关于 RAG、AI Agent、多模态，我们的理解与探索

这次交流的主题是“Agent”，但Agent并非独立存在，而是依赖于其他技术的融合。先说私域数据，它对Agent来说，承载的是输入源的处理。如果输入源处理不好，Agent的性能自然会打折扣；其次，Agent技术基于大模型，大模型能力越强，Agent的表现就越稳定。当然，Agent也有短板，比如增加系统延时——这个问题可以通过语义缓存来缓解。另外，无论是基于Agent还是AI的其他新技术，都给测试带来了全新的挑战。 ### 私域数据的分割、召回与评估 私域数据主要解决两个问题。**首先是如何有效地将企业数据输入大语言模型。** 大语言模型的上下文处理能力是有限的，所以需要智能地选择数据来适应这个限制。其次，即便能把全部数据塞进上下文，也未必是最好的选择——**最新的研究显示，大模型在处理上下文数据时效率呈U型曲线**，全量数据输入反而可能拖累效果。 从RAG的宏观层面来看，可以分成两步。**第一步是把数据化整为零存入数据库**；第二步则是**从数据库中进行召回**，召回的结果作为LLM的上下文输入。这个分割过程，本质上是将M个文件或文档映射成N个Embedding。分割策略有很多种：分隔符分割、均匀分割，甚至更复杂的以文档或段落为单位的竖结构。这里主要考虑三个因素：**分割的颗粒度**，以及**分割作为前置步骤的影响**——因为它会直接影响后续召回模块的性能。 召回环节在RAG系统中至关重要，核心包括三个方面：首先，必须遵循大语言模型（LLM）要求的上下文硬性约束，即把n个Embedding与单个上下文建立多对一的有效映射关系。其次，要尽量在召回过程中保留原始上下文信息的完整性，避免信息失真。再者，要确保拼接生成的上下文语义连贯、流畅，否则任何语境上的不连贯都可能干扰LLM的理解，引发各种潜在问题。此外，在这个模块中，还可以巧妙借助LLM来提升或辅助召回效果。 召回模块主要包含检索、排序与生成三大功能，并且可以根据实际需要决定是否启用生成模块。这些功能都可以通过小模型或大语言模型进行优化。在检索环节，虽然普遍采用向量检索法，但某些场景下它的性能可能不够稳定。以我们实践为例，用OpenAI的Ada embedding做向量检索时，特定场景下效果并不理想。为了提升检索效率和准确性，可以尝试多种策略：先用向量做初步筛选（粗排），再用大语言模型（如LLM）或其他专业模型做精细排序（精排）；或者整合传统检索技术如BM25，构建混合检索体系。更先进的方法如HYDE也值得关注——它不直接用用户原始查询去检索，而是先让LLM对查询语句进行加工，再用加工后的答案作为检索依据，从而实现更精准的信息检索。 在排序环节，除了考虑语义相似度，还需要综合看**相关性、时效性和重要性**。排序模块本身也可以使用专门的排序模型。最后是生成模型，这是可选的，用于在获得片段后生成更流畅的上下文，有时会调用LLM进行润色。 针对RAG（Retrieve-And-Generate）模型的评估，我们可以把指标分成三类： 1. **传统检索指标**：比如MMR和NDCG，虽然广泛应用于衡量检索系统的输出质量和排序效果，但在评价RAG这类新型检索生成模型时，因为无法全面反映检索性能，存在局限性。 2. **端到端测试**：在早期阶段，当各组件性能还不够完善时，可以把RAG与语言模型（LM）作为一个整体系统来评估，通过用户查询和标准答案对比来衡量LM生成的答案质量。但这种测试方法的问题在于难以精准定位改进点——也就是说，很难分清是RAG检索能力不足，还是LLM回答问题能力欠佳，评估方式比较粗略。 3. **创新的RAgas方法**：引入了一种新策略，即利用高度智能化的LLM作为评估工具，能够细致地评判上下文与问题、答案与上下文、答案与问题之间的相关性，提供更深入、准确的评估结果。相比前两种，这个方法有可能减少对人工标注的依赖，实现有效且精细的端到端测试。 **召回方法、数据分割大小和Top-k选择**是影响RAG性能的关键超参数，需要通过实验调优来确定最佳设置。有时候，基于向量空间的搜索可能不够精确，这时结合BM25算法能有效提升搜索准确性。 在排序方面，RAG系统输出的排序结果与后续调用的大型语言模型（LLM）紧密相关。不同LLM对排序敏感度的差异很明显。例如，仅解码器（Decoder only）架构的LLM，像Google的PaLLM2，对排序顺序的依赖度比GPT-4更高，排序误差可能导致PaLLM处理失败，而GPT-4则相对容错。为了提升系统性能，可以用Prompt Engineering技术，让查询（Query）同时出现在上下文的前部和后部。最终，召回阶段的排序考量不应只限于语义相似度，而需要综合多维度因素进行优化。 ### AI Agent AI Agent，也可以比喻为“角色框架”，是一种编程范式，核心在于给大型语言模型（如LLM）赋予一种解决问题的策略性思维结构。这个框架模拟了人类处理问题的流程：角色设定模块对应环境背景的理解与认知；规划模块负责任务拆解与策略制定；内存模块承载自我状态的操作与管理；动作模块执行最终的决策行为。尤其突出的是，AI Agent通过这种架构，让在LLM环境中实现群体智能的模拟与构建成为可能，为那些研究群体智能编程的开发者提供了很大便利。 在没有Agent介入时，用户的查询与外部知识一起输入LLM，由它直接生成答案；但引入Agent后，它可以在响应前进行策略规划，并在完成后独立解决相关子任务，或者调用人类预设的工具资源，从而构建一个涵盖规划、执行及反馈的智能决策循环。 说到规划模块，可以把AI Agent分为两种架构：开环系统与闭环系统。开环系统的特点是当前行动步骤的结果不会影响后续规划——比如思维链就是典型的开环系统，因为它遵循线性执行路径且没有反馈机制。相比开环系统，更先进的技术是多路径系统，这种设计灵感来自人类解决问题时会从多个角度思考。其中，self-consistency策略特别关注当多种不同思路可能导向相同结论的情况。但需要注意的是，有一种在开环系统中频繁调用LLM的方法，根据实践观察，性价比相对较低——反复调用LLM会导致成本和响应时间上升，相比之下，直接采用闭环系统更高效。 AI Agent本质上是一个闭环系统，它的每个规划步骤都会受到之前步骤的影响。这种闭环性质意味着Agent会多次调用大型语言模型（LLM），并且对内存的管理也更复杂。以下是几个代表性的闭环系统实例： 1. **Self ask**：基于Chain of Thought（COT）理念，加入了一系列后续问题，实现闭环。 2. **ReAct**：作为典型的闭环系统，挑战在于进行局部规划时，可能会逐渐偏离最初目标，导致目标遗忘。 3. **Plan & Solve**：与ReAct相似，但一开始就由LLM进行全局规划，减少了目标漂移的可能性。 4. **Reflection**：特别注重内存操作的细化，区分短期记忆和长期记忆，每类记忆被不同角色使用，有助于实现群体智能。这种方法因为内存操作的复杂性而独树一帜——内存的形态决定了编写prompt的方式，无论是向量、字符串还是SQL数据库形式。 处理内存时，主要关注三个方面：内存内容的检索、数据去重以及内存满载时的数据简化。内存类型差异影响编程策略，所以这个环节至关重要。行动模块大致可分为两类函数执行方式：一类由人类编写，有严格定义的API与输入参数；另一类直接调用LLM自身的能力，函数调用相当于自我引用。在函数选择过程中，虽然借鉴了RAG的部分思路，但有所不同——RAG中的函数排序基于算法和相似度标准，通常不能随意调整；而在我们的系统中，如果没有特定优先级设定，函数排序是可变的，实践证明调整排序顺序对性能有帮助。然而，在实际应用中，行动模块在调用人类编写的函数时可能遇到异常情况。这类函数要求固定且结构化的输入，与LLM产生的非结构化字符串输出之间需要进行转换，比如转化为JSON或字典格式。这个转化过程容易出现错误，比如括号缺失等问题。同样，函数返回结果的结构化处理也是挑战，要确保它能够被有效利用于人类函数和LLM函数的交互，而不是局限在LLM内部循环。目前，这个模块在鲁棒性上还有缺陷。好消息是，GPT-4-Turbo在JSON格式生成的稳定性上有所提升。 在评估Agent时，存在三种核心评估策略。首先是针对冷启动阶段的评估——这时缺乏充足的数据和经验，可以通过人工评分或图形测试等方式进行评价，基准对比主要包括向下对齐（对比启用Agent前后的效果差异）和向上对齐（与人类表现相比较）。 在积累一定数据后，Agent的评估会根据应用场景的具体需求而定。例如，在文档自动化场景下，针对分类任务或关键信息抽取任务，可以采用端到端固定指标来衡量Agent带来的性能提升。 而在评估Agent的泛化能力时，常利用Alfworld、HotpotQA、FEVER、HumanEval等经典数据集，它们涵盖了对决策制定、多跳问答、分类及编码等多种能力的考察。现在的趋势倾向于把Agent当作LLM来评估，广泛采用清华大学提供的Agent Bench和Tool Bench等综合型数据集进行测试。 至于Agent的工程性能评估，关键考量指标包括**平均错误率**以及在执行同样任务时，比较两个Agent的**平均LLM调用次数**来洞察成本效益。此外，**延时**也很重要——因为即使调用次数相近，频繁的小规模调用与一次大规模调用可能会带来不同的响应延迟。 经过多框架对比测试，Plan & Solve方法表现出最佳性能。但三个闭环系统的共性问题在于工具选择阶段容易出错，针对这个问题，可以通过随机化工具列表来规避LLM在处理上下文时可能出现的U型曲线偏差。 在工程编码实践上，首选方案是用Lang chain技术进行Agent的首轮迭代开发，因为它实现速度快、初步构建效果好。但需要注意，Lang chain架构存在隐忧——可能产生冗余代码，而且各版本间变化较大，后期维护和扩展性可能成为难题。 此外，Marvin库在整合人类定义函数与大型语言模型（LLM）函数的应用中展现了独特价值。它通过简洁清晰的接口设计，有效降低了LLM函数编程的复杂度，提升了集成效率。 ### 多模态 现在聊聊Agent，特别是基于底座大模型的Agent，当前最热门的话题就是这些模型的多模态能力。在文档智能领域，我们尝试了一些多模态模型，尤其是针对文字密集型文档。我们想知道现有的原生多模态模型能力如何，能不能省去OCR这一步。因为OCR过程非常繁琐——如果用纯文本LLM处理文件自动化，通常要先做OCR。OCR之后，还需要做文本序列化，而这一步很难泛化。例如，有一个表格，表头按一定格式排列，但如果这个表格信息没有正确传入LLM，按照人类从上到下、从左到右的阅读顺序处理，表头的识别就会完全错乱。这种错误会对后续的信息提取和性能产生很大影响。 传统提升模型性能的策略常依赖于模型堆叠，但这会增加系统复杂度与延迟，并没有根本解决泛化性问题。因此，研究者开始探索多模态融合技术。其中，一种典型的方法是将图像或文档经过encoder转化为向量表示，再通过adaptation技术将其映射到大语言模型（LLM）的空间中进行处理，这一系列过程被称为“高效微调”。 这类高效微调技术如Lora、LLAMA、adept和prompt tuning等，虽已取得一定成效，但也存在局限性。首先，这类方法在闭源API环境下难以应用，只能在开源系统中实施。其次，研究表明，在信息提取任务上，这些方法的表现并不理想，尤其是在处理文字密集型文档时。原因在于，当前图像encoder的分辨率普遍较低，而且不是多尺度设计——常见分辨率只有338x338，导致提取高密度文字信息时，大量信息因为分辨率不足而丢失。此外，这种微调方式并非端到端训练，而是采用两阶段微调机制，这也可能影响性能。 在OCR领域，华中科技大学的研究成果很突出。针对信息提取任务中多模态模型在KIE（关键信息抽取）上的不足，近期涌现的一些新型多模态模型提供了新的解决思路。比如Facebook的Nougat模型等小型多模态seq2seq结构模型，通过将图像信息转化为HTML或Markdown源码，有效缓解了序列化难题——因为它保留了二维布局信息。 这类模型可以对接开源或闭源的大语言模型（LLM），通过前端训练和微调实现应用。此外，部分高分辨率的预训练开源模型也展现出优势。但它们的问题在于，许多预训练模型基于学术论文数据集训练，主要对应LaTeX格式，而面对商业文档时，HTML标签识别难度较高，导致标注成本增加。 ### 语义缓存技术 在多模态研究中，为应对Agent提升时延的问题，引入了一种叫“语义缓存”的策略，这项技术显著降低了调用延迟，实现了一个数量级以上的优化。语义缓存本质上是一种工程实践，与现有的绝对匹配缓存机制（如KV cache）相融合。当绝对匹配未命中时，系统运用向量数据库进行语义层面的检索，并结合元数据及置信度top k筛选来判断缓存是否有效。在这个过程中，如果命中，会在eviction manager中进行记录。 不过，在使用语义缓存技术时，必须留意它内在的权衡特性：**缓存命中率与搜索精确度之间存在着动态平衡**。高命中率可能导致精确度一定程度的下滑——因为这涉及概率性问题，需要找到合适的操作点。 此外，我们力求利用元数据对搜索结果进行精细化过滤。例如，面对相同查询但在不同来源渠道（比如APP端与网页端）下可能出现差异化的响应，这就凸显了**属性过滤功能**的重要性。为此，建议采用兼容Hyperd search的向量数据库，这样在调用时可以自动执行这类精细化处理。 在采用语义缓存时，必须重视缓存一致性问题。特别是在企业环境下，如果KV cache与向量数据库由不同团队管理，可能会出现TTL配置失误等情况，导致缓存数据不一致，使用户接收到错误结果而系统无法有效记录。此外，确保并行化处理的安全性也很重要——例如eviction manager应具备线程安全性，以保证系统稳定高效运行。 实现语义缓存的目标在于构建统一的缓存架构，这意味着在数据库中只保存一份缓存副本，而不是多份。为此，需要自上而下进行精心设计，包括精确定义key、规划表结构，并明确与eviction manager交互的角色。 对于初次涉足向量数据库或语义缓存应用的开发者，推荐一款名为GPTCache的开源库，它支持多种向量数据库与其他数据库的整合对接，有助于简化操作流程，提高开发效率。 在当今Agent与LLM技术广泛应用的时代，客服机器人的测试面临着更高的复杂性和挑战。除了确保业务问题解答的准确性，还需要严防它回复非相关问题，以免损害公司形象与声誉。针对Agent的测试流程中，我们需要预先设定并强化合规性规则。即便如此，即便采取多重约束，Agent仍可能出现非预期回复，这时可能需要借助小型模型对LLM输出结果进行过滤，以防止潜在违规内容的出现。同时，有效识别和规避用户的越界行为，尤其是检测模型生成内容中的幻觉现象——这个问题至今尚无理想的解决方案，亟待业界共同探索。 从评测角度看，传统的依赖人工标注的测试方式已经无法满足需求，有必要开发专门的自动打分模型，或者运用高性能LLM作为评判者角色，通过Agent机制参与测试过程，专注于对hallucination、groudness等问题的评估。以上是对Agent测试挑战及应对策略的概述。