为什么不能把资料整个塞给 AI — 两条流水线是怎么被逼出来的
这一章讲三件事: 你的 AI 助手为什么答不出你公司的事; 为什么「把资料全给它」这条最直白的路走不通; 以及走不通之后剩下的那条路长什么样。 读完你会拿到全书的骨架——后面六章都是在这个骨架的某一段上打磨。 不需要任何基础,遇到的生词都在当场解释。
1. 先看现象:它什么都懂,就是不懂你的事
你大概试过这样一件事:
- 问它「Python 怎么读 Excel」—— 答得又快又对;
- 问它「我们公司去年跟这家供应商签的合同里,违约金条款是怎么写的」—— 它要么说不知道,要么编一个看起来很像的答案给你。
这不是它笨,是它没见过。
这类会写字的 AI,行话叫大语言模型,英文缩写 LLM—— 指的就是 ChatGPT、Claude 这类读了海量文字之后学会接着往下写的程序。 它写出来的每一个字,都是照着它读过的那批文字接下去写的; 它没读过的东西,它写不出来,只能编。
它读那批文字的过程,行话叫训练。训练一停,它知道的东西就定死在那一刻了—— 之后你公司签的每一份合同,它一个字都没见过。
那你的合同在哪儿?按这本书开篇给的说法:传统公司里大约八成的信息不在任何数据库里, 而是埋在幻灯片、Word 文档、Excel 表、邮件和会议记录里1。
这一章要回答的就是:怎么把这八成弄到 AI 眼前。
2. 顶层全景:一句话链条
它没见过你的资料
└─ 那就把资料给它 ── 一次能给的量有上限,而且给得越多越慢越贵 ── 此路不通
└─ 那就只给相关的那几段 ── 可「相关」怎么找?关键词对不上
└─ 把文字变成一串数字,让意思近的数字也近 ── 于是「找」变成了「比远近」
└─ 数字要提前算好存起来 ── 整件事裂成两条流水线:入库(慢)+ 问答(快)
图说:每一层都是被上一层逼出来的,不是谁设计得巧。这一章从上到下走完这五层。
3. 第一条路为什么走不通:两堵墙
这一节回答:为什么不能干脆把整份资料贴进对话框。
第一堵墙:一次能读多少是有硬上限的
「上下文」就是这一次对话里,模型眼前能同时看到的全部文字—— 包括你的问题、你贴进去的资料、以及它自己已经写出来的部分。超出这个量的部分,它看不见。
书里的说法很干脆:每个模型都有一个最大的上下文尺寸, 它规定了这个模型在一次交互里能处理多少内容2。
顺便说一个后面会反复出现的计量单位:这个上限不是按「字数」算的, 是按标记(英文 token:模型把一段文字切开之后的一小片)算的。 标记就是模型能处理的最小单位,它可能是一个完整的词,也可能只是词的一小截。 英文里大致 1 个标记 ≈ 4 个字符,这个换算书里第 2 章用到过,后面第 05 章讲切分大小时还会用3。
这堵墙其实在慢慢后退——书里也承认上 限「越来越大」。所以它不是决定性的那一堵。
第二堵墙才是真正致命的:慢,和贵
先说清一个词:「提示」就是你最终发给模型的那一整段话——问题,加上你附带的所有资料。 它是模型唯一的输入。
同一句话里,作者紧接着说了真正的原因: 堆出巨大的提示会让模型响应时间变长,让应用又慢又贵2。
提示越长,模型要读的东西越多,吐第一个字之前你等得越久。
而钱是按量算的:这类模型的服务几乎都按「读进去多少 + 写出来多少」收费。 你每问一次就把整本手册贴进去,就是每问一次都为整本手册付一次钱。
把这堵墙钉死的是一句关于用户的话
作者写了一句我认为是全书最实在的话:
没人愿意为一个精心组织的答案等上 10 秒钟, 因为同样的信息从普通搜索引擎那里几乎是瞬间就能拿到4。
他的原话是:这类应用「仍然在和传统搜索引擎争夺用户的期待和耐心」。
你的竞品不是另一个 AI,是用户已经被搜索引擎养成的那点耐心。
判断(我们的,不是书里的): 这两堵墙的地位完全不同,值得分开记。 第一堵(读不下)是技术限制,在退;第二堵(慢和贵)是经济与体验限制,不会退。 就算哪天上限大到能塞下你整个知识库,先搜再答这件事也不会消失—— 因为塞进去的每一个字都要付钱、都要等。 如果错,会错在: 如果模型的处理速度和价格降到某个程度,让「整本塞进去」的代价小到可以忽略, 那这条推导就失效了,先搜再答会退化成一种可选的改良手段而不是必需品。 判据是:同样一个问题,整本塞和先搜再答,响应时间和花费差几倍——差得不明显那天,这条就该重写。
4. 插一句:那个「八成」的数字,打个折再用
这一节只做一件事:告诉你哪些数字不能直接引用。
先说清两个词:
| 词 | 是什么 |
|---|---|
| 结构化(排成了整齐行列、机器直接能查)的数据 | 数据库表、Excel 表格 |
| 非结构化(没有固定格式、机器不知道从哪儿下手)的数据 | 一篇报告、一封邮件、一段录音 |
上面那句「公司里八成信息是非结构化的」,你会在无数篇文章里看到。它来路不明。
这个「八成」能追到的最早出处,是 1998 年美林证券的一份材料,原话是 「非结构化数据占了一个组织中数据的绝大部分,某些估计高达 80%」—— 注意它自己就是转述别人的估计。而这个数字底下从来没有人找出过原始研究5。
判断(我们的,不是书里的): 这个数字方向是对的,那个具体数值是假的。 它统计的是字节(衡量数据体积的基本单位,一个英文字母大约占一个字节; 你在电脑上看到的文件大小,就是按它算的),而一段视频的体积能顶几百万行数据库记录—— 所以它几乎是自动成立的,却说明不了「你要用的信息在哪儿」。 用它来说明「值得做这件事」没问题,写进任何需要负责的材料里就别引它。 如果错,会错在: 如果确实存在一份我们没找到的原始统计,那这条提醒就过度谨慎了。 但即便如此,「按体积算」这个方法论问题依然在。
5. 剩下的那条路:先找,再答
这一节给出全书的核心动作。
既然不能全塞,那就只塞相关的那几段。
用户问一句
│
├─ 第一步:从你自己的资料里,搜出最相关的三五小段
│
├─ 第二步:把「这几段 + 用户的问题」拼成一段话,发给模型
│
└─ 第三步:模型照着这几段写答案
图说:模型的角色从「知识来源」降级成了「写作工具」。知识来自你的资料。
这套做法的名字是 RAG。三个英文单词的首字母,拆开是「检索增强的生成」:
- 检索:就是「搜」——从一堆资料里把相关的挑出来;
- 生成:就是「让模型写出来」;
- 增强:指搜到的东西被塞进提示里,用来给模型补课。
作者给的一句话定义最好记:
一个 RAG 系统 = 一个搜索引擎 + 一个大语言模型。 搜索引擎负责在你的数据库里找到最相关的信息,模型负责根据它写出答案。6
这个名字不是这本书起的。 它来自 2020 年 5 月的一篇论文,第一作者是 Patrick Lewis。
那篇论文的说法比「搜索 + 生成」这个通俗解释更准:一个模型手上其实有两份东西可用, 而 RAG 就是让它同时用上这两份6。
- 模型脑子里那份: 改不了、查不到来源,也不知道过没过期;
- 外挂那份: 可以随时更新,而且能指出这句话是从哪份文件的第几页来的。
为什么这个区分有用: 它说明了 RAG 到底改善了什么——不是让模型变聪明, 是给它换了一份能改、能查、能标出处的资料。
6. 补课:「搜」到底怎么搜 —— 把意思变成位置
这一节是我们补的,不是书给的。 书里管这一步叫「详见后文」,而后文正好不在我们这一版里—— 可是不讲它,后面六章全都悬空。所以在这里补到「够用」的程度。
先看问题出在哪
用户问:「去年欧洲业务为什么下滑?」 你的文档里写的是:「EMEA 区营收同比走弱,主因是渠道库存积压。」
一个关键词都对不上。 按关键词搜,这份文档永远搜不到。
所以要搜的不是字,是意思。 可「意思」这东西,机器怎么比?
办法:给每段文字发一个坐标
先想一件更笨的事。 假设我们只用两个数来描述一句话:第一个数记「这句话跟动物有多大关系」, 第二个数记「跟财务有多大关系」。那「小猫在睡觉」就落在(高,低)那个角, 「季度营收报表」落在(低,高)那个角——它俩自然就离得远; 而「猫咪打盹儿」会落在「小猫在睡觉」旁边,因为这两句在这两把尺子上给的分几乎一样。
真实的做法就是这件事,只是把两把尺子换成一千多把。 区别只有一处: 这一千多把尺子各管什么,不由人来定——而是让一个专门的模型 从海量文字里自己试出来,试到「意思近的两句话得分也近」为止。
所以下面这三串数不是凭空落下来的,它们就是同一句话在这一千多把尺子上的得分:
「小猫在睡觉」 ──→ [0.21, -0.05, 0.88, … ] 一串几百上千个数
「猫咪打盹儿」 ──→ [0.19, -0.07, 0.85, … ] ← 和上面几乎重合
「季度营收报表」──→ [-0.63, 0.44, 0.02, … ] ← 离得很远
图说:意思相近的句子,数字也相近。于是「像不像」变成了「离多远」。
这一串数有个名字,行话叫嵌入(英文 embedding:把一段文字嵌进一个由数字搭起来的空间里, 让它在里面占一个位置)。关于它,先记住两件事: 第一,它是算出来的,不是查表查来的——任何一句话,哪怕从没人写过,也能当场算出一串; 第二,意思越近的两段话,算出来的两串数也越近,上面那张图就是在说这件事。
这串数有多长?常见的是几百到几千个数,OpenAI 那个嵌入模型给的是 1536 个7。 数学上管这样一串按固定顺序排好的数叫向量——跟「嵌入」是同一样东西的另一个名字。
本文后面一律叫「嵌入」。
书里对负责这件事的模型有一句很到位的形容:所有人都在谈会写字的大模型, 可真正的无名英雄是嵌入模型——它把词句的意思变成多维的数, 分类(分类就是给东西贴标签)、聚类(聚类就是把相似的东西自动归堆)、 推荐这些活儿全靠它8。
「离多远」怎么算
最常用的一个办法叫余弦相似度——它只看两串数指的方向像不像,不看它们各自多长。 方向越接近,它给的分越高;所以余弦相似度是越大越像。 好处很直接——一句短话和一段长文,只要说的是一回事,方向就接近,不会因为长短悬殊被判成不像。
这里有一句桥必须当场搭上,不然后面两章会读拧。 这一行里有两个方向相反的说法,其实是同一件事的正反两面:
| 说法 | 方向 | 怎么读 |
|---|---|---|
| 相似度(余弦相似度就是一种) | 越大越像 | 「这两段有多像」 |
| 距离 | 越小越像 | 「这两段离多远」 |
相似度越大 = 距离越小,把「有多像」倒过来说就是「离多远」,换算而已,不是两件事。
本文后面一律说「距离」,因为书里就是这么说的——它在讲按意思切分文档时给了一句判据, 记住它就够用了:距离越小越相似,距离越大越不相似9。 至于具体用哪个公式,书里指向了不存在的后文。
存在哪儿
算好的嵌入要存起来,存的地方叫向量库(也叫向量数据库)。
它和普通数据库的区别只有一条: 普通数据库擅长回答「哪一行的编号等于 1024」, 向量库擅长回答「哪几条离我给的这串数最近」。
书里的说法是:入库阶段要把「我们所有可用的文本内容装进向量库」10。
7. 于是整件事裂成两条流水线
这一节是全书的骨架,后面六章都挂在它上面。
为什么必须裂成两条?因为算嵌入是要花时间和钱的。 你不可能等用户问了问题,再现场把整个知识库算一遍。必须提前算好。
提前算好的那条线,行话叫离线。注意这里的「离线」跟有没有联网毫无关系—— 它说的是「不在用户等着的时候跑」。所以它可以半夜跑,可以跑一整天, 也可以中途失败了明天重跑一遍,没有人会因此看着一个转圈的界面干等。
跟它对着的那条线叫在线:用户正 盯着屏幕等结果,每多花一秒都是他在等。
┌─ 入库线(离线跑:不在用户等着的时候跑,慢一点没关系,做一次管很久)─┐
│ │
│ 你的文件 → 读成文字 → 切成小块 → 每块算出嵌入 → 连同出处存进向量库 │
│ (第02-04章) (第05章) │
└──────────────────────────────────────────────────────────────────┘
┌─ 问答线(用户在等,必须快)────────────────────────────────────┐
│ │
│ 用户的问题 → 算出嵌 入 → 在向量库里找最近的几块 → 拼成提示 → 模型写答案 │
│ │
└────────────────────────────────────────────────────────────────┘
图说:两条线各三步,书里就是这么分的。注意两条线都有「算嵌入」这一步。
书里把这两条线分别列成了三步11:
| 入库线 | 问答线 |
|---|---|
| 加载:从 Word、PDF、Excel、数据库等各种地方把内容读出来 | 把问题变成嵌入 |
| 切分:切成小块,因为嵌入模型和大模型都有读不下的上限 | 找相似:在向量库里算距离,找出最像的几块 |
| 算嵌入:把每一小块变成一串数,这样才能算相似度 | 答题:模型根据找到的那几块内容作答 |
这里有一条容易漏掉、漏了就全错的规矩
书里在问答线第一步的括号里悄悄写了一句,它是硬约束:
把问题变成嵌入时,必须用和入库时同一个模型12。
为什么: 不同的嵌入模型,给同一句话算出来的数完全不一样, 甚至连长度都不一样。拿 A 模型算的问题去和 B 模型算的文档比距离,算出来的数字毫无意义—— 而且它不会报错,只会给你一堆看起来随机的结果。
实际后果: 你哪天想换一个更好的嵌入模型,整个向量库都得重算一遍。 这是这套架构里最贵的一次决策,书里只用一个从句带过。
8. 从头走一遍:一次真实的问答
这一节把前面七节讲过的每一件事,拿同一个输入从头走到尾,每一步旁边写出具体的数。 读到这里你已经知道每个零件是干什么的了,这一节回答的是「它们串起来到底发生了什么」。
先声明:下面这些数是为演示编的,不是真实数值。 书里只给了一个真数:嵌入模型一次最多吃 8191 个标记(第 05 章会用到)。 其余的字数、秒数、距离、坐标,全部是我们为了让每一步看得见而编的,不许引用。
输入只有两样东西:
- 一份文件:
员工手册.pdf,三百页; - 一个用户,现在打字问:「试用期请假怎么算?」
第一步:先算一笔账 —— 整本塞进去,塞不下
手册全文约 30 万个字符。按第 3 节那个换算(英文里 1 个标记 ≈ 4 个字符), 折成 7.5 万个标记。而我们这次用的模型,一次能读进去 8000 个标记。
手册 7.5 万标记 ───────────────────────────────── 塞进去
模型这次能读 8000 标记 ────── 装得下
图说:两个数一比就完了 —— 手册是模型这次容量的九倍多。**第一堵墙,过不去。**
第二步:就算塞得下,也不该塞 —— 一次问答的账单
假设换一个能读下 7.5 万标记的模型(这类模型确实有)。那么:
- 钱: 这类服务按「读进去多少字 + 写出来多少字」收费。 用户每问一句,你就为整本手册的 7.5 万个标记付一次钱;他一天问二十次,你付二十次;
- 时间: 模型要把这 7.5 万个标记全部读一遍才开口,第一个字出现前用户等了 12 秒。 而作者的标尺是:没人愿意为一个精心组织的答案等上 10 秒(第 3 节)。
第二堵墙就在这里:不是做不到,是每问一次都要重付一次全书的钱和全书的等待。
第三步:离线时,手册早就被拆好了
所以真正的做法是在没人等着的时候(第 7 节那条离线的入库线)先把手册收拾好:
员工手册.pdf(300 页)
│
├─ 读成文字 ──→ 30 万字符
│
├─ 切成小块 ──→ 2000 块,每块 100 到 200 个字
│ 其中第 87 页那一块的内容是:
│ 「试用期内每月可请事假两天,需提前一个工作日报备。」
│
├─ 每块算出嵌入 ──→ 这一块算出来是 [0.11, 0.47, -0.02, … ],一共 1536 个数
│
└─ 连同出处一起存进向量库
这一块贴着的标签是:「员工手册.pdf / 第 87 页」
图说:这一步花了多久没人在意 —— 它跑在半夜。**注意最后一行:出处是跟着这一块走的,
不是记在文件那一层的 。**这是第 02 章的主题。
第四步:用户按下回车,他那句话也被算成一串数
用户那句「试用期请假怎么算?」,用的必须是第三步那个一模一样的嵌入模型,
算出来是 [0.13, 0.44, -0.05, … ],同样 1536 个数。
这就是第 7 节那条硬约束在这一步的样子。 如果这里换成了另一个嵌入模型, 算出来可能是 768 个数,长度都对不上;就算长度碰巧一样, 这两串数量的也不是同一批尺子,比出来的远近毫无意义,而且系统一声不吭。
第五步:跟库里两千块比距离,取回最近的三块
拿用户那串数,去和库里 2000 块各自那串数算距离(第 6 节:距离越小越像):
| 库里的块 | 算出来的距离 | 结果 |
|---|---|---|
| 第 87 页「试用期内每月可请事假两天」 | 0.12 | 取回 |
| 第 91 页「实习生请假须由带教人签字」 | 0.31 | 取回 |
| 第 12 页「差旅报销凭据须在十日内提交」 | 0.88 | 不取 |
注意第二行: 「实习生请假」这块被取回来了,因为它跟问题确实像—— 可它说的是另一类人。这就是第 06 章那一整章要处理的事:像,不等于对。
第六步:三块加原问题,拼成一段话发出去
最后发给模型的那段话(第 3 节说过,它叫提示)长这样:
【拼好的提示,约 900 个标记】
资料一(员工手册.pdf 第 87 页):试用期内每月可请事假两天,需提前一个工作日报备。
资料二(员工手册.pdf 第 91 页):实习生请假须由带教人签字。
资料三(员工手册.pdf 第 12 页):差旅报销凭据须在十日内提交。
问题:试用期请假怎么算?
图说:900 个标记,是第二步那 7.5 万个标记的八十分之一 —— 这就是「先找再答」省下的东西。
模型答完还能说出「见员工手册第 87 页」,因为出处是跟着块一路带过来的。
这条走查上,这一章的六个零件各占一步: 上下文上限(第一步)、按量计费与等待(第二步)、嵌入与向量库(第三步)、 同一个嵌入模型(第四步)、距离越小越像(第五步)、提示 = 问题 + 资料(第六步)。
9. 为什么这本书用两整章讲入库线
看上面那张图:问答线一共三步,而且每一步都很短。难点全在入库线。
作者的原话是:流程听起来很直白,可一旦要处理来源不同、形态也不同的数据, 事情立刻变得棘手——所以加载流水线的设计**「如此关键,而且需要创造力」**13。
「形态不同」指的是:同样一份季度汇报,可能是 Word、可能是 PDF、 可能是一段两小时的会议录像、也可能是一张只有图没有字的幻灯片。 它们最后都要变成同一种东西才能进库。
入库线上依次要过四道关,后面四章一章拆一道。 (注意这里 换了个词:前面那「两堵墙」说的是此路不通, 而这四道是路能走、但得一道一道过——所以叫关,不叫墙。)
| 关 | 在哪一章 |
|---|---|
| 文档格式各不相同,而且结构里藏着信息 | 第 02 章 |
| 表格和数据库根本不是「文章」 | 第 03 章 |
| 录音、图片、视频里没有文字可读 | 第 04 章 |
| 切成小块,切在哪儿决定了以后搜不搜得到 | 第 05 章 |
10. 作者的一句警告:先别急着上工具包
这一节是作者自己在第 1 章开头就说的话,而且他的立场比大多数教程克制得多。
你会在这本书里频繁看到两个名字:LangChain 和 LlamaIndex。 它们干的事是把上面那些步骤(读文件、切块、算嵌入、存进向量库、检索) 各自打包成一段现成的、写好名字就能直接叫来用的代码, 让你少写很多「把这个零件接到那个零件上」的连接代码。
这里要给一个后面每一章都在用、却从来没人定义过的字下个定义。
别人写好、你装上就能直接叫来用的那段现成代码,行话叫「库」。 你后面每一章都会撞见它:
python-docx、PyPDF2、unstructured、Whisper、pgvector,全是库。 大一点、把一整串步骤都打包好的,行话叫「工具包」或者「框架」—— 本文里这三个词指的是同一类东西(别人写好的现成代码),只是规模不同; LangChain 和 LlamaIndex 属于后者。
必须提醒一句,因为这个字在这一行会撞车:
| 写法 | 是什么 | 干什么用 |
|---|---|---|
| 库 | 一段现成的代码 | 拿来干活的工具 |
| 向量库(第 6 节讲过) | 一种数据库 | 存嵌入的地方 |
两个词长得像,意思完全不同。 本文后面单说「库」就是指现成代码; 指存嵌入那个地方时,一律写全「向量库」。
作者的态度,原话大意是14:
用它们是合理的,它们确实顺手。但先确认你是不是真的需要。 它们仍处于早期阶段、一直在变,在把应用部署到生产环境时这会很麻烦。 而且它们不过是一堆更成熟的框架的集合——你完全可以直接用它们背后的那些框架。
「生产环境」是什么意思: 就是真正给用户用的那套系统, 区别于你自己电脑上跑着玩的那份。生产环境里,一次依赖升级把服务弄挂,是要背责任的。
判断(我们的,不是书里的): 这条警告在这本书出版之后被现实追认了一次。 我们核对到:LangChain 那个专门放不稳定功能的「实验区」包 (
langchain_experimental),已经在 2026 年 6 月被官方封存、不再维护—— 而书里第 2 章推荐的「按意思切分」的工具正是从那个包里取的15。 说清楚范围:这条只关于 LangChain。 LlamaIndex 没有同名的包, 我们也没有去核对它的情况——别把这一条读成「两家都被封存了」。 如果错,会错在: 如果那个功能在封存前已经被搬进了稳定的主包, 那么受影响的只是代码开头那一行「我要用哪个包里的什么东西」的写法,不是功能本身。 但「从实验区取零件上生产」这个判断依然成立。
11. 作者的判断与证据:哪些有依据,哪些是经验
这本书是配方书,大部分说法属于「作者的从业经验」,不是实验结论。分清楚很重要:
| 说法 | 属于哪一类 |
|---|---|
| 模型有上下文上限、提示越长越慢越贵 | 事实,可验证 |
| 「没人愿意等 10 秒」 | 作者的经验判断,书里没有用户研究支撑;方向可信,数字别引 |
| 「公司里八成信息是非结构化的」 | 转述的行业说法,来路不明(见第 4 节) |
| 「加载流水线的设计需要创造力」 | 作者的立场,也是这本书存在的理由 |
| 「这些工具包还在早期、别急着上生产」 | 作者的经验判断,后来被现实部分证实(见第 10 节) |
12. 边界与局限
这一章之外,这本书还欠着三件事:
- 嵌入怎么算出来的,书里没讲——它把这一步指向了一个不存在的章节。 第 6 节是我们补的,够你读懂后面六章,不够你自己去实现一个;
- 检索本身没讲。找出「最近的几块」之后还有一大堆学问 (先用关键词粗筛再用嵌入细排、找回来之后再排一次序),这一版里一个字都没有;
- 成本没有任何数字。「慢」和「贵」是这一章的立论基础, 但全书没有给出任何一组延迟(从你按下回车到看见第一个字之间的等待)或价格的实测。
13. 可带走的
- AI 答不出你的事,只是因为它没见过——不是能力问题,是资料问题;
- 整本塞进去这条路被两件事堵死:一次读不下,以及塞得越多越慢越贵; 前者在退,后者不会退;
- 你的对手是用户的耐心,不是别的 AI。作者的标尺是「没人愿意等 10 秒」;
- RAG = 先搜出相关的几段,再让模型照着写;它把模型从知识来源降成了写作工具;
- 搜不能靠关键词,要靠意思——把文字变成一串数(嵌入),比谁离得近;
- 向量库的唯一本事就是「找最近的几条」,别拿它当普通数据库用;
- 整件事分成两条线:入库(离线、慢)和问答(在线、快);
- 问题和文档必须用同一个嵌入模型,否则结果毫无意义——而且不会报错; 换模型 = 整个向量库重算,这是最贵的一次决策;
- 难点全在入库线,所以这本书用两整章讲它;
- 「八成信息是非结构化的」这个数字来路不明,方向可用,那个数值别引;
- 工具包能省事,但作者自己都提醒:上生产之前先确认你真的需要它。
14. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 八成信息是非结构化的 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:13(搜「80% of information is unstructured」) |
| 嵌入模型是无名英雄 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:17(搜「unsung heroes」) · text/04-ch01-chapter-1-loading-data.txt:17(搜「multidimensional vectors」) |
| 上下文上限、提示越长越慢越贵 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:19(搜「each model has a maximum context size」) · text/04-ch01-chapter-1-loading-data.txt:19(搜「building huge prompts leads to long response times」) |
| 没人愿意等 10 秒 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:21(搜「10 seconds for a well-crafted answer」) · text/04-ch01-chapter-1-loading-data.txt:21(搜「competing with traditional search engines」) |
| RAG = 搜索引擎 + 大模型 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:23(搜「RAG combines the strengths of search engines」) · text/04-ch01-chapter-1-loading-data.txt:41(搜「combines a search engine and a LLM」) |
| 入库线三步 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:25(搜「load all our available text content into our vector store」) · text/04-ch01-chapter-1-loading-data.txt:29(搜「Split text: Split the text into smaller chunks」) · text/04-ch01-chapter-1-loading-data.txt:31(搜「vector representations of the text chunks」) |
| 问答线三步、必须用同一个模型 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:35(搜「using the same model as during the loading process」) · text/04-ch01-chapter-1-loading-data.txt:37(搜「calculating the distance between the question embedding」) |
| 加载流水线需要创造力 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:45(搜「so essential and requires creativity」) |
| 别急着上工具包 | Chapter 1. Loading Data | text/04-ch01-chapter-1-loading-data.txt:51(搜「check first if you really need them」) · text/04-ch01-chapter-1-loading-data.txt:51(搜「merely a collection of more established frameworks」) |
| 距离越小越相似 | Chapter 2. Data Preparation | text/05-ch02-chapter-2-data-preparation.txt:577(搜「A smaller distance means higher similarity」) |