Knowledge Base Retrieval and Recall for Hotel and Catering

What the Data for This Category Looks Like

Data sources primarily include daily sales reports exported from store POS systems, supply chain purchase receipts, digital offline menu files, and public industry association survey documents. Update frequencies vary widely. Menu SKU information is updated weekly. Customer traffic and revenue data are synced daily. Supply chain ledgers are updated monthly. Most documents are structured tables or semi-structured reports, containing fields such as store code, business date, customer unit price, ingredient purchase price, in-store visit count, and more. Units include yuan, visits, kilograms, percentage, and others.

Constraints on Knowledge Base Retrieval and Recall

Highly structured data requires field-level precise matching during retrieval, to avoid irrelevant results caused by general semantic recall. Data sources with multiple update frequencies must be split into sync batches. Perform incremental indexing daily, weekly, and monthly separately, to avoid excessive computing resource usage from full indexing. Document fields include numerical values with multiple units. A unified unit conversion logic must be implemented during recall, to ensure cross-store comparison of customer unit price and ingredient purchase price data. Most single document content consists of short tables or single-line records. Adjust segmentation rules to avoid losing field association information after splitting.

Configuration Settings

Configuration Item	Recommended Value	Rationale
`chunk_size`	800–1200 characters	Adapts to short tables and single-line records in hotel and catering documents, preserves field association integrity
`recall_top_k`	Top 10–15 entries	Covers retrieval needs across multiple stores and categories, avoids insufficient single-store data
`similarity_threshold`	0.72–0.78	Filters low-match unstructured text, retains structured records with high field matching scores
`rerank_top_n`	Top 3–5 entries	Focuses on precise results for core stores or core SKUs, aligns with decision-making needs in investment research scenarios
`incremental_index_schedule`	Update revenue data daily at 2:00, update menu data weekly at 1:00, update supply chain ledgers monthly at 10:00	Matches update frequencies of different data sources, reduces computing power waste
`parse_structured_table`	Enabled	Retains correspondence between table fields and content, avoids loss of structured information after splitting

The parameter values provided on this page are common starting points for configuration setup. Actual values are affected by material format, data volume and business rules. Specific issues require specific analysis. It is recommended to test on your own samples before finalizing.

Three Common Misconfigurations

Symptom: After the reranking model is deployed and passes testing, the is_re_ranked field returned by each retrieval is false. Cause: The rerank_model_id parameter is not included in the retrieval request, or the configured reranking model is not bound to the current knowledge base.
Symptom: Retrieval results differ significantly between online chat and API calls, and API returned results have lower accuracy. Cause: The prompt_template parameter is not passed correctly in API calls, or the use_chat_mode parameter is not set, resulting in the exclusive prompt logic for investment research scenarios not being enabled.
Symptom: The specified knowledge base cannot be selected during tool calling. Cause: The index ID of the target knowledge base is not bound in the tool configuration, or the knowledge base permission switch for the tool is not enabled.

How to Confirm Configuration Is Complete

Send a single API retrieval request, check the total_hits field in the returned results, confirm that the number of recalled entries matches the configuration range of recall_top_k.
Call the reranking model test interface, pass in the retrieval results and user questions, confirm that the score field sorting of the returned results meets expectations.
Check the logs of the incremental indexing task, confirm that the sync time of different data sources matches the incremental_index_schedule configuration.
Compare retrieval parameters between online chat and API calls, ensure that configurations such as similarity_threshold and rerank_top_n are completely consistent.

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-14.