What the data for this category looks like
Public transit service inquiry-related data mainly comes from official operation manuals, route adjustment announcements, ticketing policy documents, customer service historical question-and-answer archives, real-time dispatch notifications, and stop service descriptions. Data sources include internal document systems of urban public transit enterprises, and industry public content from government disclosure platforms. Update cadence: Route adjustment documents are updated irregularly according to operational plans. Ticketing rule documents are updated every quarter or half year. Real-time service notifications are pushed immediately based on temporary dispatch requirements. Document formats mostly include structured tables (stops, fares, operating hours), long-text question-and-answer entries, and PDF-format operation manuals. Fields include route number, stop name, fare amount, service hours, and inquiry script templates. Common units are yuan, minutes, and kilometers.
What constraints these characteristics impose on the "document parsing and chunking" step
Public transit service inquiry documents contain three types of content: structured tables, short-text question-and-answer entries, and long-text operation manuals. Standard character-based chunking will split the rows of structured tables, causing linked information such as routes and fares to break apart. A large number of short question-and-answer entries need to be chunked as single entries or linked groups. Overlapping chunking across entries will lead to information confusion during retrieval. The real-time update requirement of service notifications means the parsing process must control time consumption to avoid impacting service response. Strongly linked fields such as route numbers and stop names must retain context to ensure complete operation information can be matched during retrieval.
How to configure the settings
Reference only; verify against the target FastGPT release and deployment documentation.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Adapts to the average length of long-text paragraphs in public transit service inquiry documents, balancing retrieval recall range and accuracy |
chunkSplitter | Split by paragraph + table boundary | Adapts to document structures mixing long-text question-and-answer entries and structured route tables, avoiding splitting that breaks table integrity |
customPdfParse | Enabled | Used to parse PDF documents such as public transit operation manuals and announcements, retaining original layout and table field information |
PARSE_FILE_TIMEOUT_SECONDS | 60–180 seconds | Adapts to the average size of public transit documents, avoiding parsing timeout for large-format operation manuals |
chunkSettingMode | Manual mode | Allows separate chunking rule configuration for three document types: question-and-answer entries, operation tables, and real-time notifications |
UPLOAD_FILE_MAX_SIZE | 50–100 MB | Adapts to the needs of public transit enterprises for batch uploading operation manuals and historical question-and-answer archives, avoiding file upload interception |
Three common configuration mistakes
- Phenomenon: After custom chunking, duplicate blocks appear in the knowledge base and are automatically deleted, causing the manually set chunk order and index to not match. Cause: The system's default content deduplication logic is not disabled. The system automatically clears blocks with completely identical content, breaking the manually configured chunk order.
- Phenomenon: When parsing public transit structured table documents, table content is split into scattered text blocks, making it impossible to fully retrieve single route information. Cause:
chunkSplitteris not configured to split by table boundaries, and the default character-based chunking logic is used, destroying the table structure. - Phenomenon: When batch uploading public transit operation manuals, parsing tasks remain in the parsing state for a long time, and finally return a timeout error. Cause: The
PARSE_FILE_TIMEOUT_SECONDSparameter is not adjusted, and the default shorter timeout duration is used, which cannot cover the parsing time of large-format documents.
How to confirm the configuration is correct
- Upload a PDF document containing standard route tables, check the parsed chunk content, confirm that table rows are not split and are fully retained in a single chunk.
- Upload a text document containing 10 or more customer service question-and-answer entries, check if chunks are split per single question-and-answer entry, with no overlapping chunks across entries.
- Upload an operation manual of around 50 MB, check the parsing task status, confirm that parsing completes within the set timeout duration with no timeout errors.
- View the knowledge base's chunk list, confirm that no automatically deleted chunks appear, and the manually configured chunk order matches the original document content.
The values provided are common starting points and should be evaluated against samples relevant to the specific deployment.
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-28.