知识库问答是最适合认识 Dify 的第一个应用。它的目标并不是让模型“知道更多”，而是在回答前先从你的资料里找到相关内容，再要求模型依据这些内容作答。这类方式通常被称为 RAG，也就是检索增强生成。
先定义它能回答什么
假设我们要做一个内部制度助手。资料包括报销规范、请假制度和办公用品申请流程。第一版只回答这三类问题；遇到薪酬、法律意见或资料中没有写明的事项，应明确说不知道，并提示用户联系对应负责人。
这一步很重要。知识库的边界越清楚，测试问题越容易准备，应用上线后的责任也越明确。
最小链路
一条可用的链路可以保持得很短：
用户输入 → 知识检索 → LLM → 回答先在 Dify 中创建知识库，上传经过确认的资料。文档进入知识库后会被分段并建立索引。不要急着连接应用，先使用知识库的检索测试，输入真实用户可能提出的问题，观察命中的片段是否正确。
检索稳定后，再创建 Chatflow 或聊天类应用，把用户问题交给知识检索节点，并将检索结果连同问题一起传给 LLM。系统提示词可以约束模型：只依据检索内容回答；信息不足时直接说明；不要虚构制度、日期和联系人。
分段比提示词更早决定答案
一份文档如果把多个主题塞在同一个超长段落里，检索结果会携带大量无关信息；分段太碎，又可能丢失条件和上下文。整理资料时，可以让一个片段尽量只回答一个相对完整的问题，并保留标题、适用对象、生效时间等必要信息。
当制度更新时，应删除或停用旧版本，避免新旧规则同时被召回。对于部门、地区或产品线不同的资料，可以补充元数据，并在检索时限定范围。
用问题集验收
至少准备三组问题：
- 资料里可以直接找到答案的问题。
- 需要结合两个片段才能回答的问题。
- 明确超出知识范围的问题。
验收时不要只看语言是否流畅，还要核对引用内容、数字、条件和结论。一个合格的助手应当答对已知问题，也应当在未知问题上克制。
知识库问答的真正成果不是“像人一样聊天”，而是让用户更快抵达可信资料。只要这一点没有做到，就不应该用更长的提示词掩盖检索质量问题。