Data Characteristics for this Category
Stability study data primarily originates from batch production records, quality control reports, accelerated stability study reports, and long-term stability study reports generated during drug development. These reports are typically PDF documents with a high degree of structural organization, containing extensive tabular data and experimental result descriptions. Data update frequency depends on the drug development phase and regulatory requirements. For example, long-term stability reports might update annually, while batch production records generate with each new batch. Common fields in these documents include batch number, production date, expiry date, test item, test method, test result, unit, temperature, humidity, and light conditions. Units are expressed in various ways, such as mg/mL, ℃, %RH, Lux, days, and months.
Constraints from these Characteristics on "Document Parsing and Chunking"
The structured tabular data characteristics of stability study documents require the document parser to have precise table recognition and data extraction capabilities. Due to the diversity of units and fields, chunking must ensure that related data and units are fully associated to avoid semantic loss. For instance, a test result must be in the same chunk as its corresponding unit and test item. Document update frequency dictates the knowledge base content update strategy, requiring support for incremental updates and version management to reflect the latest stability data. Time-series data within documents (e.g., test results at different time points) should maintain its temporal logic during chunking to allow accurate retrieval of drug stability trends over time. For large volumes of historical documents, batch processing capabilities and a recovery mechanism for interrupted processing are crucial.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
Chunk size (Chunk Length) | 800–1200 characters | Ensures complete inclusion of table rows or experimental result descriptions, preventing semantic fragmentation. |
Overlap Length | 100–200 characters | Guarantees contextual continuity at chunk boundaries, especially for multi-page tables or descriptive text. |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Accommodates the time required to parse lengthy stability reports containing complex tables or images. |
UPLOAD_FILE_MAX_SIZE | 500 MB | Supports large stability report files, preventing upload failures due to excessive file size. |
Chunking Method | By title + By text length | Prioritizes structured document elements like tables and section titles, supplemented by fixed length to ensure comprehensive coverage. |
Recall count (Recall Count) | Top 5 entries (Top 5) | Balances retrieval efficiency with result comprehensiveness, ensuring critical stability data is recalled. |
Common Pitfalls
- When uploading a large number of stability report documents, task processing interrupts, and the backend log shows
Error: Document processing timeout. This typically occurs because thePARSE_FILE_TIMEOUT_SECONDSparameter is set too low, not providing enough processing time for complex documents. - In retrieval results, stability data does not match the corresponding units or test conditions; for example, only
25is returned withoutmg/mLor25℃. This often results from an overly simplistic chunking strategy that fails to integrate multi-column data from tables or key associated information from descriptive text into the same chunk. - When uploading large PDF documents, the system is unresponsive or returns an
HTTP 413 Payload Too Largeerror. This indicates that theUPLOAD_FILE_MAX_SIZEconfiguration is below the actual file size, causing the file to be rejected by the server during the upload stage.
Verification Steps
- Select a stability report containing complex tables and multi-page content, upload it to the knowledge base, and check if its parsing status displays "Completed".
- Randomly sample parsed stability reports. Use the knowledge base's preview or retrieval function to check if key fields (e.g., batch number, test result, unit) appear accurately and semantically complete within the chunked content.
- Simulate a batch upload operation with a large number of documents. Observe if the entire upload and parsing process runs smoothly. Check for any failures due to timeout or file size limits, and adjust the
PARSE_FILE_TIMEOUT_SECONDSandUPLOAD_FILE_MAX_SIZEthresholds accordingly.
The values provided are common starting points. Measure them against your own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-21.