很多人调试提示词时，总喜欢把业务规则、产品规格、几十条注意事项全部塞进系统的 Prompt 框里。在前两轮对话时，大模型的回答看起来还算正常。但是只要对话进行到第五轮或者第八轮，模型就会开始漏掉前置要求，甚至给出前后矛盾的事实。
这并不是你的提示词写得不够详细，而是你把大模型当成了外部数据库。大模型的上下文窗口就算支持上万字，它在长对话中的注意力依然会衰减。而且每次多轮互动都带上全部规则文本，不仅会导致响应速度变慢，还会消耗大量 Token 成本。
解决这个问题的直接方式，是把“规则指令”和“背景知识”拆开管理。指令保留在提示词内，背景知识存入本地知识库。配合开源工具 Dify 构建本地知识库与检索增强（RAG）管道，模型在每次生成回复之前，只会读取当前问题最相关的几条参考内容。
| 对比维度 | 纯长提示词方案 | Dify 本地知识库方案 |
|---|---|---|
| 事实准确度 | 依赖模型内部参数记忆，极易捏造细节 | 依赖私有文档匹配，回答有据可依 |
| 多轮稳定性 | 对话轮次增加后，极易遗忘早期约束 | 检索与对话历史解耦，长对话始终稳定 |
| Token 消耗 | 每次交互都重复发送全量规则，费用持续累加 | 仅发送检索出的局部片段，单次消耗可控 |
| 维护难度 | 规则变更需要修改长文本并反复微调措辞 | 直接替换或更新知识库文件，无需重构系统词 |
构建高精度知识库，前期七成的精力在于文档清洗和分块处理。直接上传未经处理的几百页 PDF，召回结果往往偏差很大。
在上传文档前，先做基础清洗：删掉文档里的页眉页脚、扫描杂质以及重复的版权声明。接着根据文档结构选择分块模式。Dify 支持自动分块、自定义分块以及父子分块三种核心方式。
| 分块策略 | 适用场景 | 优点 | 缺点与避坑提示 |
|---|---|---|---|
| 自动分块 | 叙事类文本、长篇通用资讯 | 设置快捷，无需手动调整规则 | 容易切断表格或强逻辑段落，精度一般 |
| 自定义分块 | 制度文件、技术规范、产品说明书 | 精确控制切割位置，保留段落完整度 | 分块过小会导致语义残缺，分块过大则会混入无关噪声 |
| 父子分块 | 客服问答表、操作手册、法律条文 | 检索小段落确保精准，向模型提供完整大段落 | 索引构建耗时较长，对硬件资源要求稍高 |
按照真实场景测试，处理技术手册或规章制度时，分块大小（Chunk Size）建议设置为 400 到 600 Token。分块重叠（Chunk Overlap）建议设置为 10% 到 15%（即 40 到 60 Token）。设置重叠区间的目的，是防止关键句子刚好在分界处被截断，导致语义丢失。
文档分块完成后，决定答案质量的关键就是检索配置。很多初学者只开单一的向量检索，在遇到产品型号、专有名词、错误代码时经常找不到结果。因为向量模型擅长找语义相近的话，不擅长做字符级精确匹配。
实际部署中更稳妥的做法是配置 混合检索（Hybrid Search）配合重排序（Rerank）。
| 检索模式 | 技术机制 | 适用数据类型 | 核心参数推荐 |
|---|---|---|---|
| 纯向量检索 | 计算向量嵌入（Embedding）的余弦相似度 | 意图问答、口语化提问 | Top K: 3~5，相似度阈值: 0.6 |
| 全文检索 (BM25) | 基于倒排索引与关键词词频打分 | 专有名词、产品型号、固定编号 | Top K: 5 |
| 混合检索 + Rerank | 先并行初筛候选集，再由交叉编码器重新打分 | 专业客服、垂直业务支持、多轮交互 | 初筛 Top K: 8，Rerank 保留: 3，得分阈值: 0.5 |
混合检索会同时启动关键词检索和向量检索。关键词检索抓取固定字符，向量检索捕捉口语意图。两路召回结果汇总后，交由 Rerank 模型重新打分。本地部署可以使用 `bge-reranker-large` 模型。必须将 Rerank 的得分阈值设为 0.5。这样低于设定分数的无关分段会被直接抛弃，避免无关上下文干扰模型的判断。
多轮对话常常会出现指代不明的问题。比如用户在第一轮问：“A2 路由器的默认密码是什么？”模型回答后，用户第二轮接着问：“那它的复位键在哪里？”如果系统直接拿第二轮这句“那它的复位键在哪里？”去匹配知识库，检索模块不知道“它”代表什么，召回的内容大概率完全脱节。
在 Dify 里解决多轮指代问题，需要使用 Chatflow（对话工作流），具体搭建步骤如下：
先做 A：在 Dify 平台创建应用，类型选择 Chatflow，不要选基础的 Chatbot 模板。
然后做 B：在知识检索节点前面，插入一个 LLM 节点作为问题重写模块。调用轻量化模型，输入提示词：“请根据历史对话记录，将用户的最新问题改写为一个包含完整主谓宾的独立问题，不要补充不存在的内容。”例如将“那它的复位键在哪里？”重写为“A2 路由器的复位键在哪里？”。
接着做 C：把重写后的完整提问传入 知识检索节点。设置检索方式为混合检索，并启用配置好的 Rerank 模型。这样检索模块拿到的就是语义完整的目标短句，召回准确度会显著改善。
最后做 D：在最终生成回复的 LLM 节点中，配置标准系统提示词模板，约束模型的输出边界。模板写法可以直接参考以下结构：
你是一名客观严谨的技术助理。请严格根据下方给出的【参考知识】回答用户的问题。
【参考知识】：
{{#context#}}
回答约束：
1. 仅依据【参考知识】内的信息回答。如果【参考知识】中未提及相关答案，请直接告知“知识库中未记载该信息”，不得凭空猜测或补全信息。
2. 回复保持清晰直接，不使用主观修饰词。
3. 结合对话历史中的上下文逻辑进行回答。在本地部署方面，直接使用 Docker Compose 运行 Dify 社区版即可。本地 Embedding 模型推荐选用 `bge-m3` 或 `bge-large-zh-v1.5`，配合 Ollama 完成加载。
在落地使用中，还要注意两个关键避坑点：
第一，绝对不要把未经校对的扫描件直接建库。OCR 识别出的错别字会直接破坏向量语义，导致检索阶段彻底失效。必须在文本格式整理干净后，再导入系统。
第二，不要为了追求完整度而盲目调大 Top K。有些用户把 Top K 设置成 10 甚至 15，把大量低相关度的片段塞进上下文。这会导致大模型产生严重的注意力分散，生成错误答案。保持保留 3 到 4 个高相关度片段，才能在控制成本的同时获得高精度输出。
原创文章，作者：七点互动，如若转载，请注明出处：https://ai.qidianhudong.com/aikonw/4330.html
