假设你给个人资料助手两份读书会通知，问报名截止日期。把两份正文一起交给模型，就能让它依据这些材料回答。
如果资料夹里已经存了几千份活动通知，同样的问题就多了一项选择：把整个资料夹交过去，先让助手挑文件读，还是先搜索相关内容？这些做法都会把资料交给模型，却在不同的位置决定“这次读什么”，因此增加的开销和可能漏掉的信息也不同。
我们用同一组教学资料看清这些差别。问题始终是：
青禾书店这次读书会的报名截止日期是哪天？如果有调整，以调整后的通知为准。
| 资料 | 发布日期 | 正文中的关键信息 |
|---|---|---|
| D1《读书会报名通知》 | 2026-09-10 | 青禾书店本次读书会报名将于2026年9月20日截止。 |
| D2《读书会报名调整通知》 | 2026-09-16 | 青禾书店本次读书会报名截止日期提前到2026年9月18日，原通知中的截止日期作废。 |
要支持“9 月 18 日截止”这个结论，需要取得 D2 的正文，知道它修改的是同一场活动。只看见“调整通知”的标题，还不知道日期怎样变了。
下面先分别看三种常见的处理过程。它们可以组合使用，尤其是按需读文件和检索，经常出现在同一条流程里。
1. 直接放入全文：先把确定要用的材料交齐
如果任务范围就是这两份短通知，程序可以读取它们，把正文和问题一起交给模型：
程序读取 D1、D2 的全文
↓
模型收到任务要求、两份正文和用户问题
↓
模型依据这些材料生成回答
这里没有“先让模型选资料”这一步。D1 的旧日期、D2 的新日期以及修改关系，都已经进入同一次回答所依据的输入。
这样做的好处很具体：程序的处理步骤少，也不会在按问题筛选资料时，把已经选定的 D2 漏掉。对于几份确定相关、篇幅不长的材料，这是很自然的起点。模型仍然可能误解内容，因此还要核对答案；材料给全了，只解决了取得依据的问题。
代价在资料增多时出现。假设把其余几千份通知也全部放入，请求中就会包含大量与这场读书会无关的文字。模型需要处理更多词元(Token)，这些文字也会占用它一次能处理的容量，也就是上下文窗口。超出窗口时，就无法继续按原样一次提交。
“全文”也不必指整个资料库。用户已经选中的两份文件、某个项目的三份说明，都可以构成这次任务的完整材料范围。选择全文方式，首先要明确的是哪些资料确实需要一起看，以及它们能否在为回答预留空间后放得下。
只要这个范围小、材料已知，增加搜索步骤未必有收益。两份通知本来就都需要读取，先搜出这两份再读，通常只是增加了取资料的环节。
2. 按需读文件：先给线索，运行时再决定读什么
现在假设通知已经很多，但按活动归档，文件名也比较清楚。程序可以先提供相关目录中的文件名和编号，让模型决定需要哪些正文，再由程序执行读取。
对于这道日期问题，一条合理的处理路径是：
模型先看到问题，以及 D1、D2 的标题和发布日期
↓
模型提出读取相关通知，程序打开文件并返回正文
↓
模型根据已读内容决定是否继续读取，或生成回答
关键变化是：正文不再全部提前进入输入，而是等到需要时才加入。 例如，目录里还有场地布置说明和往期活动照片清单，当前日期问题未必需要读取它们。
文件线索因此承担了实际职责。标题、所在目录、日期或简短说明，需要足以帮助定位资料。模型能选择一个文件，不代表已经读到文件内容；程序成功返回正文后，这些内容才成为回答依据。
这种做法也有两项容易被忽略的成本。
首先，运行中多了选择、读取和回传的步骤。若模型先读一份，再判断需要另一份，就会增加往返等待。假如最后两份通知都读完了，最终需要处理的正文并没有减少，还多了调用记录。它的收益来自少读无关内容，不能仅凭“按需”二字认定更快或更省。
其次，挑文件依赖线索。假设 D2 被放在“其他事项.txt”里，标题无法显示它与读书会有关，只浏览文件名就可能漏掉它。此时可以搜索正文，或者先缩小目录再检查内容。如果只是把几千个文件名全部放入输入，选择负担也没有消失。
按需读取同样受上下文容量限制。读进来的内容越积越多，后续输入仍会变长；它改变了资料加入的时机，并没有让可用空间变成无限。
3. 先检索：回答之前，先按问题筛出相关内容
当资料分散在许多文件里，用户又不知道应该打开哪一份时，可以让程序先搜索。
检索就是按问题或查询条件，从可访问的资料中找出相关内容。它可以根据标题、正文关键词，也可以使用按含义匹配的搜索方式。返回对象可以是一整份文件，也可以是文件中的一段内容。
一种简单的安排是由程序先执行检索，再把结果交给模型回答：
程序根据问题搜索“青禾书店、读书会、报名”等相关内容
↓
搜索取得 D1、D2 的相关正文，并保留标题、日期和出处
↓
模型收到问题与检索结果，依据取得的内容生成回答
与直接放入全文相比，取舍发生在回答之前：模型得到的是搜索找回的部分，而非资料库中的所有内容。与逐份挑文件相比，搜索可以直接定位正文里的信息，不要求模型先看遍文件名。
如果一份文件汇集了全年的活动通知，检索可以定位到读书会的有关段落。返回内容应保留“哪场活动、改成哪天、原日期是否作废”这些关系，并能找到原文。孤零零的“9 月 18 日”很短，却不足以支持这个答案。
先取得相关外部资料，再让模型依据这些资料生成答案，就是检索增强生成的一种常见形式，英文简称 RAG。 这里增加的是回答时可用的依据，模型本身不必重新训练。RAG 也不限定某一种数据库；LangChain 的检索说明就列出了复用现有数据库、内部文档系统等资料来源的方式。
检索把输入缩小的同时，也增加了一道可能遗漏依据的环节。假设资料库里有 D2，但本次搜索只返回 D1，模型收到的材料就缺少调整内容。此时即使模型准确读懂 D1，也不能仅据这份旧通知确认最终日期。
这类问题需要沿资料取得过程查找原因：D2 是否进入搜索范围，查询能否匹配到它，返回数量限制是否把它排除，交给模型的片段是否保留了调整关系。只要求模型“更认真地回答”，不能补上输入里没有的依据。
如果为了加快查询，事先把文件整理成便于搜索的索引，还要维护这份索引。D2 新增或修改后，搜索材料必须相应更新。索引没有更新时，原文件已经变化，搜索仍可能取得旧内容。这是采用预先索引时增加的维护成本；直接搜索当前文件的实现则有自己的扫描开销。
4. 按需读取和检索，可以在同一个助手里配合
三种过程的差异，可以放在一起看：
| 常见安排 | 谁决定本次取哪些资料 | 用于回答的正文怎样进入输入 | 主要增加的负担 |
|---|---|---|---|
| 直接放入全文 | 用户或程序提前确定材料范围 | 选定材料的全文一起加入 | 材料多时输入较大 |
| 由模型按需读文件 | 模型根据问题、文件线索和已有结果提出读取请求 | 程序读取后分步加入 | 动作往返，以及选错或漏选文件的风险 |
| 程序先检索，再生成回答 | 程序执行查询和结果筛选规则 | 搜索取得的正文或片段加入 | 检索遗漏；使用预建索引时还有更新维护 |
表中的“按需读文件”选择了由模型决定读取对象的常见情形；路径已经确定时，程序也可以直接读取。检索同样可以成为模型调用的一项工具，让模型根据结果决定要不要再搜。
例如，资料助手可以先检索到 D1、D2，返回标题和短片段；模型发现还需要核对修改关系，再请求读取 D2 全文。这里既有检索，也有按需读取。它们分别解决“相关内容在哪里”和“现在还需要看多少内容”，并不冲突。
公开系统也有这种组合。Anthropic 关于上下文组织的工程文章介绍了 Claude Code 的做法：把项目说明文件预先放入输入，再通过文件名匹配、正文搜索等工具，在执行过程中寻找和加载其他内容。项目说明帮助确定工作约定，搜索和读取则补充当前任务需要的材料。
这个案例说明，提前给定内容与运行时取资料可以配合使用。它并没有给个人资料问答提供一个通用的速度或正确率排名。具体采用哪些步骤，仍要看资料组织方式与问题需要。
因此，看到一个助手使用文件工具，还不能判断它是否采用了 RAG；要看它是否围绕当前问题查找外部资料，并把取得的内容用于生成答案。RAG 也可以是程序安排好的“先查、后答”，不一定需要模型自己规划多个动作。
5. 选择方式，要看答案需要的资料有多难定位
资料数量有参考价值，但单独看数量容易误判。几千份文件中，用户已经明确指定的一份短通知，可以直接读取并交给模型；只有一份文件，却包含全年上千页记录，也可能需要先定位有关段落。
可以按当前困难选择起点：
- 相关材料已经确定，而且很短。 直接放入全文，先把问答做通。此时增加检索很可能没有减少需要读取的内容。
- 需要哪些文件，要看执行中取得的结果。 使用按需读取。例如，通知提到另有补充说明，取得这条线索后再读对应文件。
- 相关信息藏在大量文件或长文档中。 先检索定位，再根据片段是否足够，决定要不要补读原文。
比较开销时，要统计整个任务。最终回答的输入短了，前面却可能多了几次模型请求和搜索；一次读入的文字较多，也可能省掉多轮等待。费用还受服务计价和缓存情况影响，不能仅按最后一次输入长度判断。
验证时则先看依据，再看答案。用同一组资料和问题比较，记录实际取得了哪些内容、D2 的调整关系是否进入回答所用的输入、发生了多少次读取或搜索，再核对最终日期与出处。这样才能分清：变化来自取得资料的方式，还是模型对相同材料作出了不同理解。
可以用两个条件变化检查自己的选择：
第一种：资料库扩展到五千份文件，但用户明确要求“只解释我选中的 D2”，而 D2 只有三句话。还必须先检索吗？
不必。文件已经定位，内容也很短，直接读取全文即可。大资料库并不意味着每个问题都要搜索整个库。
第二种：问题改为“列出这个月所有修改过报名日期的活动”，搜索返回了五条最相关结果。能据此认为清单完整吗？
不能。找出几条相关资料，与覆盖“所有修改”是不同要求。需要检查约定范围内的通知及其更新关系，采用能覆盖该范围的查询或遍历，再根据容量分批读取。不能把只取少量结果的办法，直接当成完整清单的依据。
回到两份读书会通知：材料已经明确时，全文一起提供就足以作为起点；不知道该读哪个文件时，需要定位线索；有关内容分散或埋在长文档里时，检索帮助缩小读取范围。选择的落点，是以可接受的开销，把支撑当前答案所必需的内容完整交到模型手里。
