AI自信答错，问题未必出在LLM本身

构建一个可靠的 AI 应用，远比写一条“好提示词”复杂得多。一位开发者在打磨品牌营销文案生成系统时发现：模型信誓旦旦给出的错误答案，根源可能压根不在模型身上。

一个营销文案系统暴露的三层问题

设想一个典型场景：系统基于品牌知识库自动生成营销文案。要让输出真正可用，至少三个环节必须同时在线。

品牌上下文（Brand context）——AI 是否真正理解品牌调性、目标受众与市场定位？

检索（Retrieval）——系统有没有从上传的文档中捞出正确的信息？

生成（Generation）——LLM 是否正确地使用了这些信息？

这三层任何一层出问题，最终答案都可能是错的。但麻烦在于，从用户视角看，错误答案长得都一样。

为什么“改提示词”常常治标不治本

调试的难点恰在这里。如果系统检索到了错误信息，优化提示词基本无济于事——模型拿到的是错的原料，再好的厨艺也做不出对的菜。

反过来，如果正确的信息已经送进 LLM，答案依然是错的，那问题可能出在模型对上下文的利用方式上，比如指令跟随、上下文窗口内的注意力分配，或者输出格式约束。

两种故障的表现相似，修复路径却完全不同。盲目改 prompt，很可能只是在错误的地方反复试错。

RAG（检索增强生成） 是当前构建可靠 AI 应用的主流架构范式，其核心思路是在 LLM 生成答案之前，先从外部知识库中检索相关文档片段，将检索结果作为上下文一并送入模型。RAG 之所以重要，是因为它让模型能够回答训练数据之外、或实时更新的领域问题，而不必重新训练。但 RAG 也引入了一个关键的工程挑战：系统的输出质量不再仅由模型决定，而是由「检索质量 × 上下文组织 × 生成忠实度」共同决定。任何一个环节出错，最终答案都可能看似合理却事实错误。这正是文中强调「三层问题」的技术背景——RAG 把单点问题变成了流水线问题，调试难度随之上升。

先定位故障层，再谈修复

这位开发者总结出的关键经验只有一句：在修复答案之前，先搞清楚系统在哪里出了错。

这本质上是一种分层调试思路。把 RAG 流水线拆成可观测的环节，分别检查检索命中率、上下文相关性、生成忠实度，才能把“幻觉”这个笼统的标签拆解成具体可修的问题。

这也是他持续深入 RAG、评估（evaluation）与可靠 AI 应用构建的原因。评估不是锦上添花，而是定位故障的必要手段。

生成忠实度（faithfulness） 是评估 RAG 系统时最核心的指标之一，衡量的是模型输出是否忠实于所提供的上下文，而非依赖自身参数化知识「编造」。与之相关的还有上下文相关性（context relevance） 和答案相关性（answer relevance），三者共同构成 RAG 评估的经典三角框架（如 RAGAS 等评估工具所采用）。检索命中率关注「有没有捞对文档」，上下文相关性关注「捞出来的内容是否切题」，生成忠实度则关注「模型是否老老实实用了这些内容」。将幻觉笼统归因于模型，往往掩盖了检索层或上下文组织层的真实病灶。建立分层指标，才能把「答案错了」这一模糊现象拆解为可定位、可量化、可修复的具体问题。

检索、幻觉还是输出不稳定？

文章末尾抛给 LLM 开发者一个问题：你遇到的最大挑战是检索、幻觉，还是输出不一致？

三者其实对应着不同的工程层次。检索问题属于数据管道，幻觉更接近生成阶段的忠实度问题，输出不一致则往往牵涉采样策略与系统稳定性。把它们混为一谈，调试效率会大打折扣。

对正在构建 RAG 系统的团队来说，先建立分层可观测性，再谈优化提示词，或许是更务实的路径。