AG、AI Agent与多模态：从理论到实践的全面解读

最新推荐文章于 2024-09-02 10:31:45 发布

程序员鑫港

最新推荐文章于 2024-09-02 10:31:45 发布

阅读量1.1k

点赞数 12

文章标签：人工智能语言模型 AI编程职场和发展 ai

本文链接：https://blog.csdn.net/a2875254060/article/details/138719314

版权

引言

在这个快速发展的数字时代，生成式 AI 不仅仅是一个概念，而是正在被塑造成为未来技术生态系统的核心。随着 LLM 的崛起，我们正处于一场技术革命的前沿。在 QCon 上海站上，王元讲师从构建企业级智能问答机器人方面的实战经验入手，深入分享了私有数据的接入、代理框架的运用，到多模态实践、语义缓存技术等 LLM 的新技术与新实践。本文为演讲整理文～

这次交流的主题是“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 处理后的答案作为检索依据，从而实现更为精准有效的信息检索。

在排序环节，除了考虑语义相似度外，还需要综合考虑**相关性、时效性和重要性。**排序模块也可以使用排序模型。最后是生成模型，这是一个可选模块，用于在获得片段后生成更流畅的上下文，有时会调用 LLM 进行润色。

针对 RAG（Retrieve-And-Generate）模型的评估，我们可以将其评估指标划分为三类：

传统检索指标：诸如 MMR 和 NDCG 等，尽管广泛应用于衡量检索系统的输出质量和排序效果，但在评价 RAG 这类新型检索生成模型时，因其无法全面反映检索性能而存在局限性。
端到端测试：在早期阶段，当各组件性能尚待完善时，可将 RAG 与语言模型（LM）作为一个整体系统进行评估，通过用户查询和标准答案对比来衡量 LM 生成的答案质量。但此类测试方法的问题在于其难以精准定位改进点，即区分是 RAG 检索能力不足还是 LLM 回答问题的能力欠佳，且该评估方式较为粗略。
创新的 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），并且对内存的管理更为复杂。以下是几个代表性的闭环系统实例：

Self ask：基于 Chain of Thought（COT）理念，并加入了一系列后续问题，以此实现闭环。
ReAct：作为一个典型的闭环系统，其挑战在于在进行局部规划时，可能会逐渐偏离最初的目标，导致目标遗忘。
Plan & Solve：与 ReAct 有相似之处，但它从一开始就由 LLM 进行全局规划，减少了目标漂移的可能性。
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 测试挑战及应对策略的概述，欢迎大家提问交流。