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

推荐订阅源

T
Tor Project blog
博客园 - 聂微东
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - 【当耐特】
G
Google Developers Blog
J
Java Code Geeks
The Cloudflare Blog
Attack and Defense Labs
Attack and Defense Labs
宝玉的分享
宝玉的分享
Last Week in AI
Last Week in AI
Cisco Talos Blog
Cisco Talos Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
I
Intezer
Jina AI
Jina AI
T
Tenable Blog
P
Palo Alto Networks Blog
Project Zero
Project Zero
D
DataBreaches.Net
Hugging Face - Blog
Hugging Face - Blog
The Hacker News
The Hacker News
F
Full Disclosure
Cloudbric
Cloudbric
量子位
H
Heimdal Security Blog
K
Kaspersky official blog
有赞技术团队
有赞技术团队
罗磊的独立博客
V
Vulnerabilities – Threatpost
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
阮一峰的网络日志
阮一峰的网络日志
Vercel News
Vercel News
Recent Announcements
Recent Announcements
WordPress大学
WordPress大学
GbyAI
GbyAI
S
SegmentFault 最新的问题
M
MIT News - Artificial intelligence
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
I
InfoQ
Recorded Future
Recorded Future
Security Archives - TechRepublic
Security Archives - TechRepublic
AI
AI
Webroot Blog
Webroot Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
爱范儿
爱范儿
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
T
The Exploit Database - CXSecurity.com
Apple Machine Learning Research
Apple Machine Learning Research
C
Cybersecurity and Infrastructure Security Agency CISA
H
Hacker News: Front Page
Latest news
Latest news

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
AI产品经理必修课:RAG(终)
我是黄晓泽 · 2025-08-26 · via 人人都是产品经理

RAG,不只是技术架构,更是一种产品思维。从“检索增强”到“生成协同”,它连接的是知识系统与用户体验的双重跃迁。但很多产品经理只看到了“能搜能答”,却忽略了背后的数据治理、提示词策略与系统设计。

作为系列终篇,本文将从产品视角拆解 RAG 的底层逻辑与落地路径,帮助你真正把它用成“认知引擎”,而不是“搜索外挂”。

1. 引言

从RAG的本质和RAG Pipeline的编排展开,把不使用RAG的坏处、使用RAG的好处、RAG系统里各个环节的思考。

  • RAG的本质:知识检索与语言生成,二者的解耦再重新编排。
  • RAGpipeline的编排:从离线知识库的构建,到在线检索增强生成的每一步。

2. 检索与生成的解耦

从一个不可分的、隐含在同一大模型的内部过程,拆分为两个各自可独立优化的模块。被解开的耦合不仅是检索功能和生成功能,更在于它带来的知识更新与模型训练的分离。

2.1 不使用RAG的坏处

在不使用 RAG 的情况下,大模型需要将所有知识都存储在模型参数中。而知识更新的速度远高于模型训练,可能以小时甚至分钟级变化。如果每次知识更新都要重新训练模型,那成本就太高了,而且还可能引入新的问题。

a)训练周期长和训练成本高:每次知识更新都可能需要对整个大模型进行重新训练或微调,这是一个耗时且昂贵的过程。RAG 通过将知识存储在外部知识库中,避免了频繁的重新训练,只需要大语言模型通过特定的检索机制 (例如,基于语义相似度的向量检索) 从知识库中按需获取相关信息,从而降低了成本。

b)数据合规性和引入新噪声: 新数据可能包含不合规内容或噪声,直接用于训练会将这些问题固化在模型参数中。RAG 允许对外部知识库进行更严格的质量控制和合规性审查,从而降低了风险。

2.2 使用 RAG 的好处

在使用 RAG 的情况下,知识更新无需频繁改变模型参数,知识直接存储在外部知识库,会带来这些好处:

a)减少资源的消耗:模型通常会将知识直接编码到模型的参数中,知识越多,参数越多,计算量越大,就需要更多计算资源来进行部署和推理 (在部署时,需要大量的内存来加载模型参数,就需要高性能服务器和 GPU;在推理时,模型需要对每个参数进行计算,相应基础设施的调度会消耗大量电力)。

b)知识管理更灵活:轻松地添加、删除或修改知识库中的信息,而无需更改或重新训练大语言模型。这使得系统更容易适应不断变化的知识需求,例如,可以快速地添加最新的行业报告、法规更新或产品信息,确保模型始终提供最准确和最新的答案。

c)信息的可追溯性:大语言模型被认为是黑盒,因为很难理解它为什么会做出这样的回答,这使得它在医疗、金融、法律的关键应用中的应用受到限制。通过 RAG 可以追踪模型在生成答案的知识来源,验证模型是否使用了可靠的信息,为人类的决策提供具体依据。

★ 3. Rag pipeline的编排

(总的来说分为:离线知识库的构建+在线检索增强生成)

a)数据收集:从各种数据源获取原始数据,并对数据进行预处理,涉及不同类型数据的解析策略 (word、pdf、ppt、跨页表格)。

b)数据分块:将长文档切割成语义相对完整的文本块 (Chunk),涉及不同类型数据的分块策略 (比如结构化数据与非结构化数据、长文段与短文段)。

c)向量嵌入:将上一步的文本块转换为向量。需要用向量嵌入模型 (Embedding Model) 将文本信息嵌入到向量空间中,涉及模型的选型。

d)存储与索引:将上一步的向量化的文本块存储进向量数据库中 (存储),并将文本块按照一定规则排列好 (创建索引),便于查询时快速检索,涉及索引结构的选择 (摘要索引、树状索引、知识图谱、向量索引)。

注意:使用向量索引时,无论是离线文本的向量化,还是在线的用户查询的编码,都必须使用同一个向量模型,保证它们编码在同一个向量空间。

e)检索与重排:系统收到用户查询 (query) 后将其向量化,并在数据空中进行相似度检索,得到大量相关的文本块并进行排序,找出与查询语义最相关的 Top-K 的文本块 (比如 Top-3 就相关性前三的资料) 作为参考。

f)答案生成:模型仔细阅读用户查询和参考资料,依据提示词生成一个有依据的回答,涉及增强提示词的设计。

注意:返回给用户之前需要进行后处理,保证生成答案的美观度和可信度,同时过滤掉不必要的信息。

虽然向量嵌入主要在数据存储时使用,但在检索重排时也会涉及。只是为了方便读者理解,在前文将向量嵌入单独作为一步进行说明,接下来将其合并为:数据收集→数据分块→创建索引→检索重排→答案生成。

3.1 数据收集

对文档进行搬运(不同类型的文档解析方式不同),并用模型进行预处理 (打标签、生成摘要),优质的数据收集需要满足以下特点:

a)内容完整:不能漏掉任何有价值的信息,包括文字、图片、表格等。

b)内容准确:提取内容不能有错误,比如 OCR 识别出来的文本,就要尽可能地避免识别错误。

c)关系完整:数据内部存在关联性,比如主干段落与分支段落的层级关系、图片与图片说明的对应关系,能够帮助 RAG 系统更好地理解数据。

d)元数据完整:元数据就是数据的数据,数据本身具有标题、标签、大小、生成时间等信息,能够帮助 RAG 系统更好地管理和利用数据。

Word 解析方案

a)文本信息解析:使用”python-docx”库对”.doc”文档进行解析,提取出保留结构层级的信息(标题、正文、编号、列表等)

# ChatGPT 使用说明

## 简介

ChatGPT 是一个大型语言模型,由 OpenAI 训练,它可以用于各种自然语言处理任务。

(解析前)

<h1>ChatGPT 使用说明</h1>

<h2>简介</h2>

<p>ChatGPT 是一个大型语言模型,由 OpenAI 训练,它可以用于各种自然语言处理任务。</p>

(解析后)

b)图片标签生成:将 word 里的图片导出到指定文件夹 (image_folder),建立映射字典 (image_map) 表示 key 和 value 的关系(key 就是图片的身份证号,value 就是图片的身份证信息,包含图片路径 scr 和文字说明 alt)

比如:<img src=”image_folder/image1.png” alt=”Image 1 Description”>

  • img=嘿,这里有一张图片
  • scr=它的位置在image_folder/image1.png
  • alt=如果图片加载不出来,就显示Image1Description这段文字

c)图文内容整合:将文本内容和图片标签按照原文档的顺序组合成一个完整的 HTML 字符串。

若检测到图片引用 ID (例如 “image123″)。

在 image_map 中查找这个 ID 作为 Key。

image_map 返回对应的 Value。

将这个 HTML 标签插入到最终生成的 HTML 文档中。

d)HTML文档导出:输出包含富文本结构的 HMTL 内容块,它的标准化结构和易于渲染的特性,方便了后续的分块、向量化、检索。

  • 文档分块:在RAG文档预处理时,HTML格式便于将文档内容结构化地分割成更小的块。
  • 检索展示:在展示检索内容时,将检索结果高亮显示,将插图还原,会更加的简单和可靠。

# ChatGPT 使用说明

## 简介

ChatGPT 是一个大型语言模型,由 OpenAI 训练。 它可以用于各种自然语言处理任务,例如:

– 文本生成

– 机器翻译

– 问答

[图片ID: chatgpt_architecture]

(解析前)

<h1>ChatGPT 使用说明</h1>

<h2>简介</h2>

<p>ChatGPT 是一个大型语言模型,由 OpenAI 训练。 它可以用于各种自然语言处理任务,例如:</p>

<ul>

<li>文本生成</li>

<li>机器翻译</li>

<li>问答</li

</ul>

<img src=’images/chatgpt_architecture.png’ alt=’ChatGPT 架构图’ title=’ChatGPT 内部结构’>

(解析后)

PDF 解析方案:

Word、HTML、Markdown 是结构化文档,内部带有结构化标签,例如段落、列表、表格等,这些标签如同文档的”骨架”,方便计算机直接解析和理解。而 PDF 的设计初衷是为了在不同设备上完美展示文档,内容以页面流的形式呈现,缺乏内在的语义结构信息,是按照坐标进行绘制的,大大增加了提取难度。

PDF文档中的文本在提取出来时,排版是混乱的,不具有可读性。需要根据字符坐标 (x 和 y)、排版特征 (页码、字体、粗细、行间距)、结构信息 (标题、正文、编号、列表),像拼图一样,把这些碎片重新组合成完整的富文本结构的段落。

a)文本提取:使用工具 pdfplumber 和 PyMuPDF,或 OCR 解析PDF文件,为后续文本重组做铺垫。

文本内容:”

1. Introduction”

位置坐标:(100, 50)

字体大小:14pt

字体:Arial

加粗:True

结构:一级标题

b)文本重组:基于字符坐标、排版特征、结构信息,重建包含标题、正文、序号等结构的页面。

c)修复错误:在重新组织文本时,容易出现换行错误(一段话被错误地分成两行),这是由于坐标精度不足导致的字符位置关系不确定(公式、表格、特殊符号、字体的变化等,会导致字符间距变小,程序识别精度不够,可能会认为是字符重叠的),进而采取”强制换行“和”插入空格“这样最常见、也最保守的策略。

d)图片标签生成

e)图文内容整合

f)HTML文档导出

3.2 数据分块 (chunk)

文本分块是自然语言处理 (NLP) 中的一项关键技术,其作用是将较长的文本切割成更小、更易于处理的片段。

为什么需要对文档进行分块?而不是直接进入下一步,提取文档的嵌入向量。

分块过大: 降低检索精度,增加计算成本,易超出模型上下文窗口导致信息截断。分块过小: 造成上下文缺失(如论点论据分离、数据分析脱节),影响模型对信息的完整理解。

分块大小需要考虑几个维度:

a) 数据本身的结构特点:学术论文需要长段的完整的分块,视频文案天然适合较短的分块。

b)用户提问的长度和复杂性:用户输入的文段长度和问题的复杂程度,影响结果需要参考的上下文长度。

c)Embedding 模型的适配:不同的嵌入模型,对文本块颗粒度的适应性不同,影响检索的效果。

d)计算成本和响应时间:分块越大,意味着生成内容时发给 LLM 的内容越多,成本和延迟都会增加。

Token 切片 (滑动窗口)

滑动窗口是实现 Token 切片的一种常见方式,你可以把它想象成一个在文本序列上滑动的尺子,它有固定的长度 (chunk_size),每次滑动一定的距离,就从尺子框住的头和尾切下一块。

  • chunk_size:每个文本块块包含多少Token(尺子的长度)。
  • chunk_overlap:相邻小块之间重叠多少个Token(尺子滑动前后的重叠部分)。

举个例子,假设我们有一段文本:

[A、B、C、D、E、F、G、H、I、J、K、L、M、N、O、P、Q、R、S、T、U、V、W、X、Y、Z]

如果我们设置 chunk_size = 5,chunk_overlap= 2,那么切出来的效果就是:

切片 1: [A, B, C, D, E]

切片 2: [D, E, F, G, H]

切片 3: [G, H, I, J, K]

分块时使用配套的分词器 (Tokenizer) 可以确保分词方式与模型训练时使用的方式一致,从而获得最佳性能。LLM 模型的官方文档会明确指出推荐使用的 Tokenizer,或者有自己的 Tokenizer (例如 BERT、GPT 有自己专门的 Tokenizer,与模型一起发布)。同时,也需要考虑语言和任务,在 Hugging Face Transformers 库中寻找合适的分词器,并进行效果评估。

一句话总结:Token 切片是目标,就像我们要把蛋糕切成小块;滑动窗口是手段,就像切蛋糕的刀,决定了怎么切、切多大。它的特点是简单粗暴,但是也容易破坏语义完整性。

句子切片

使用正则表达式识别中文标点符号(句号、问号、感叹号等)是一种简单直接的中文文本分句方法,虽然不如语义切片精确,但足以满足基本需求。

递归分割

递归分割按照预设的优先级顺序 (段落分隔符/两个换行符 → 换行符 → 句子分隔符 → 空格),依次尝试使用这些分隔符将文本分割成更小的块,直到文本块的大小都满足预设的限制。就像一个要减肥的人吃蛋糕,一次不能吃太多,不然卡路里超标。先切一大块,发现切多了,热量高了,就再补一刀,直到大小合适,热量正常为止。

-最高优先级:按照段落 (两个换行符/单个换行符) 切割。

-再次:按照句子分隔符 (句号、问号、感叹号) 切割。

-接着:按照空格切割 (尽量保证单词完整)。

-最低优先级:如果以上方法都不行,就强制按照字符切割 (最坏的情况)。

专门分块(数据本身有特定规则)

根据 Markdown 语法规则(标题、加粗、代码块等)进行分块。

根据 LaTeX 命令(如 \section, \subsection)来创建逻辑块,如章节和小节。

语义切片

通过 LLM 理解语义后,依据上下文精准灵活地进行分割。切片的精度高,但计算成本也高。

滑动窗口+语义切片

语义切分优先 (首先将文本分割成具有完整语义的块),超过限制的块用滑动窗口 (如果语义块仍然过大超出 token 限制,则对该块使用滑动窗口切分)。

a)大模型理解语义:将原始文本切分成语义段落 (例如,有”原始语义段落 1″和”原始语义段落 2″)。

b)判断每个段落的大小:如果段落大小合适 (比如 ≤50 tokens),则直接采纳。

c)滑动窗口并进行切片:针对过长段落进行 token 切片,生成含重叠的子切块。

举个例子,原始段落如下:

“RAG 框架是一种将检索和生成相结合的技术。它首先从大规模知识库中检索相关信息,然后利用这些信息来生成更准确、更有针对性的回复。与传统的生成式模型相比,RAG 框架能够显著提升生成内容的质量和可信度。本段主要介绍 RAG 的基本概念和优势。要搭建一个基于 RAG 框架的智能客服,你需要准备以下几个关键组件。”

a)大模型语义理解

原始语义段落1:”RAG 框架是一种将检索和生成相结合的技术。它首先从大规模知识库中检索相关信息,然后利用这些信息来生成更准确、更有针对性的回复。”

原始语义段落2:”与传统的生成式模型相比,RAG 框架能够显著提升生成内容的质量和可信度。本段主要介绍 RAG 的基本概念和优势。要搭建一个基于 RAG 框架的智能客服,你需要准备以下几个关键组件。”

b)判断每个段落的大小

原始语义段落1: 45 个 token,小于 50 token 的阈值,因此直接采纳。

原始语义段落2: 70 个 token,大于 50 token 的阈值,需要进一步切分。

c)滑动窗口并进行切片(含重叠部分)

子切块2.1:”与传统的生成式模型相比,RAG 框架能够显著提升生成内容的质量和可信度。本段主要介绍 RAG 的基本概念和优势。”

子切块2.2:”本段主要介绍 RAG 的基本概念和优势。要搭建一个基于 RAG 框架的智能客服。你需要准备以下几个关键组件。”

普通分块的问题在于,直接切分可能会破坏语义的完整性,但如果整个文档太大,又会超出 token 数量的限制。而滑动窗口+语义切片的优势就在于,既能保证语义完整性,又不会让单个文本块过大:先做语义切分 (保证语义完整性),若语义切分后的块还是很大,超出token限制,再对这个块做滑动窗口切分 (解决chunk大小问题)。

分块策略的选择a)先结构化后语义

面对 word、ppt、markdown 这种结构化的文档,优先采用专门切块,按照目录/章节/列表的格式进行切片,再视情况而定是否要追加语义切片。可以最大化的保留文档的语义,结构化部分也可作为检索特征。

b)非结构化就语义

面对小说、散文、哲学这种典型的结构化文档,就需要采用语义切块。可以避免整段语义的分割,便于模型理解抽象概念。

工作流:

– 句子级拆分:将文档按句子进行划分。

– 组块构建:连续多个句子组合成一个“句子组”。

– 语义嵌入生成:使用指定嵌入模型为每个句子组,生成向量表示。

– 语义相似度计算:通过余弦距离衡量相邻句子组之间的语义差异。

– 动态切分决策:当语义差异超过设定的阈值,则在此处进行切分。

c)窗口重叠来补救

token 切片和递归切片,这种固定规则的切片方式,容易破坏语义结构,有时需要采用窗口重叠来补充上下文。重叠比例一般在 10%-20%之间,宁愿多消耗算力,也要保证语义信息的完整。

3.3 创建索引

索引是检索增强 LLM 中的一个核心组件,用于组织和存储向量化后的文本内容 (chunk),以便用户能够快速找到所需的信息。简单来说,它就像书的目录一样,可以帮助你快速定位到书中的相关章节。

以下是几种常见的索引结构:

a)摘要索引:将节点按照顺序链接起来。检索时,可以顺序遍历所有节点或根据关键词进行过滤。

b)树索引:将节点组织成树状结构,检索时可以从根节点向下遍历,也可以直接利用根节点的信息。

c)关键词表索引:从每个节点中提取关键词,并建立关键词与节点的多对多映射关系。适用于查找包含特定关键词的文档,但在处理多关键字查询时效率较低 (过于复杂)。

d)向量索引:使用文本嵌入模型将文本块转换为固定长度的向量,并存储在向量数据库中。检索时,将用户查询文本也转换为向量,并通过向量相似度计算来查找最相似的节点 (这是目前最流行的方法)。

e)知识图谱索引:知识图谱是不同知识之间的关系图。

f)多层表示索引:通过创建多个向量来表示每个文档,例如:

  • 多向量检索器(multi-vectorretriever):把每个文档先提炼成简短的摘要,并将摘要转成向量用于语义检索;检索命中后,不返回摘要本身,而是将对应的完整原文档交给LLM生成答案。
  • 父文档检索器(parent-docretriever):先把文档切成较小的块,并对这些块进行向量化检索;检索命中后,返回这一小块和它的父块(这样上下文更丰富)给LLM生成答案。

通过较小的表示(摘要或块)进行检索,但将它们链接到完整的文档/上下文中进行生成,核心思想是在保证检索效率的同时,尽可能提供完整的上下文信息。

3.4 检索重排

传统的搜索技术,要么因为过于依赖关键词而忽略了用户的真实意图,要么就是因为信息处理能力有限而遗漏了关键信息。而在RAG中需要检索相关资料作为上下文,发给大模型。但是,如果一股脑地把Top50 的资料都塞给大模型,显然会带来一些问题 (token 消耗过大、模型受窗口限制无法读取全文)。

所以,在向量查询 (ANN) 后,通常使用 Rerank模型 进行重排序,精选 TOP5 甚至 TOP3 的相关资料。

Reranker 是一种后处理技术,常用于向量近似最近邻(ANN)搜索之后。它通过更精确的语义相关性分析,对初始检索结果进行语义级精细打分并排序,进一步提高检索的准确性。

注意:既然通过 embedding 可以理解语义,为什么还要使用 rerank?前者可以检索到相似语义的结果,但后者可以通过打分区找到最相关的结果,减少提示词上下文窗口的占用。

3.5 答案生成

检索到参考资料,接下来由模型组装答案,需要使用提示词进行引导,最基础的 rag 提示词模板:

参考资料(检索到的文本快):xxx

用户查询(用户输入的指令):xxx

请你根据参考资料回答用户查询。

备注:更详细的提示词的模板可以查看《AI产品经理必修课:RAG(2)》的”三个 RAG 提示词模板——精准地引导 RAG 进行信息检索与生成”。

4. 结语

RAG(检索增强生成)技术在不断发展,为各种应用场景带来了新的可能性。在实际的RAG编排中,难免会遇到各种问题,如何用逆向排查的方式定位问题,可以从哪几个角思考解决方案。可以参考:RAG 系统的问题排查可以查看《AI产品经理必修课:RAG(1)》的”RAG的数据源从哪里来,出现错误信息,结果不合预期怎么办?”。

本文由 @黄晓泽 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议