惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

aimingoo的专栏
aimingoo的专栏
宝玉的分享
宝玉的分享
博客园 - 【当耐特】
博客园 - 司徒正美
L
LangChain Blog
有赞技术团队
有赞技术团队
大猫的无限游戏
大猫的无限游戏
Stack Overflow Blog
Stack Overflow Blog
Engineering at Meta
Engineering at Meta
U
Unit 42
Microsoft Azure Blog
Microsoft Azure Blog
I
InfoQ
博客园 - 叶小钗
H
Hackread – Cybersecurity News, Data Breaches, AI and More
J
Java Code Geeks
月光博客
月光博客
量子位
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园_首页
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
Google DeepMind News
Google DeepMind News
云风的 BLOG
云风的 BLOG
D
DataBreaches.Net

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
检索增强生成(RAG):如何让AI大模型更懂我?
AI小当家 · 2024-02-21 · via 人人都是产品经理

大模型的局限性体现在缺少实时性、无法获取私有知识等方面,而RAG可以帮助解决私有知识问题,让私有知识库和AI大模型更好地融合。怎么理解RAG的原理、应用场景和优缺点?一起来看看本文的分享。

上文简单介绍了AI大模型非常重要的提示工程,今天我们继续学习检索增强生成(Retrieval-Augmented Generation,RAG)。

RAG可以将私有知识库和AI大模型融合,让大模型“知道”我们的私有知识,变得越来越“懂”我们。

一、AI大模型的局限性

使用过大模型的小伙伴应该知道,虽然大模型看起来无所不能,但是它也经常胡编乱造,没有足够的确定性,这也限制了大模型在各种场景的落地。

大模型的局限性,可以简单归纳为以下两点:

  • 没有实时性:AI大模型的知识不是实时的,最新的GPT-4 Turbo也只是把知识库更新到2023年4月,所以无从得知该时间之后发生的事情。
  • 无法获取私有知识:大模型的训练数据主要来源于互联网,不可能拿到个人或企业的私有数据,所以无法回答私有问题。

针对实时性问题,一般通过Actions或Function Calling(函数调用,可以理解为接口回调)等方式,让大模型实时调用搜索、地图、甚至企业自己实现的api,获取各种需要的实时信息,减少幻觉,提升确定性。

而RAG可以解决私有知识问题,它通过外挂知识库的方式,让大模型可以根据检索到的内容,回答私有库的相关问题,也就是所谓的检索增强,目的同样是提升确定性。

二、基本概念

RAG的核心目的是通过某种途径把我们的知识告诉给AI大模型,其核心流程就是根据用户提问,从私有知识中检索到“包含答案的内容”,然后把“包含答案的内容”和用户提问一起放到prompt(提示词)中,提交给大模型,此时大模型的回答就会充分考虑到“包含答案的内容”,看起来也就更“懂”我们。

那么具体要如何实现呢?再看一下核心流程,会发现有一个必须解决的问题,就是如何“根据用户提问,从私有知识中检索到包含答案的内容”,用户的提问是自然语言(包含复杂的语义理解),传统的关键字检索(Elastic Search)是无法理解语义的,这时候就需要引入向量检索的概念了。

  • 向量:文本的语义关系在底层被处理为向量,向量就是一组浮点数,例如[0.72, 0.42, …],代表该文本在N维空间里的坐标。在空间中距离越近的向量,语义也就越接近。一般使用欧式距离或余弦距离来衡量向量的相似度。
  • 向量检索:向量检索实际上是将文本分段转换成了一个个向量,通过余弦距离或欧式距离来计算两个向量之间的相似度,向量相似度越高,表示对应的文本语义相似度越高。
  • 向量数据库:专门为向量检索设计的中间件。

我们可以通过向量检索来获得与用户问题语义最相近的私有知识库的内容,即便用户问题中没有包含关键字,也可以通过语义的相关性搜索到“包含答案的内容”。

实现RAG的具体步骤如下:

  1. 加载私有知识库文档,并将文本切分为一个个小片段,需要注意切分的粒度,然后将切分后的文本转换成向量,存入向量数据库。
  2. 将用户的提问内容也转换成向量,在向量数据库中检索相似的文本内容,检索结果就是“包含答案的内容”。
  3. 将用户的提问内容和检索到的“包含答案的内容”组装成新的提示词,发给AI大模型。
  4. AI大模型参考“包含答案的内容”(私有化的知识资料),回答用户的问题。

这样我们就可以收获一位更“懂我”的大模型了。

三、应用场景

RAG可以有效扩展大模型的知识库,以下是一些具体的例子:

  • 问答系统:RAG可以用于构建问答系统,用户提出问题,RAG模型从大规模的文档集合中检索相关的文档,然后生成回答。
  • 对话系统:在对话系统中,RAG可以用于生成更丰富、更具信息量的回答。
  • 文档生成:RAG可以用于生成包含特定信息的文档,例如新闻报道、研究报告等。

四、优缺点

RAG的优点:

  • 生成的回答更丰富:由于在生成回答时会考虑检索到的文档,因此生成的回答通常更丰富、更具信息量。
  • 能处理开放领域的问题:传统的生成模型通常只能处理特定领域的问题,而RAG模型可以处理开放领域的问题,因为它可以从大规模的文档集合中检索信息。

RAG的缺点:

  • 计算成本高:RAG模型需要在大规模的文档集合中进行检索,这会增加计算成本。
  • 依赖文档质量:RAG模型的性能在很大程度上依赖于文档的质量,如果文档质量差或切分粒度不合适,可能会影响模型的性能。
  • 可能产生不准确的回答:虽然RAG模型可以生成丰富的回答,但是如果检索到的文档包含错误的信息,可能会导致生成的回答不准确。

五、总结

本文我们主要介绍了RAG的基本原理,RAG可以有效扩展大模型的知识库,有效提升回答的确定性,让AI大模型变得更加“懂”我们。

下篇文章,我会介绍如何让AI大模型连接外部世界,让大模型和我们的业务连接的更加紧密,甚至看起来“无所不能”,敬请期待。

本文由 @AI小当家 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。