文章核心观点 - AI Agent在生产环境的部署失败率高达95%，主要瓶颈并非模型智能度，而是上下文工程、安全性、记忆设计等基础设施的缺失[2][3] - 成功的AI产品开发核心在于构建复杂而强大的“上下文选择系统”，而非简单的提示工程[3] - 行业即将迎来一波专注于记忆工具包、编排层、上下文可观测性等基础设施工具的浪潮[49] 上下文工程 - 精细调整模型的需求非常少见，设计完善的检索增强生成系统通常已能满足需求，但大多数现有系统设计过于初级[5] - 先进的上下文工程是为大语言模型量身打造的特征工程，需实现可版本化、可审计、可测试[9][10] - 应采用语义与元数据双层架构，统一处理杂乱输入格式，确保检索到的是高度相关的结构化知识，而非仅是相似内容[11][12] - 文本转SQL系统在生产环境部署挑战巨大，成功团队会构建业务术语表、带约束的查询模板、验证层及反馈循环作为支撑[13][20] 安全与信任机制 - 安全性、溯源能力与权限控制是阻碍系统部署的关键障碍，而非可有可无的功能[14] - 系统必须支持基于角色的行级别访问控制，即使问题相同，也需为不同权限用户提供定制化输出[16][21] - 信任的核心在于系统能否表现出一致、可解释、可审计的行为，而非原始技术能力[18] - 5%成功部署的AI Agent共同点是采用“人在回路”设计，将AI定位为辅助工具，并构建反馈循环[18] 记忆功能设计 - 记忆功能不是简单存储，而是涉及用户体验、隐私和系统整体架构的设计决策[22] - 记忆应分为用户级、团队级和组织级三个层级，优秀团队会将其抽象为独立的上下文层与行为层，实现版本化与自由组合[23][28] - 记忆能提升用户体验与Agent流畅度，但过度个性化会触及隐私红线，共享记忆若范围不当会破坏访问控制[30][34] - 当前技术栈缺失安全、可移植、由用户掌控的内存层，这是一个重要的创业机会点[30][42] 多模型推理与编排 - 模型编排是一种新兴设计范式，企业根据任务复杂度、延迟要求、成本敏感度等因素设计智能路由逻辑[31][32] - 典型模式包括：简单查询调用本地模型、结构化查询调用领域特定语言、复杂分析调用前沿模型，并采用双模型冗余设计作为回退[35][36] - 模型选择本身可通过追踪“哪些查询在哪些模型上表现更好”来持续学习优化，路由策略需自适应而非手动调整[37] 交互界面设计 - 并非所有任务都需要聊天机器人，自然语言交互的价值在于极大降低复杂工具的使用门槛[39] - 理想应用场景包括处理情绪化任务和进行探索性、开放式的查询[40][46] - 核心是理解用户选择自然语言的根本原因来设计交互，而非将所有交互塞进聊天框架，并应提供GUI控件支持后续精细化调整[40] 未来机会与待解问题 - 重要创业机会点包括：上下文可观测性、可组合记忆、领域感知的领域特定语言[41][42][44] - 善用延迟可创造价值体验，深度分析即使耗时10秒，只要展示思考过程并给出有效答案，用户也能接受[45] - 生成式AI的下一个护城河将源于上下文质量、记忆设计、编排可靠性和信任体验四方面[50][51]

背景介绍 - RAG（检索增强生成）方法结合了检索模型和生成模型的能力，以提高生成文本的质量和相关性 [1] - 该方法由Meta在2020年提出，让语言模型能够获取内化知识之外的信息，并以更准确的方式回答问题 [1] - 在大模型时代，RAG用于解决幻觉问题、知识时效问题和超长文本问题等大模型本身的制约或不足 [1] RAG的挑战 - 主要面临三个方面的挑战：检索质量、增强过程和生成质量 [2] - 检索质量方面存在语义歧义、用户输入变复杂、文档切分和多模内容提取等挑战 [5] - 增强过程面临上下文集成、冗余和重复、排名和优先级等挑战 [5] - 生成质量方面存在过度依赖检索内容、无关性、毒性或偏见等问题 [5] 整体架构 产品架构 - 包含模型层、离线理解层、在线问答层和场景层四层 [11] - 模型层支持自研序列猴子、开源大模型和第三方模型，并优化跨语言Embedding模型 [11] - 离线理解层包括智能知识库和搜索增强模块，负责非结构化文本处理和检索精准度 [11] - 在线问答层支持多文档、多轮次、多模态及安全性与拒识等功能 [11] - 场景层针对不同行业特点预制多种场景类角色 [11] 技术架构 - 分为query理解、检索模型和生成模型三个主要组成部分 [10] - query理解模块包括query改写、扩写和意图识别等，旨在提高召回率 [12] - 检索模型从文档集或知识库中检索相关信息，使用信息检索或语义搜索技术 [12] - 生成模型根据Prompt或上下文生成新内容，包括chat系统和Prompt优化等 [13] Query理解 - 引入query理解模块解决用户query措辞不利于检索和生成结构化查询的问题 [14] - 意图识别模块利用LLM实现决策功能，可应用于选择器模块或查询引擎 [15] - query改写模块利用LLM重新措辞用户query，提高检索效果 [16] - HyDE技术生成假设答案并转换为嵌入，从数据库中检索最接近的实际文档 [17] - query扩写模块将复杂问题拆解为子问题，采用分而治之的方法处理 [22] - Step-Back Prompting通过抽象和推理两步处理复杂任务 [23] - CoVe技术通过验证和完善回答提高大型语言模型答案的可靠性 [25] - RAG-Fusion生成多个query并行执行搜索，使用倒数排名融合重新排序 [27] - ReAct将复杂查询分解成更简单的子查询，结合思维链提示和Action计划生成 [29][31] - query重构模块通过一次请求实现改写、拆解和拓展用户输入 [32] 检索模型 挑战 - 依赖于Embedding模型的向量化是否准确 [33] - 相关信息出现在输入上下文开头或结尾时性能最高，中间性能明显下降 [34] 架构 - 包括文档加载器、文本转换器、文本嵌入模型、向量数据库和索引等组件 [35][37] 文档加载器 - 从配置源加载文档数据，支持懒加载和多种来源如txt文件、网页和YouTube视频 [38] 文本转换器 - 将大型文档分割成较小块，适应模型上下文窗口 [39] - 递归分割文本保持相关文本片段在一起 [40] - 常见类型包括HTML、Markdown、Code、Token和Character等 [43] - 使用Chunkviz工具评估文本转换器工作情况 [44] 文本嵌入模型 - 创建文本的向量表示，捕捉语义并支持语义搜索 [45] - 应具备跨语种检索、长原文和短摘要关联、不同表述相同语义关联等能力 [45] 向量数据库 - 支持嵌入式的高效存储和搜索，检索与嵌入查询最相似的嵌入向量 [47] 索引 - 摘要索引将节点存储为顺序链，支持顺序遍历或基于关键词过滤 [51] - 树索引构建层级树状结构，父节点是子节点的摘要 [53] - 关键词表索引提取关键词并构建多对多映射 [55] - 向量索引利用文本嵌入模型将文本块映射成向量并存储在向量数据库中 [57] 排序和后处理 - 基于相似度分数、关键词、LLM重新排序或时间进行过滤和排序 [59] 生成模型 - 回复生成策略包括依次结合相关文本块修正回复或在Prompt中填充多个文本块 [66] - prompt拼接策略包括字符串提示和聊天提示 [61] - 字符串提示连接模板，聊天提示由消息列表组成 [62][63] 插件 - 基于混合演示检索的上下文学习方法融合文本检索和语义检索进行多路召回 [64] - 检索模块包括文本检索和语义检索，分别采用BM25和双塔模型 [70] - 重排模块使用倒序排序融合算法和两端填充排序策略 [71] - 生成模块设计prompt组装模块，融入长期和短期对话记录 [72] 引用或归因生成 - 归因让模型生成内容与参考信息对齐，提供证据来源确保信息准确性 [73] - 模型生成方法直接让模型生成归因信息，依赖模型能力 [75] - 动态计算方法在流式生成时匹配语义单元和参考源 [76] 评估 - Faithfulness评测生成的回答是否忠实于contexts，避免幻觉 [79] - Answer Relevance评测生成的答案是否解决实际问题 [79] - Context Relevance评测检索的上下文是否重点突出且少含无关信息 [79] - RGB基准研究RAG对大型语言模型的影响，分析噪声鲁棒性、拒答等能力 [77] - RAGAS框架对RAG pipeline进行无参考评估，考虑检索系统和LLM能力 [81] - LlamaIndex提供衡量生成结果质量和检索质量的模块 [81] 总结 - RAG技术需要不断实践和研究才能打磨出符合企业应用的精品 [82] - 本文总结了过去一年在RAG实践的关键模块，属于大纲式技术普及文章 [82]