一种架构，其中 LLM 生成答案，然后通过一个单独的验证步骤，使用检索来检查并纠正它，这种架构在创造性和准确性之间提供了平衡，但也引入了复杂性和性能之间的权衡。 该方法首先让 LLM 生成响应，然后使用检索系统（如数据库或外部知识来源）来验证事实、填补空白或纠正错误。 这种两步流程可以提高可靠性，但需要仔细设计以管理开销并确保连贯性。
主要优势是提高准确性和可信度。 LLM 经常生成听起来合理但不正确或过时的信息，尤其是在小众主题方面。 基于检索的验证层可以根据可信来源交叉检查声明。 例如，如果 LLM 声明“Python 3.12 引入了 X 功能”，则验证步骤可以查询官方文档以确认或将该声明替换为正确的详细信息。 这在医疗保健、金融或技术支持等领域尤其有用，在这些领域中，错误会产生实际后果。 此外，将生成和验证分开可以独立优化每个组件——例如，使用较小的、更快的 LLM 进行初始响应，并使用专门的检索系统进行验证。
但是，这种架构增加了复杂性和延迟。 运行两个连续的步骤——生成，然后检索——会减慢响应时间，使其不太适合聊天机器人等实时应用程序。 开发人员还必须管理组件之间的同步。 例如，如果检索系统更正了 LLM 答案中的日期，但未能更新相关上下文（例如，移动事件时间线），则最终响应可能会变得不一致。 维护成本也会上升：检索系统的数据必须保持最新，并且边缘情况（例如，冲突的来源）需要解决逻辑。 实现不佳的验证步骤甚至可能引入错误，例如使用过时的检索结果覆盖正确的 LLM 输出。
是否使用这种方法取决于用例。 当准确性至关重要且延迟可以容忍时，它很有价值，例如生成技术文档或法律摘要。 但是，对于需要即时响应的应用程序（例如，游戏 NPC 对话），开销可能会超过好处。 开发人员还应该考虑混合策略，例如异步运行验证或使用检索增强生成 (RAG) 来混合这些步骤。 测试是关键：测量错误率、延迟和用户满意度，以确定增加的复杂性是否证明了可靠性的提高。
