> For the complete documentation index, see [llms.txt](https://docs.cherryai.com.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cherryai.com.cn/docs/en-us/knowledge-base/cases.md). # Knowledge Base Use Cases Whether a knowledge base is reliable does not depend on the amount of material, but on whether the boundaries are clear, the sources are maintainable, and real questions can consistently retrieve the right evidence. {% hint style="info" %} The parameters below are only a starting point. First run through import, retrieval, and usage with 3–10 representative materials, then expand based on a fixed question set. {% endhint %} ## First design using the same method {% stepper %} {% step %} ### 1. Clearly define the final task Clarify the judgment or deliverable the user needs to make, such as looking up policies, troubleshooting faults, or generating a research report. {% endstep %} {% step %} ### 2. Define the material boundaries Only place materials in the same knowledge base if they should be retrieved together during use. Content with different permissions, lifecycles, product models, or versions should be separated first. {% endstep %} {% step %} ### 3. Choose sources and update methods Specify who maintains documents, notes, directories, and web pages, when they are replaced, and whether historical versions need to be kept. {% endstep %} {% step %} ### 4. Prepare validation questions Prepare 3–10 real questions covering exact facts, conditional rules, colloquial wording, and easily confused versions. {% endstep %} {% step %} ### 5. Adjust the retrieval plan Keep the configuration simple at first. Add embeddings only when BM25 is not enough to handle synonymous expressions; add reranking only when the correct candidate appears but the order is unstable. {% endstep %} {% step %} ### 6. Connect to a dialogue or Agent Use normal conversation for one-shot Q\&A; bind an Agent when multi-step research, comparison, and file delivery are needed. Check the sources line by line before going live. {% endstep %} {% endstepper %} ## User case 1: Employee policy Q\&A ### Goal Let employees look up travel approval, lodging standards, and reimbursement exceptions, and be able to open the sources to verify the original text. ### Material organization * Knowledge base: \[Employee Travel Policy] * Entry: \[Business Trip Approval Process] * Entry: \[Lodging Standards Quick Reference] * Entry: \[Travel FAQ]
由多条制度资料组成并全部就绪的员工差旅制度知识库

Policy clauses and FAQs are maintained separately, so updating one does not require redoing all materials.

### Recommended configuration | Item | Starting point | When to adjust | | ------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------- | | Retrieval | Start with BM25 | Add embeddings when there is a large difference between employee phrasing and policy wording | | Reranking | Do not use for now | Enable when the correct candidate appears but the order is unstable | | Material version | Keep only the current version | If historical auditing requires coexistence, include the year in the name | | Answer requirements | Separate the conclusion, conditions, and sources | Clearly mark when the material does not specify something | ### Validation question 1. What is the maximum hotel reimbursement for a business trip? 2. Can overseas car rentals be reimbursed? 3. Who approves when the estimated total cost exceeds 5,000 yuan? 4. What happens if a hotel is booked before approval? ### Conversation prompt > Answer only based on the "Employee Travel Policy." Give the conclusion first, then list the applicable conditions and sources; if the material does not explain something, write "not specified in the policy" and do not fill it in with common sense. {% hint style="success" %} When validation passes, the same policy can be hit by both the original wording and colloquial wording of the question, and the amounts, roles, and conditions in the answer can be directly supported by citations. {% endhint %} ## User case 2: Product after-sales assistant ### Goal Organize official manuals, fault codes, and reviewed cases so customer service can first provide safe, traceable troubleshooting advice. ### Material boundaries | Knowledge base or material group | Content | Maintenance principle | | -------------------------------- | -------------------------------------------------------- | -------------------------------------------------- | | Official manual | Specifications, warranty boundaries, standard procedures | Keep the model and document version | | Fault code | One fault, one section | Label applicable firmware and device model | | Reviewed case | Cases with confirmed causes and solutions | Unreviewed chat logs must not be imported directly | When rules differ significantly across models, split them into separate knowledge bases by model to avoid the same fault code competing with itself. ### Retrieval and Agent configuration * For PDFs, first inspect the table of contents, tables, and two-column body text. * Fault codes depend on precise terminology, so keep BM25. * When customer descriptions are more colloquial, add an embedding model. * Bind the official manual and reviewed cases to the after-sales Agent, and enable only \[Knowledge Base Search]. > Troubleshoot in three steps based on the device model, fault code, and symptoms. Indicate at each step whether the basis comes from the official manual or reviewed cases. When disassembly, electricity, or data erasure is involved, first warn about the risks and wait for confirmation. ### Acceptance criteria * Do not use steps from other models for the current model. * Safety warnings appear before the operation steps. * Official rules and case suggestions are kept separate. * Hand off to a human when there is no material support; do not guess. ## User case 3: Research materials and reports ### Goal Extract verifiable evidence from papers, interview notes, and web snapshots, then have the Agent generate a comparison report with sources. ### Material organization * Build the knowledge base around research questions; do not put all papers into one large repository. * The file name includes the author, year, and a short title. * Interview notes should indicate the interviewee's role, date, and whether they can be cited. * Web materials should record the capture date, because the knowledge base stores imported snapshots.
从提出真实问题、检查召回、定位问题到只调整一项并重新索引复测的知识库质量闭环图

First validate source coverage in the research repository with fixed questions, then hand it to the Agent for cross-document synthesis.

### Agent prompt > Find evidence in the bound research knowledge base for "why users abandon the initial setup." First list the original viewpoints and limitations by source, then synthesize consensus, disagreements, and hypotheses to be verified. Finally generate a Markdown report; do not write inferences as if they were the interviewees' original words. ### From evidence to deliverables
资料来源经过知识库召回和 Agent 整理后形成文字文件或多语言图片的内容工作流图

Keep the evidence and limitations first, then let the Agent organize them into a report; do not let the finished product obscure the original sources.

### Acceptance criteria * Consensus is supported by at least two independent sources. * Disagreements retain their own conditions and are not forced to merge. * Citations, inferences, and recommendations are clearly labeled. * Web snapshots and paper versions are traceable. ## Configuration notes: reusable design table | Item | Questions to answer | | ------------------- | -------------------------------------------------------------------------------------------- | | Goal | What judgment or result does the user ultimately need to produce? | | Boundary | Which materials should be retrieved together, and which must be separated? | | Sources | How should files, notes, directories, and web pages be updated? | | Parsing | Which types of documents are most prone to OCR, table, or ordering issues? | | Retrieval | Is BM25 sufficient? When are embeddings and reranking needed? | | Validation question | Which 3–10 questions best represent real usage? | | Failure handling | What should be done when there are no results, conflicting versions, or no material support? | | Maintenance | Who is responsible for replacing materials, re-indexing, and backups? | {% hint style="warning" %} Do not treat "imported a lot of material" as the completion criterion. The more material there is, the more explicitly duplicate versions, permission mixing, and noisy competition need to be managed. {% endhint %} ## Common questions
Should policies, manuals, and cases be placed in the same knowledge base? Check whether they should be retrieved together in the same question, and whether permissions and update cycles are consistent. When the differences are obvious, splitting the repositories makes it easier to control source boundaries.
Can the case repository directly import all customer service chats? Not recommended. First review the causes, solutions, and privacy content, and import only confirmed, reusable cases.
What needs to be done before expanding materials? Keep a fixed set of validation questions, import in batches, and retest. If new materials degrade the results, you can quickly identify which batch caused the issue.
## Continue reading
Knowledge base basicsFirst get creation, import, retrieval, and use working./pages/7140324ff22db2432f4def400aa0613550c21011
Use with AgentConfigure multi-step research and material permissions./pages/828bb5b1083ccd9a5f192ca3835ea0fb0f1e6a21
Common questionsUse symptoms to locate materials, retrieve them, or answer questions./pages/81a55a83c41cfd9a6cb2e0cc71cd6a0e384a8681
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cherryai.com.cn/docs/en-us/knowledge-base/cases.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.