What Data Looks Like for This Category
The core entities for this category are the synthesis, fermentation, purification, quality assurance, and registration support departments of active pharmaceutical ingredient manufacturers. Daily generated documents include batch production records, material balance reports, reaction and purification records, cleaning records, impurity profile reports, and deviation and change documents. Data sources include registered process documents, raw material batch records, DCS system data, weighing system logs, LIMS systems, chromatography data systems, and QMS quality management systems. Data is updated once per production batch or process step. Fields include reaction parameters, impurity content, yield data, compliance approval records, and more, with units such as ppm, percentage, batch numbers, and timestamps.
Constraints Imposed on Vector Models and Indexing Workflows
Since data is updated frequently, with new documents generated per batch or process step, indexes must support incremental updates to avoid performance losses from full reindexing. Document types include both structured instrument data and unstructured text records, so chunking strategies must balance accurate extraction of structured fields and semantic integrity of unstructured text. Audit scenarios for this category have strict relevance requirements for retrieval results, to ensure the accuracy of vector matching and prevent irrelevant documents from disrupting audit workflows. Additionally, cumulative data per batch grows as production scale expands, so index capacity planning must adapt to continuously increasing document volume.
How to Configure Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
| Chunk Length | 800–1200 characters | Documents related to active pharmaceutical ingredients are mostly paragraph-style records. This length preserves complete semantic units such as reaction steps and impurity analysis, avoiding semantic fragmentation. |
| Overlap Length | 100–150 characters | Cross-chunk reaction parameters and impurity-related information must be retained to ensure contextual coherence during retrieval. |
| Similarity Threshold | Calibrated based on actual testing | Semantic similarity differences between content such as impurity profiles and process records for this category are small, so matching accuracy must be adjusted based on actual audit scenarios. |
| Single Search Limit | Top 10 results | Audit personnel only need to focus on the most relevant historical batches and supplier records; excessive results increase audit burden. |
| maxToken | Set to the selected embedding model/service maximum supported input tokens | maxToken is the input-token maximum supported by the selected embedding model/service; verify it in that provider configuration. See the v4.17.2 model-field reference. It is not retrieval/LLM context or a FastGPT-wide fixed cap. |
| defaultToken | Adjust based on average document length | Token consumption varies widely between different types of audit documents, such as batch production records vs. impurity profile reports, so adjustments must match actual content scale. |
Three Common Misconfigurations
- When uploading documents larger than 10 MB, some chunks fail vectorization after being split into over 1000 chunks, with partial recovery after retries. The interface displays partial chunk vectorization failures, and logs show embedding processing timeouts or format errors. The cause is insufficient resources on local CPU servers running ollama when large documents are split into too many chunks, leading to queuing timeouts for vectorization tasks of some chunks.
- After a server crashes and restarts due to multiple knowledge base upload tasks, existing knowledge bases cannot automatically enter a ready state, and the interface shows lag and no response. The knowledge base status remains "indexing" with no progress updates. The cause is that FastGPT’s indexing tasks do not have an automatic recovery mechanism, so unfinished indexing processes are not retriggered after restart.
- After updating FastGPT to versions 4.9–4.10, knowledge bases with existing indexes cannot support vector retrieval, and no results are returned for searches. No matching documents are returned when entering audit-related keywords. The cause is that the underlying format of vector indexes changed after the version upgrade, and existing indexes are not compatible with the new vector model or index structure.
How to Verify Proper Configuration
- Upload a single typical document, such as a single-batch batch production record, and check if the number of split chunks matches expectations, with no abnormal error prompts.
- Initiate a vector retrieval test to verify that the relevance of returned results meets the requirements of audit scenarios, and adjust the similarity threshold to a reasonable range.
- Simulate an incremental data upload and check if the index automatically updates, with vectorization and indexing of new documents completed without manual intervention.
- View the index monitoring panel in the FastGPT backend to confirm that current index resource usage is within a reasonable range, with no overload errors.
The values provided are common starting points and should be measured against the reader's own samples.