Data Characteristics
Rare disease regulation and SOP data originates from policies, clinical guidelines, drug catalogs, and reimbursement rules published by national and local health commissions and drug administration agencies. These documents are typically in PDF, Word, or structured database formats. Update frequencies vary; regulations may be revised annually or have supplementary notices issued periodically, while clinical guidelines might update every few years. Document structures are complex, containing extensive specialized terminology, tables, and attachments. Fields include drug names, indications, reimbursement scope, treatment pathways, and approval processes. Drug dosages, administration routes, and specific genetic test results often include explicit units and numerical ranges.
Constraints Imposed by These Characteristics on Tool Calling and Plugins
The complexity and multiple sources of rare disease regulation data place specific demands on tool calling and plugins. First, document diversity requires parsing plugins that support various file formats and have robust capabilities for extracting structured information, such as accurately retrieving drug reimbursement percentages from PDF tables. Second, data update uncertainty necessitates flexible tool calls to trigger external data source synchronization or API queries, ensuring information timeliness. Third, the presence of specialized terminology and numerical ranges requires strict validation and unit conversion of input parameters during tool execution to prevent query failures due to format mismatches. Finally, since rare disease treatment often involves multidisciplinary collaboration, tool calls may need to integrate different external systems, such as genetic testing report systems or medical insurance settlement platforms, to provide comprehensive information.
Configuration Guidelines
| Configuration Item | Recommended Value | Rationale for Recommendation |
|---|---|---|
maxContext | 2048 | Rare disease regulatory documents are often long, requiring a larger context window to understand complex clauses. |
embeddingModel | text-embedding-ada-002 | Suitable for biomedical texts, better capturing semantic similarity of specialized terms. |
toolCallTimeout | 120 seconds | External API calls may involve complex queries or multi-system integration, requiring a longer timeout. |
maxToolCallsPerTurn | 3 | Rare disease questions often require chaining multiple tools, for example, querying policy then querying drugs. |
functionCallSchema | Generate from API documentation | Ensures that tool call parameter types, names, and descriptions strictly match the actual external API interface. |
retrievalTopK | 10–15 | Regulatory documents often contain many similar clauses; increasing the number of retrieved items can improve relevance coverage. |
Three Common Mistakes
- Symptom: Tool call returns error code
400 Bad Requestwith a message "parameter format incorrect." Reason: The external API has strict requirements for input parameter types or formats, and the plugin did not adequately validate or convert parameters, for example, passing a string to a field expecting a numerical value. - Symptom: The model repeatedly attempts to call the same tool, but each attempt times out, ultimately failing to provide an answer. Reason: The external API interface response time is too long, exceeding the
toolCallTimeoutthreshold configured in the FastGPT application, leading to tool call interruption. - Symptom: When querying rare disease reimbursement policies, the model fails to correctly extract the reimbursement percentage, returning an empty or inaccurate result. Reason: The document parsing plugin has insufficient capability to extract table data from PDFs or Word documents, or it was not optimized for specific document structures, leading to the loss of critical field information.
How to Confirm Correct Configuration
- Conduct multiple question-and-answer tests for specific rare disease names or drugs, observing whether the model accurately triggers relevant policy query tools.
- Check system logs to confirm that successful tool calls have an HTTP status code of
200 OKand that the response content matches the expected data structure. - Construct queries containing different parameter types (e.g., numerical, date, string) to verify that tool calls correctly pass parameters and are effectively processed by the external API.
The values provided are common starting points and should be measured against specific 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.