微信扫码
添加专属顾问
我要投稿
考量一
选择合适的知识块大小
一个批量评估的过程输出
考量二
分离用于检索的块与用于生成的块
如果原始知识是大量结构化的问答对,那么非常适合只对问题作向量嵌入。在精确检索到问题以后,再将关联的答案内容加入后一起输入LLM用作生成。此外,这里还会有一些常见的检索前(Pre-Retriever)处理:
利用LLM生成更多相似问法做嵌入,以提高召回能力
利用LLM生成假设性问题做嵌入,来模拟问答对
考量三
对大文档集知识库做分层检索
如果你只是用笔记本电脑上的一个简单pdf文档来构建经典RAG应用,你可能永远不会有这个问题的困惑。但在企业复杂的知识密集型应用中,你可能会面临几百个不同知识来源与类型的知识文档。虽然在管理与维护上,可以通过多级管理进行简化;但是在向量存储与检索的方法上,如果只是简单依赖于传统的文本分割+top-k检索,那么就会遇到精度不足、知识相互干扰等问题导致效果不佳,而这里最主要的问题仍然是检索阶段。一个重要的方法是实现大文档集下的“分层”过滤与检索。考虑以下三种不同的分层检索策略:
【元数据过滤 + 向量检索】
这种方案在向量知识库构建时根据文档信息对拆分的每个知识块做元数据标识(比如这里的地区、类型),然后生成向量并存储。那么在检索时的流程变为:
利用LLM推理输入问题的元数据信息
借助向量数据库的元数据过滤定位到部分文档
结合向量语义检索进一步定位到top-k的知识块
这种方案的好处是简单的借助了向量库的能力,可以快速自动过滤并检索;但缺点是:
需要设计元数据标签
借助LLM推理问题元数据存在一定的不确定性
元数据只能精确匹配,不能语义搜索
可能需要借助向量数据库
【摘要检索 + 内容检索】
这种方案就是利用了上文提到的“小块”到“大块”的多层向量方案。对每个文档做摘要信息提取,并在摘要与原始文档两个级别上分别做嵌入与向量存储,并做好两者的关联。检索时的流程为:
在摘要级别做检索,获得相关的摘要知识块
根据摘要块的关联信息,可以关联到原始文档
递归查找原始文档的知识块,找到top-k的上下文
这种方案的好处是在两个层次上都可以做语义检索。缺点是:
需要借助LLM生成摘要知识块,较为麻烦且成本增加
摘要查找时如果语义匹配错误,则后续无法得到有效上下文
【多文档AI Agent】
与上面两种不同的是,这是一种基于AI Agent思想的方案。虽然也是一个“两级”的方案,但是并不是通过简单的两级向量来实现分层递归检索,而是一个两级的AI Agent,并利用Agent的思维链模式进行推理。其核心思想是:
为每一个文档或知识库实现一个知识Agent。这个Agent的能力是可以使用一个或者多个RAG工具来回答问题
在多个知识库Agent之上实现一个语义路由的Agent,这个Agent会借助推理来使用后端的知识Agent完成任务
所以这不是一个简单的知识检索优化方案,而是一个基于RAG之上的多级Agent方案(Agentic RAG)。其最大的好处是具备了极大的灵活性与扩展性,几乎可以完成任意基于知识的复杂任务。知识既可以是这里向量化的知识,也可以是外部系统的结构化/非结构化知识。其主要优势来自于两点:
通过对二级Agent的扩展,可赋予其更多的工具能力,而不再局限于简单的回答事实性的问题,可以完成更多的知识型任务。比如:整理、摘要生成、数据分析、甚至借助API访问外部系统的实时知识等
多个Tool Agent可以通过协作完成联合型的任务。比如:对两个不同文档中的知识做对比与汇总。这也是经典的问答型RAG无法完成的任务
当然这种方案的缺点是具有一定的实现复杂性,后面我们也会用专门的文章与实例单独探讨Agentic RAG的应用。
我们将在【下】篇中继续探讨RAG应用的另外三个常见优化考量。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-02-01
2025-01-01
2024-08-13
2025-02-04
2024-07-25
2024-04-25
2024-06-13
2024-09-23
2024-04-26
2024-08-21
2025-03-13
2025-03-13
2025-03-13
2025-03-13
2025-03-13
2025-03-13
2025-03-13
2025-03-12