Data Characteristics
Rehabilitation equipment, particularly home and wearable devices, generates diverse pharmacovigilance data. This includes traditional medical institution reports and manufacturer collections. It also extensively incorporates voluntary user feedback from home use, physiological parameter changes from IoT sensors, and social media discussions on device experience and adverse events. This data often combines unstructured text, semi-structured logs (e.g., device operation logs, user action records), and structured tables (e.g., adverse event report forms). Update frequencies vary; medical institution reports typically have fixed cycles, while user feedback and IoT data can be real-time or near real-time. Document types include user manuals, device firmware update instructions, clinical study reports, and adverse drug reaction (ADR) forms. Fields, beyond standard patient information, device models, and adverse reaction descriptions, often include unique fields such as device serial number, firmware version, usage duration, charging status, and wearing method. Some physiological parameters may appear as time-series data, with units covering voltage, current, pressure, temperature, and heart rate.
Constraints on Citation and Traceability
The diverse data forms and sources of rehabilitation equipment impose specific requirements on citation and traceability capabilities. Unstructured text and semi-structured logs demand efficient text chunking and metadata extraction to ensure appropriate information granularity and traceability to original sources. High-frequency IoT data and user feedback require the knowledge base to support incremental updates and real-time indexing, preventing knowledge obsolescence. Device-specific fields like serial numbers and firmware versions must be identified during information extraction and used as key retrieval items to support precise problem localization and traceability. Furthermore, some data may come from non-professionals, leading to variable text quality, including colloquialisms, typos, and non-standard terminology. This requires the knowledge base to have fault tolerance and semantic understanding capabilities during indexing and retrieval, ensuring that even ambiguous queries can recall relevant information and accurately point to the original data source.
Configuration Settings
| Configuration Item | Recommended Value | Rationale for this Value |
|---|---|---|
Chunk size | 500–800 characters | Adverse event descriptions for rehabilitation equipment are often concentrated; this length helps maintain contextual integrity and reduces redundancy. |
Chunk Overlap Length | 50 characters | Ensures contextual continuity at chunk boundaries, improving recall hit rates across segments and handling cases where key information is at paragraph edges. |
Recall count | Top 10 entries | Given the complexity of rehabilitation equipment adverse events, increasing the recall quantity can cover more potentially relevant information. |
Similarity threshold | 0.75 | Balances recall and precision. For colloquial expressions and non-standard terminology, it maintains a certain recall flexibility. |
Rerank result count | Top 3 entries | While ensuring broad recall, re-ranking selects the most relevant few results, improving user reading efficiency. |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Provides ample parsing time for large clinical reports or device log files, preventing parsing failures due to timeouts. |
Three Common Mistakes
- Symptom: Knowledge base recall results lack critical device model or firmware version information, preventing precise problem localization. Reason: Device metadata was not treated as an independently retrievable entity during text chunking, or these fields were not correctly extracted and associated during indexing.
- Symptom: Colloquial user feedback fails to recall relevant adverse event reports, even when the content is semantically very similar. Reason: The knowledge base index did not adequately account for the impact of informal language and typos, leading to the failure of retrieval strategies based on exact matching or standardized terminology.
- Symptom: The source document ID or timestamp cited in RAG results is empty or points to an unrelated document. Reason: During data ingestion, the knowledge base failed to correctly parse or associate the original document's unique identifier and timestamp, resulting in lost or incorrect traceability information.
How to Verify Configuration
- Select a batch of test questions containing colloquial descriptions and device-specific fields. Ask these questions in the FastGPT interface and check if the cited sources in the answers include the correct device model, firmware version, and corresponding adverse event reports or user feedback.
- Upload a new device operation log or user feedback. After the knowledge base updates, observe if the new content can be accurately recalled using key information from the log (e.g., specific error codes, timestamps) and traced back to the original log file.
- For known adverse event data related to rehabilitation equipment, simulate a user querying with non-standard terminology or vague descriptions. Check the similarity scores of the recalled results and verify that the returned citations cover all relevant and correct document snippets.
Note: The values provided are common starting points and should be measured 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.