从幻觉到可信：构建企业级AI智能体的工程化实践与多层防御体系

1. 从“幻觉”到“可信”：智能体落地的核心挑战

最近和几个做AI应用落地的朋友聊天，大家不约而同地提到了同一个词：心累。原因无他，辛辛苦苦基于大模型开发的智能客服、数据分析助手或者内容生成工具，时不时就会给你来个“惊喜”。比如，你问它“我们公司上季度的营收增长率是多少？”，它可能煞有介事地编造一个18.5%的数据，还附上一段看似合理的分析；或者，在处理一份法律合同时，它可能会“创造”出几条根本不存在的条款。这种现象，在圈内我们称之为大模型的“幻觉”。

“幻觉”不是指模型疯了，而是指大模型在生成内容时，会基于其训练数据中的统计规律，产生一些看似合理但事实上不正确、无依据或与输入信息相矛盾的内容。这几乎是所有生成式AI与生俱来的“原罪”。对于写诗、编故事这类创意场景，幻觉或许是灵感的源泉；但对于企业级应用，尤其是金融、法律、医疗、客服等严肃场景，幻觉就是致命的毒药。它直接动摇了用户对AI系统的信任基础——如果一个工具连基本的事实都无法保证，谁还敢把重要决策交给它？

因此，“可信智能体”这个概念应运而生，并且迅速从学术讨论变成了工程实践中的头号命题。它不再是简单地调用一个API，而是指一整套工程化、系统化的技术方案，其核心目标就是约束大模型的想象力，将其输出牢牢锚定在事实、逻辑和业务规则的轨道上。澜舟科技提出的“可信智能体”框架，正是针对这一痛点的一次系统性工程实践。它不是某个单一的“银弹”算法，而是一个融合了知识约束、流程控制、反馈学习和结果验证的复合型技术栈。简单说，它的思路不是“教模型不说谎”，而是“给模型套上缰绳，并随时检查它有没有跑偏”。

2. 拆解“幻觉”的根源：为什么大模型会“胡说八道”？

要治理幻觉，首先得理解它从何而来。从工程视角看，大模型的幻觉并非随机错误，其产生有深刻的机制性原因，主要可以归结为以下几点：

2.1 训练数据的固有缺陷与知识截止

大模型本质是一个基于海量互联网文本训练的概率模型。互联网信息本身就有大量矛盾、过时、不准确甚至虚假的内容。模型在学习时，无法像人类一样进行事实核查和逻辑推理，它只是学会了“什么样的词序列更常一起出现”。因此，当被问及训练数据中不存在或存在冲突的信息时，模型倾向于生成一个在统计上“最流畅”、最符合其学习到的语言模式的答案，而非事实正确的答案。这就是“一本正经地胡说八道”的根源。

此外，所有大模型都有知识截止日期。对于截止日期后的新事件、新数据，模型一无所知，强行回答必然产生幻觉。例如，询问“2024年某公司的最新财报”，如果模型数据截止到2023年，它很可能会基于2023年的数据“推理”或“编造”出一个2024年的结果。

2.2 自回归生成的“贪婪”与“创造性”

大模型以自回归方式生成文本，即根据上文预测下一个最可能的词。这种机制存在两个倾向：

1. 局部贪婪：在每一步，模型都倾向于选择当前概率最高的词（即使采用采样策略，也围绕高概率区域）。这可能导致模型为了保持生成的流畅性和“合理性”，在某个节点上选择了一个看似合理但偏离事实的词汇，并由此一路“将错就错”下去。
2. 过度泛化与捏造：模型具备强大的“联想”和“补全”能力。当问题模糊或信息不足时，模型会主动调用其“内部知识”（实则是训练数据的统计模式）进行补全。这种补全在创意写作中是优点，在事实问答中就是捏造。例如，问“张三和李四谁更擅长编程？”，如果训练数据中同时提到“张三是工程师”和“李四写过代码”，模型就可能编造一段对比论述。

2.3 提示工程与上下文管理的不足

很多幻觉源于糟糕的输入。模糊、矛盾或多义的提示词（Prompt），会引导模型走向错误的方向。此外，大模型有有限的上下文窗口。当我们在上下文中提供参考文档（如知识库）时，模型可能存在“注意力漂移”问题，即生成到后半段时，逐渐忽略了上下文开头的关键约束信息，又开始依赖自身的参数化知识进行“自由发挥”。

理解了这些根源，我们就能明白，对抗幻觉不能只靠“更好的大模型”，而必须依靠外部工程化手段进行系统性约束和校正。这正是澜舟可信智能体技术框架发力的地方。

3. 澜舟可信智能体技术栈：一个多层防御体系

澜舟的可信智能体框架，可以看作是一个针对大模型输出的“质量管控流水线”。它并不试图在单一环节解决所有问题，而是通过多个环节的协同，层层过滤和修正，最终输出可靠的结果。其核心可以概括为“前约束、中控制、后验证”的三段式工程架构。

3.1 前置层：知识注入与精准提示设计

这一层的目标是在大模型开始生成之前，就尽可能为其提供准确、结构化的“弹药”，并给出清晰的“作战指令”。

1. 动态知识检索与增强：这是对抗知识截止和事实性错误的核心。系统不会让大模型“凭空”回答。当接收到用户查询时，首先会启动一个检索增强生成（RAG）流程。

• 流程：用户问题 -> 查询理解与向量化 -> 从企业专属知识库/文档库中检索最相关的片段 -> 将检索到的片段作为“证据”或“参考材料”，与用户问题一起拼接成新的提示词，交给大模型。
• 澜舟的工程细节：单纯的向量检索容易受语义相似度但内容不相关的影响。澜舟的实践中，通常会结合稀疏检索（如BM25）和稠密检索（向量模型）进行混合检索，取长补短。同时，会对检索到的文档片段进行重排序（Re-ranking），使用更精细的交叉编码器模型对相关性进行二次打分，确保喂给大模型的是最相关、最精华的信息。
• 关键提示：检索到的知识在提示词中的摆放位置和指令至关重要。常见的模式是：“请严格依据以下提供的信息来回答问题。如果信息中不包含答案，请直接回答‘根据已知信息无法回答该问题’。信息如下：[检索到的文档片段] 问题：[用户问题]”。

2. 结构化提示与思维链约束：通过精心设计的提示模板，引导大模型的思考路径，减少其“信马由缰”的可能。

• 分步指令：对于复杂任务，不是抛出一个问题，而是拆解成多个步骤。例如，对于数据分析任务，提示词可能是：“第一步，请识别用户问题中要求分析的指标。第二步，从提供的表格数据中提取相关数字。第三步，执行计算。第四步，用文字总结结果。” 这种思维链（Chain-of-Thought）引导，让模型的推理过程更透明、更可控。
• 输出格式约束：强制要求模型以特定格式（如JSON、Markdown表格、特定关键词开头）输出。这不仅便于后续程序化处理，也能在一定程度上规范模型的表达，减少冗余和编造。例如，要求“以JSON格式输出，包含answer和confidence两个字段”。

3.2 执行层：流程编排与实时干预

这一层确保任务按照预设的、可靠的流程执行，并在过程中可以插入检查和干预。

1. 智能体工作流编排：将复杂任务分解为由多个“智能体”协作完成的子任务流。每个智能体职责单一，并通过标准化接口（如函数调用）传递信息。例如，一个“合同审核智能体”可能由以下子智能体构成：

• 信息提取智能体：专门从合同中提取关键实体（甲方、乙方、金额、日期）。
• 条款合规智能体：将提取的条款与标准条款库进行比对。
• 风险提示智能体：基于比对结果生成风险报告。 这种分工降低了单个大模型任务的复杂度，每个环节的输入输出更明确，更容易验证，幻觉产生的范围和影响也被缩小了。

2. 工具调用与事实核查：赋予大模型调用外部工具和API的能力，让模型自己“动手查证”。这是解决动态信息和精确计算问题的关键。

• 场景：当用户问“今天纽约的天气如何？”时，智能体不是让大模型回忆训练数据，而是让大模型生成一个调用天气API的请求，然后将API返回的真实数据整合进最终回答。
• 澜舟的实践：他们会为智能体配备一个丰富的“工具包”，包括计算器、数据库查询接口、搜索引擎摘要API等。在流程设计中，会明确规定某些类型的查询必须强制使用工具。例如，涉及数值计算、实时信息查询的任务，提示词中会强调“你必须使用提供的计算器工具来完成运算”。

3.3 后处理层：输出校验与反馈学习

这是最后一道，也是至关重要的防线，用于捕捉和纠正前两层未能过滤掉的幻觉。

1. 多维度一致性校验：对模型的输出进行自动化的事实性和逻辑性检查。

• 内部一致性检查：检查长篇幅回答中，前后文是否存在矛盾。例如，前面说“成本上升了10%”，后面总结说“利润因此增加了”，这可能需要触发警报。
• 外部事实核查：对于回答中声称的、可验证的事实点（如具体数据、日期、引用来源），自动将其作为新的查询，反向调用RAG检索系统或可信知识库，验证该事实点是否存在支持依据。
• 规则校验：针对特定业务场景，编写业务规则校验器。例如，在金融报告中，校验“净资产收益率”的数值是否在一个合理范围内（如0%-100%），或者生成的SQL查询语句是否符合安全规范（避免DROP TABLE等危险操作）。

2. 置信度评分与不确定性量化：不是所有输出都值得同等信任。澜舟的框架会尝试为模型的每一次生成输出一个置信度分数。这个分数可能来源于多个方面：

• 模型自身的不确定性：有些大模型本身能输出每个token的生成概率，低概率序列可能意味着模型“心里没底”。
• 检索证据的支持度：最终答案与检索到的参考文档之间的语义匹配程度。
• 校验环节的通过率：通过了多少项一致性检查和规则校验。 当置信度低于某个阈值时，系统可以自动触发人工审核流程，或者直接向用户提示“此回答的确定性较低，建议您进一步核实”。

3. 闭环反馈与迭代优化：所有被人工纠正或用户标记为错误的回答，都会被收集到一个“错误案例库”中。这些案例有两个核心用途：

• 提示词优化：分析幻觉产生的模式，反推是不是提示词设计有漏洞，进而迭代优化提示模板。
• 检索器优化：如果幻觉是因为检索到了错误或不相关的文档导致的，那么这些案例可以用来优化检索模型（通过微调或改进排序算法），提升知识检索的准确性。 这个闭环使得智能体系统能够像人一样，从错误中学习，不断进化其“可信”能力。

4. 工程化实践中的关键决策与避坑指南

将上述技术栈落地，远非简单的组件堆砌。在实际工程中，我们面临大量权衡和选择。以下是一些从实践中总结的关键决策点和常见陷阱。

4.1 知识库构建：质量远大于数量

很多团队一开始就陷入“知识库越大越好”的误区，盲目导入大量未经处理的文档，结果导致检索精度急剧下降，噪音信息引发更多幻觉。

• 正确做法：优先构建“小而精”的高质量核心知识库。这意味着：
  • 严格的源头管控：只录入经过权威审核、来源可信的文档。
  • 深度的预处理：不仅仅是文本提取。应对文档进行结构化解析（识别标题、段落、表格）、实体识别与链接（将文档中的人名、产品名、术语标准化）、关键信息摘要。为文档打上丰富的元数据标签（如文档类型、适用部门、生效日期）。
  • 分片策略：文档切片（Chunking）不是简单按字数切。要按语义切分，确保每个切片是一个完整的语义单元（如一个章节、一个问答对、一个表格）。澜舟常采用递归式分片，先按大标题分，再在段落内按句子或固定长度微调，并结合重叠（Overlap）策略避免上下文断裂。
• 避坑提示：警惕非结构化文档中的“隐性知识”。比如一份产品手册的修订记录，可能以注释形式存在，简单的文本提取会丢失。必须设计专门的解析器来处理这类情况。

4.2 RAG检索的精度与召回平衡

检索是RAG的基石，检索不准，后面的大模型再强也白搭。

• 混合检索的必要性：向量检索（稠密检索）擅长语义匹配，但可能召回一些“意思对但词不沾边”的无关文档。关键词检索（稀疏检索）擅长精确匹配字面，但无法处理同义词和抽象查询。混合检索并用重排序模型精排，是目前工业界的标准做法。
• 查询重写与扩展：用户的原始查询可能很模糊。在检索前，可以先用一个小模型（或大模型本身）对查询进行重写和扩展。例如，将“怎么报销？”扩展为“员工差旅费用报销流程、所需单据、提交系统及审批时限”。这能极大提升检索的召回率。
• 避坑提示：重排序模型虽然效果好，但会显著增加延迟。需要根据业务对实时性的要求，决定是在全量检索结果上做重排，还是只对Top K（如Top 20）的结果做重排。同时，重排序模型本身也需要领域数据微调，否则效果可能不佳。

4.3 提示工程：从艺术到科学

提示词设计不再是“玄学”，而是有章可循的工程。

• 系统指令（System Prompt）的稳定性：定义智能体角色、行为准则和知识范围的系统指令必须稳定、明确、无歧义。这部分应作为代码的一部分进行版本管理，任何修改都需经过测试。
• 少样本示例（Few-Shot）的威力：在提示词中提供1-3个高质量的输入输出示例，对于规范输出格式、教会模型处理复杂逻辑有奇效。示例必须精准，且覆盖关键场景。
• 思维链（CoT）的自动化：对于标准化任务，可以预先定义好思维链的步骤模板，通过程序自动将用户问题和知识填充到模板中，形成最终提示词，而不是每次都让大模型“从头思考”。
• 避坑提示：避免提示词过长导致有效上下文被压缩。要定期清理对话历史中无关的上下文。对于超长文档，可以采用“Map-Reduce”策略：先让模型对多个文档切片分别总结（Map），再对总结进行汇总（Reduce）。

4.4 验证与评估：如何知道它真的“可信”了？

上线前，必须建立一套可量化的评估体系。

• 超越人工评测：不能只靠几个人看几个例子就下结论。需要构建一个覆盖核心场景的测试集，包含标准问题和期望答案（或答案的关键要点）。
• 设计自动化评估指标：
  • 事实一致性（Factual Consistency）：使用NLI（自然语言推理）模型或专门的事实核查模型，判断生成答案与提供的参考文档是否在语义上一致。
  • 答案相关性（Answer Relevance）：评估答案是否直接回应了问题。
  • 幻觉率（Hallucination Rate）：在测试集上，统计模型产生无依据陈述的比例。
  • 工具调用准确率：对于需要调用工具的任务，统计其正确生成工具调用参数的比例。
• 实施红队测试（Red Teaming）：主动设计一些“刁钻”的问题，如诱导性问题、包含矛盾信息的问题、涉及知识盲区的问题，来测试智能体的抗幻觉能力和拒绝回答（知道就说知道，不知道就说不知道）的机制是否健全。
• 避坑提示：自动化评估指标本身也有局限性，它们只是代理指标（Proxy）。最终必须结合关键场景的人工深度评估和上线后的线上A/B测试与用户反馈，形成综合判断。

5. 成本、性能与可信度的三角权衡

工程化永远是在约束条件下寻求最优解。可信智能体的构建，始终围绕着成本、性能（延迟、吞吐）和可信度这三个顶点进行权衡。

• 大模型选型：最强的闭源模型（如GPT-4）通常事实性和逻辑性更好，但成本高、延迟可能较大。优秀的开源模型（如Llama 3、Qwen系列）成本低、可私有化部署，但可能需要更精细的提示工程和RAG框架来弥补其在某些复杂推理上的不足。选择时需平衡业务对准确率的苛刻要求与预算限制。
• RAG与微调的取舍：RAG灵活性高，知识更新快（改知识库即可），但每次查询都涉及检索，增加延迟。微调（Fine-tuning）可以让模型更“懂”你的领域术语和任务格式，响应更快，但知识更新麻烦（需要重新训练），且对解决事实性幻觉帮助有限。通常建议：用RAG解决知识性、事实性问题；用微调解决风格、格式和常见任务流程问题。两者可以结合使用。
• 校验环节的开销：每一层校验（一致性检查、规则验证、置信度计算）都意味着额外的计算和时间开销。需要在关键业务路径（如合同审核）和非关键路径（如内部知识问答）上采取不同的校验强度。可以采用分级策略：高置信度回答直接返回；中置信度回答进行快速校验；低置信度回答触发完整校验链或人工审核。
• 缓存策略：对于频繁出现的、答案固定的常见问题（FAQ），完全可以绕过整个复杂流程，直接使用缓存的结果，这是平衡性能与成本最有效的手段之一。

构建可信智能体，没有一劳永逸的解决方案。它更像是一个持续运营和迭代的系统工程。澜舟的框架给出了一个清晰的蓝图：通过知识增强、流程控制、结果校验构建多层防御，并通过数据反馈不断优化每一个环节。其核心思想是承认大模型的不完美，然后用系统工程的方法为其构建“护栏”和“校正仪”。

在实际操作中，我的体会是，启动时不必追求大而全。可以从一个具体的、高价值的业务场景切入，比如“根据产品手册回答客户技术问题”或“从财报中提取关键指标”。针对这个场景，深入实践RAG流程的每一个环节——从知识库构建、检索优化到提示词设计，并建立一个最小化的验证闭环。把这个场景做深、做透，让智能体在这个领域真正达到“可信”的标准，其积累的方法论、工具链和经验，远比一个泛泛而谈的、全能的但不可靠的聊天机器人有价值得多。可信，是智能体从技术演示走向生产应用的生死线，而跨过这条线，需要的是严谨的工程思维和持续的精细化运营。