微信扫码
添加专属顾问
我要投稿
深入解析RAG技术,让AI模型更好地理解和应用企业私有数据。 核心内容: 1. AI大模型在企业私有数据场景的限制和挑战 2. RAG技术的原理和流程详解 3. RAG如何平衡业务知识感知与数据隐私保护
在前面的文章《实战干货!如何使用Java构建企业级AI Agent服务框架?》里有讲过,AI大模型存在一些能力边界及限制:
1)LLM没有真逻辑
2)LLM数据滞后,没有私有数据
3)存在幻觉,欠缺精确性
数据滞后以及缺少私有数据限制了大模型在一些保密性有要求、企业内部私有数据场景的使用。之前有预测认为这会催生垂类专有模型的发展,但是从实际的发展趋势来看,专有小模型并没有发展起来。
大模型是个赢者通吃的业务,新模型间的能力竞赛此起彼伏,昨天还是小甜甜,转眼就成了牛夫人。
因此发展垂类专有小模型看起来既没必要也不实用(有垂类知识,但是能力残缺)。
那么如何解决这个问题呢?至少有两种方案:
1)模型微调
即将私有的业务数据按照微调的方式喂给已有大模型,从而达到更新模型知识背景的目的。
但是微调模型对数据集的准备以及数量级都有要求,使用起来门槛较高。同时微调需要将企业内部知识输入给模型,无法保证数据隐私性。
2)RAG-检索增强生成(大模型+外部挂载私有知识库)
RAG方案优先从私有知识库获取知识,AI在其中仅发挥语义聚合的作用。对数据量和数据格式都没有要求,在保证大模型可以感知业务知识的同时,又保证了数据隐私。
本篇文章就准备结合我在前司建设AI智能知识库的经验,介绍一下RAG的原理和解决方案。
之前介绍理论相关的文章都太长了,在这个注意力缺失的时代,难以让读者保持专注地阅读下去。为了避免文章过长,本篇着重在原理和方案解析上,下一篇再讲解实战。
放一下当初基于ChatGpt3.5模型做的AI智能知识库产品演示视频:
RAG的过程可以分为两个阶段:索引构建阶段以及索引召回和内容生成阶段。
在该阶段,系统会将相关的文档内容经过一系列文本处理手段,如清理、分片等,通过数据嵌入技术(embedding)转换成向量数据,存储在向量数据库中,供后续阶段查询使用。
文档加载后,根据需求和模型能力的不同,需要对文档先进行一些清理操作,如模型为文本模型,势必处理不了多媒体类型文档;同类内容的整理和过滤等;
同时大模型的上下文有限制,针对很大的文档也需要进行切片,转换成较小的内容片段,这在后续的召回阶段,对提升召回准确性也很有帮助。
这一阶段的核心是向量化模型和向量存储引擎。向量化是将低维数据映射到高维数据的过程,比如OpenAI的text-embedding-ada-002模型就采用了1536维,将输入数据映射为一个1536维向量。
这个阶段会先采用相同的方式,将用户的问题使用相同的向量化技术转为向量数据,再使用该向量去向量数据库检索与之相似的K条向量数据,然后再将返回的数据作为模型调用的上下文与用户问题一起提供给大模型,让大模型来进行内容的聚合和生成。
这里需要铺垫一下向量检索的基础标准:向量相似度。
在向量化的过程中,我们将文本内容向量化到了1536维的特征空间,衡量两个向量是否相似的一个方法是使用余弦相似度。它的思想即如果两个向量之间的夹角越小,表明两个向量的相似程度越高。
如果我们需要根据给定的向量,找到跟它最相似的K个向量,通常会使用KNN或者HNSW算法。它们底层会使用余弦相似度来作为向量相似度的判断标准。
如果向量丰度足够,这一步后用户问题的答案就已经定位到了,每一条向量数据在存储自身向量化的数据之外,同时也关联了切分后的内容块。
下一步就只需要将这些原始答案内容块,结合问题一起交给大模型来聚合生成最终的答案了。
这一步才是整个RAG环节真正跟大模型打交道的地方。大模型天然适合语义理解和内容生成,当你提供了特定知识的上下文和用户的原始问题,它便可以生成语句通顺的内容来。
从上述过程也可以看出来,大模型从始至终并没有获得企业内部的知识内容,在跟大模型交互的过程中,它只有一些片段的知识内容的上下文信息,因此数据合规安全方面也有所保证。当然对保密要求有进一步要求的场景,你甚至完全可以私有化部署一套Qwen或DeepSeek的大模型使用。
RAG的工作原理实际上并不复杂,但是要想真正让它能够发挥实用价值,在工程上还是需要克服不少的困难。
使用阶段你可能面对各式各样的知识形式,纯文本、WORD、PDF、网页、图片、PPT等,你需要正确地从不同形式的载体中抽取出知识内容来。
如去除内容噪音(去除HTML标签、特殊字符、无意义符号、空白等)、数据标准化(统一文本格式)、识别非结构化数据(PDF、OCR)、处理重复数据等。
我在实践过程中对知识领域重复但内容不一致的内容深恶痛绝,因为压根没有一个统一的正确性判断标准。正如一个人说“1+1=2”,另一个人说“1+1=3”,你无法确认哪个业务知识是正确的,最终得到的问题回答可能也是错误的。
在将大内容文档分块切分时也需要注意:盲目切分会将完整的句子切分成段。
我采用了句读来切分,保证了不会将完整的一句话切分。切分的粒度也很重要,过细会造成知识信息密度低,影响向量召回准确性;过大会造成无关信息干扰;还有可能造成同一个知识点内容被切断。
向量嵌入模型的选择也很关键,理论上模型量化的特征空间维度越高,知识向量化后的相关性就会越高,但同时计算成本、存储成本和耗时也会相应提升。
从上面的流程示意图上可以看出来,召回阶段,RAG会将用户的Query完整embedding后作为检索向量。因此如果用户的提问包含一些无关信息,或者提问内容过长,势必会在向量化后影响召回准确率。
可以借鉴搜索引擎的分词策略,分解为更简单的查询后进行多个子查询后合并。也可以在这个阶段即引入AI,让AI先对问题进行有效性总结后,重写查询。
向量相似度的判断有多种方法,使用不同的向量检索选型也会存在不同的检索算法。需要在不同的算法选型中调研,选择合适自己需求场景的技术选型。
在内容丰度不足的情况下,最近的K个向量可能依然和正确的答案内容相差甚远。因此在检索召回过程中可以考虑设置阈值过滤的方式,将相似度过低的内容排除。
需要设计清晰明确的指示,可以通过few shot、前述文章中提过的CoT等技术,引导模型生成准确性更高的答案。
在模型的选择和参数调优上,也需要根据使用场景进行合适的评估,如是否需要多模态模型、中英文支持度的考虑、是否需要控制模型的生成创意、是否需要模型在无相关知识上下文场景下进行兜底等。
将知识生产和消费环节打通形成闭环,通常是一个更优的解决方案。如此,你可以通过控制知识内容的来源,避免多源头的知识载体不一致。
我在实践过程中即采用了这种方式,自研了类似语雀、飞书文档的现代知识生产管理平台,将第一步的内容向量化步骤自动化,用户在保存文档过程中自动完成内容的切块、预处理、向量化和存储,用户无需感知。
已有的知识文档也通过API对接的方式,迁移到统一的平台,自动触发内容的向量化。
混合使用搜索引擎技术,将问题分词处理后检索知识文档标题、标签等结构化数据,辅助向量召回,某些场景下甚至无需继续向量检索即可完成问题内容的检索。
在AI聚合生成问题内容后,将原始知识内容的来源附带出来,一方面可以供用户进一步了解详细内容,另一方面也可以让用户通过知识来源检查问答正确性,解决上面提到的可能源头知识内容冲突的问题。
RAG方案是一个很有用的将大模型结合垂类业务数据的解决方案,本文从原理和落地解决方案方面分析了RAG技术。但是RAG的使用也存在一些局限性:
1. 依赖embedding的准确性
它的核心即文档内容的向量化过程,向量化的准确性决定了问答召回的准确性
2. 依赖文档质量
如果知识库存在错误、不完整或过时的信息,会导致产生错误的或者误导的信息。
3. 处理长文档的挑战
长文档的处理会带来工程上的复杂度,处理不当会影响系统的准确性。
4. 文档召回和大模型幻觉
文档召回依赖向量检索技术,即使在召回准确的情况下,大模型幻觉依然可能存在。
所以RAG解决方案通常需要结合企业内部的知识生产工具一起使用,它是一个系统性的方案,需要企业拥有完整的内部知识数据的生产、维护、消亡全生命周期。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-04-02
回答我!会不会搭建 DeepSeek 版个人知识库?
2025-04-02
你的RAG检索太“笨”?用K-Means聚类来“调教”
2025-04-02
强大的AI研究助手Local Deep Research
2025-04-02
探索智能代理增强检索生成(Agentic RAG):从基础到实践
2025-04-01
ragflow想说爱你不容易,win10环境搭建、常用修改
2025-04-01
跟着高手学提问,复现deepsearch
2025-04-01
Ubuntu服务器RAGFlow的部署教程
2025-04-01
连续尝试了18种RAG技术之后,我找到了最优的那个
2024-10-27
2024-09-04
2024-07-18
2024-05-05
2024-06-20
2024-06-13
2024-07-09
2024-07-09
2024-05-19
2024-07-07
2025-04-02
2025-04-01
2025-04-01
2025-03-30
2025-03-28
2025-03-27
2025-03-27
2025-03-25