ARTICLE · 1347482

先别急着把文档丢给它——为什么大模型答不了你公司的事

发布时间：2026-11-12 22:22:43 最近访问：2026-11-12 22:22:43

先别急着把文档丢给它——为什么大模型答不了你公司的事

手搓一个 AI 应用 · 第 1 篇。从一个新人天天问的内部问题讲起,告诉你为什么直接把公司文档丢给大模型不行——塞不下、找不准、答不对。读完你会知道,接下来这 12 篇你要手搓的到底是个什么东西。

开头 · 新人又在群里问了第十遍

先说个场景,看眼不眼熟。

团队来了个新人,在群里问:"我们 CI/CD 怎么配?测试环境部署走哪个流水线?"这是他这周第三次问类似的问题。老人被问烦了,随手把一份 Confluence 文档链接甩过去,新人点开一看,三十多页,找半天没找到"测试环境"那段。

你想:这事让 AI 干不就行了?于是你打开 ChatGPT,问它"我们公司 CI/CD 怎么配到测试环境"。它给你洋洋洒洒写了一大段——用的全是业界通用做法,跟你们团队实际那套流水线没半毛钱关系。你把那份 Confluence 文档整篇贴给它,它又说"文档太长了,我处理不了";你只贴了相关那一节,它倒是答了,可它不知道你们"测试环境"指的是那台叫 test-box-03 的机器,给的步骤对不上。

问题不在 AI 笨,在于你手上的大模型是个空铺子。

还记得《AI 在工作中》那个实习生吗?它博学但没记忆——你问它公司的事它就编。旧系列教你把数据贴给它让它加工;但这次你要自己开店了,不能每次有新问题都手动翻文档、手动贴给它——你得把货摆上货架,让它自己取。这就是接下来 12 篇你要手搓的东西:一个懂你们公司、能自己找资料、会答内部问题的 AI 应用。

这篇是地基,只讲清一件事:为什么不能直接把文档丢给它——三个不行,以及解法长什么样。

一、空铺子:你手上的大模型缺的是什么

先把概念摆正。你直接能调到的那个大模型(不管是 GPT、Claude 还是别的),它训练时读过的是互联网上的公开文字——维基百科、博客、公开论文。它没读过你公司任何一份内部文档。

一句话定义:

你手上的大模型,就是你刚租下的一个空铺子。地方有了,伙计(模型本身)也聪明、嘴也会说,但货架上空空荡荡——你公司的事,一件货都没进。

客人(用户)进来问"你们退货政策是什么",铺子里没这件货,伙计又不能不说话,于是他就按概率编一个最像答案的给你。这就是旧系列讲过的"幻觉",在"答公司内部问题"这个场景里,它不是偶尔出错,是必然出错——因为它真的不知道。

那你说:我手动把文档贴给它不就行了?这就像客人来问,你现场从仓库翻出一卡车货倒在柜台上让伙计现找。能找到吗?分三种情况,每种都不行:

你怎么喂	发生什么	为什么不行
不喂(直接问)	伙计编一个	货架上没货,只能按概率接龙
整篇文档全贴	报错或"记不住后面"	柜台就那么大(上下文窗口有限),一卡车货倒上来堆不下,边收边掉
只贴相关那一节	能答,但你得自己先找到是哪一节	你又变回人工检索了,没解决问题

这三种情况,就是接下来你要手搓的东西要治的三个病。给它们起个名字,后面 11 篇都围着它们转:塞不下、找不准、答不对。

二、三个"不行",逐个看明白

1. 塞不下:柜台有限,一卡车货倒不下

大模型有个东西叫上下文窗口(旧系列第 3 篇详细讲过,这里只用结论):它能一次"看"的文字量是有上限的。你公司几十上百份文档,全塞进去它装不下;就算装下了,中间那部分它也容易"看漏"——这有个专门的坑叫 lost in the middle,内容越多,它对中间部分的注意力越差。

所以"把所有文档全贴给它"这条路,从物理上就走不通。

2. 找不准:就算塞得下,它也不知道哪段相关

退一步,假设文档少、塞得下。你问"测试环境部署走哪个流水线",文档里有三十页,真正相关的是第 18 页那段。大模型不会"检索",它是把所有喂进来的内容一起读、一起接龙——它分不清哪段是你这次该看的重点,容易被无关段落带偏,把通用那部分写给你。

你手动只贴第 18 页?那你又得先自己找到第 18 页。你把检索的活又扛回来了,这跟没用 AI 有什么区别。

3. 答不对:就算找对了段,它也可能理解偏

就算你精准贴了相关那一节,大模型答的时候还是可能出错——它不知道你们"测试环境"特指 test-box-03,不知道你们流水线里那个 deploy.sh 是定制过的。它会按通用理解答,步骤对不上。

三个不行,根子是同一个:铺子里没货,或者有货也没摆好,伙计再聪明也没用。

三、解法长什么样:把货摆上货架,让它自己取

讲完病,讲药。药就一句话:

别让伙计看你临时倒在柜台上的货,要提前把货进好、贴上条码、摆上分类架,客人来问,伙计自己去架上取最相关的几本,翻完了再答。

这套做法有个大名:RAG(Retrieval-Augmented Generation,检索增强生成)。别被这英文吓到,翻译成人话就是"先检索、再生成"——先从你的文档里检索出相关内容,再让大模型基于这些内容生成答案。

对应前面三个病:

病	RAG 怎么治	对应铺子里干什么	本系列哪篇讲
塞不下	只取相关的那几段喂给模型,不全塞	不倒一卡车货,只取几本相关书	第 4-6 篇(切分、检索、精筛)
找不准	用向量检索自动找相关段,不用人找	给书贴条码、按条码摆架、自动叫号取	第 3-5 篇(Embedding、向量库)
答不对	基于取到的原文生成,并附引用来源	伙计翻着取来的书答,指给你看哪页	第 7-8 篇(对话引擎、全链路)

这就是你接下来 12 篇要搭的东西的全貌。先给你看一眼"手动 RAG"长什么样——其实你前面贴第 18 页那一节让模型答,就是一个粗糙的手动版。RAG 只是把"找哪一节""贴给谁""怎么答"这三步自动化了。

四、手把手:用 30 行代码看清"空铺子"和"有货"的区别

空讲不如上手。这一节用 Python 跑一个最小对比:同一个内部问题,不喂文档vs手动喂相关文档,看大模型答得有什么不一样。这一步不改任何东西,只为让你亲手摸到"塞不下/找不准"的实感——后面 11 篇都是在改这段代码,把它一步步变成真的 RAG。

环境:Python 3.8+,装一个 OpenAI SDK(用任何兼容 OpenAI 接口的模型都行,国内模型把 base_url 换成对应地址即可)。

pip install openai

代码(保存为 rag_00_empty_shop.py):

# rag_00_empty_shop.py# 依赖:openai>=1.0.0# 说明:演示”空铺子”vs”手动喂货”的答案差异。运行前设好 OPENAI_API_KEY。from openai import OpenAIclient = OpenAI()# 默认读环境变量 OPENAI_API_KEY；用国内模型可传 base_url=...MODEL = ”gpt-4o-mini”# 换成你实际能用的模型# 你团队的真实情况(假装这是一份内部文档里的一节)INTERNAL_DOC = ”””我们的 CI/CD 流水线部署到测试环境(test-box-03)的步骤:1. 代码合入 release 分支后,流水线 job `deploy-test` 自动触发。2. job 会执行仓库里的 ./scripts/deploy.sh,把产物 scp 到 test-box-03:/srv/app。3. 部署完成后,在飞书群 #release-notify 会收到一条机器人通知。注意:测试环境绝不接受手动 ssh 上去改文件,一切走流水线。”””QUESTION = ”我们测试环境怎么部署?能直接 ssh 上去改吗?”def ask(question, doc=None):    ”””空铺子(doc=None)或手动喂货(doc=文档)。”””    if doc:# 手动版:把相关那一节贴给它        prompt = f”根据下面的内部文档回答问题,不要编造文档里没有的内容。\n\n文档:\n{doc}\n\n问题:{question}”    else:# 空铺子:直接问        prompt = question    resp = client.chat.completions.create(        model=MODEL,        messages=[{”role”: ”user”, ”content”: prompt}],    )    return resp.choices[0].message.contentif __name__ == ”__main__”:    print(”=== 空铺子:直接问 ===”)    print(ask(QUESTION))    print(”\n=== 手动喂货:贴相关文档 ===”)    print(ask(QUESTION, INTERNAL_DOC))

预期输出(大意,具体措辞看模型):

=== 空铺子:直接问 ===(模型会编一套通用 CI/CD 流程,提到 Jenkins/GitHub Actions 之类,说”一般可以 ssh 上去部署”——全错,因为你们根本不让 ssh)=== 手动喂货:贴相关文档 ===(模型会基于 INTERNAL_DOC 答:走 release 分支触发 deploy-test job,执行 deploy.sh scp 到 test-box-03,在 #release-notify 收通知;并明确说不能 ssh 手动改——全对)

跑完你会真切看到一件事:同一个模型、同一个问题,有没有货,答案天差地别。空铺子答得越流畅越坑人;喂了货就答得准。

但你也一眼看出这个手动版的毛病:

文档是我手动找好、手动贴的——这正是"找不准"病没治,我又当了一回人肉检索引擎。
只贴了一节——如果文档有几十份,我得先知道该贴哪一节,这不可持续。
每次问题不一样,我得每次重新找——新人来问,他不会找,我也没法替所有人找。

接下来 11 篇,就是把这"手动找、手动贴、手动答"一步步自动化:

第 2 篇:先画张施工图,看清要造的铺子有几个房间。
第 3-5 篇:给文档贴条码(Embedding)、切分(chunking)、上架(向量库),让"找相关段"从人肉变成自动。
第 6-8 篇:精筛、对话、串成流水线,让"取对货、答对话"自动化。
第 9-12 篇:装手、变掌柜、模拟考、挂牌营业,把它从能答变成能办事、能上线。

五、避坑清单(建议收藏)

这一篇的坑都围绕"以为直接喂文档就行"。五条,每条反例→正例:

反例:把整份 50 页文档一次性塞进 prompt,指望模型自己找重点。
正例:只取与问题相关的几段喂进去(这正是后面 RAG 要自动干的事);手动阶段就先自己定位再贴相关段。
反例:不喂文档直接问公司内部流程,模型答得很流畅,你就信了。
正例:凡是公司内部事实,一律走"先喂文档再答";模型没读过的内部数据,直接问必然编。
反例:手动贴了文档,但不让模型说"不知道",它在文档里找不到时还是会编。
正例:prompt 里加约束:"仅基于提供的文档回答,文档里没有就说'文档中未提到',不要编造。"——这能砍掉一大半幻觉。
反例:觉得"模型上下文窗口有 128k,够大,全塞进去就行"。
正例:窗口大不等于"看得准";内容越多越容易 lost in the middle。窗口是上限不是质量保证,该检索还是要检索。
反例:一上来就想用 LangChain 框架搭一套,先装一堆包。
正例:先用裸 SDK 跑通"问→喂→答"的最小对比(就像上面那段代码),理解每一步在干嘛,再上框架。框架是手脚,不是脑子——先有脑子再有手脚。