大模型的"幻觉"问题是实际应用中最大的挑战之一。通过 RAG（检索增强生成）技术，可以让模型基于真实知识回答问题，大幅降低幻觉风险。这是我们"调整向量"的核心操作对象。
幻觉是大模型生成看似合理但实际上完全错误信息的现象，是我们在实际应用中必须面对和解决的核心问题。
RAG 是一种将外部知识检索与语言模型生成相结合的技术，让模型"有依据地说话"。
Dify 提供了可视化的知识库管理功能，让你轻松构建和管理 RAG 应用。
除了 RAG，还有多种策略可以帮助我们减少模型产生幻觉的可能性。
原理：让模型的回答基于明确的、可验证的知识源。
实现方式：
原理：通过精确的提示词约束模型的输出行为。
实践技巧：
原理：使用多个不同的模型对同一问题进行回答，对比结果的一致性。
适用场景：对于关键决策、重要信息输出等需要高可靠性的场景。
实现方式：可以在 Dify 中创建多个模型的集成应用，自动对比输出结果。
原理：在输出前对模型回答进行事实核查。
实现方式：
从真实故障中总结的 RAG 调试方法论，帮你快速定位和解决知识库检索失效问题。
AI 回答错误 = 检查输入（Prompt/Context） + 检查检索（Recall/Rank）
故障现象：用户问"找下 ZeroCloud 里面的 getTagText"，AI 回复"未找到相关信息"
关键线索：AI 在拒绝时补充了一句——"（注：您提供的 context 内容仅包含 ZcFileUtils.download... 并未提及 getTagText）"
初步判断：这不仅是模型能力问题，而是数据链路（Data Pipeline）出了问题。模型很诚实，它确实没收到正确的数据。
关键动作：检查 LLM 节点的 Input 变量，查看其接收到的上下文（Context）。
发现异常：Token 数显示有 155 tokens，但实际内容是 ZeroCloud.config.title、客户端网页标题文字等元数据字段，而不是代码正文。
诊断结论：模板配置错误——Jinja2 语法引用了错误的字段，系统把数据库的"表头/元数据"当成了"文章内容"喂给了模型。
修正方案：修改模板语法，确保遍历并输出的是检索结果中的 content 字段（例如 {{ item.content }}）。
故障现象：AI 终于能读到文章了，但依然回答"未找到 getTagText，但我看到了 ZcFileUtils..."
深度归因——向量检索为什么会"张冠李戴"？
关键动作：使用"测试检索"或"命中测试"功能，不要只看最终对话，直接去知识库管理界面测试检索。
测试结果（输入关键词：getTagText）：
确诊结论：问题本质是检索召回率（Recall）不足。并不是模型不懂，而是"书"没翻对页。纯向量检索在处理"精确代码函数名"时，容易受周围代码语义干扰。
背景：将文档转换为 Markdown 格式上传，期待结构化切片能改善召回效果——但依然失败。
尝试：添加 System Prompt 约束
"请严格基于提供的 Context 回答。如果 Context 中包含 ZcFileUtils 但不包含 getTagText，请不要强行关联，直接告知用户当前上下文缺失该函数定义。"
效果：AI 不再胡编乱造，而是诚实地说"我看到了 ZcFileUtils 但没看到 getTagText"。但这只是让 AI 更诚实地表达不知道，并没有真正解决问题。
🎯 关键突破：知识库分段摘要（触发词机制）
触发词：getTagText, 获取标签文本, 标签处理函数✅ 最终结果：配置生效后，再问"找下 ZeroCloud 里面的 getTagText"，AI 终于能准确返回 getTagText 的代码定义了。
基于现有技术栈（Dify + Hermes + 低代码平台）构建完整的私有知识库体系，实现"精准召回、可靠生成、安全输出"。
❌ 错误做法：直接把一堆杂乱的 Word、PDF、Markdown 文档扔进知识库
✅ 正确步骤：
| 子分段 | ~200字，负责精准检索 | 如："保修期是多久" → 保修期限 |
| 父分段 | 500-800字，提供完整上下文 | 如：保修范围、例外条款、申请流程 |
Hermes 的角色定位：不是去"背诵"知识库，而是充当调用知识库的专家员工。
工作流程：
集成步骤：
两种对接方案：
权限隔离：利用 Dify 的元数据标签功能，给不同部门的知识打上标签（department: it/hr/finance），配合低代码平台的账号体系，实现"不同人查到的内容不一样"。
在 Dify 的 System Prompt 中加入强制约束：
效果：最大限度杜绝幻觉
利用 Dify 后台的"日志与标注"功能：