跨国深谈← 返回←搜代码不用向量库，搜公司文档为什么不行？

搜代码不用向量库，搜公司文档为什么不行？

关联

人物 George He

公司 LlamaIndex · Claude Code · Anthropic · LlamaParse · LightParse · TurboPuffer

概念 智能体 · 预索引 · RAG · 向量数据库 · grep · 上下文长度 · 文档解析

AI 智能体火了之后，一个老问题被重新翻了出来：

让模型在大量文件里找信息，到底是直接在本地文件系统里搜索，还是提前建好向量索引？

George He 是 LlamaIndex 的工程负责人，这家公司专门做文档解析和知识管理。

他用一场演讲把这个问题讲得很清楚：答案取决于你的数据长什么样、有多少。

为什么 Claude Code 不用向量库？

Claude Code 发布时，很多人好奇它内部怎么管理代码文件。

Anthropic 的选择是：不用预建索引，不做检索增强，就靠 grep、glob 这类本地文件搜索工具直接遍历 。

这之所以行得通，是因为代码有几个天然优势：

仓库通常不大，格式半结构化，而且代码本身会留下线索，导入什么、测试什么，都写在那里。

文件层级本身就是一张地图，智能体照着走就行。

Claude Code 的创始人 Boris 也说过，他们试过向量数据库，最后放弃了。不只是性能问题，更是维护问题：代码一直在改，预建索引很难保持同步 。

公司文档完全是另一回事

可一旦换成企业数据集，情况就变了。图片、PDF、PPT 混在一起，根本没有一个组织好的文件夹让你去 grep。

规模大得多，安全权限必须管，格式五花八门，可能有复杂的 PDF、制造图纸、电路原理图 。这种数据没法在本地跑。

那到底什么时候用哪种方案？George 给了一个粗略的判断：100 到 1000 个文件，本地搜索就够，智能体在上下文里能装下；

到了几万、几百万个文件，就必须有预建索引，至少给智能体一个大致方向，像指南针一样指出该往哪找 。

上下文窗口变大，反而更贵

有人会说，现在模型有 100 万 token 的上下文了，把文档全塞进去不就行了？George 算了笔账：用模型上下文做数据摄入和搜索，极其昂贵。

把二进制文件发给模型让它自己渲染再提取，每次都在烧 token 。

用子智能体分担也不划算。每个子智能体都需要完整上下文，即使用便宜的小模型，整个环境依然又耗 token 又慢。

所以为了避免每次重复处理文档，预建索引系统反而成了省钱的做法。

正确答案：给智能体一整套工具

George 的核心建议是：不要人为决定用哪种方案，而是做一个工具集，让智能体自己选。这套工具分两层：

第一层是定向，也就是回答该去哪里找。

这里推荐混合搜索：关键词搜索加上语义向量搜索，两者融合加权，再用重排序模型对前 100 条结果精排。

基准测试显示，混合方案明显好于单一方法，因为你不会被某一种搜索方式的盲区困住 。

第二层是深挖，包括列出文件、按元数据筛选、用 grep 在具体文件里找关键词，以及读取文档实际内容。

这样智能体先用搜索缩小范围，再用文件遍历深入细节，得出的答案是有据可查的，而不是编出来的。

复杂文档要先解析，还要存截图

表格、图表、扫描件、原理图，这些对传统索引流程是灾难，因为它们不是一行行给人读的文本，而是另一种表达。

LlamaIndex 的做法是用结构化解析工具，把表格和图表编码成 markdown，让智能体能理解空间布局 。他们有产品 LlamaParse，还开源了 LightParse。

一个有意思的技巧：解析时顺便给每一页存一张截图。这些 PDF 和 PPT 本来是给人看的，不是给机器消费的。

有了预建的截图索引，智能体在做检索时可以像人一样核对原始页面 。

生产环境的三个坑

真要上线，客户一定会问三件事。一是多租户：一个人能不能看到另一个人的数据？

Google Drive 或 SharePoint 的权限元数据怎么同步进来，还不能让系统停摆？二是数据新鲜度：数据一直在变，预建索引如何跟上？

这正是很多公司放弃预索引的原因 。三是存储架构：他们处理过千万级文档，建议数据落盘，再加一层内存缓存加速读取；

演示用的向量库是 TurboPuffer，权限过滤直接下沉到存储层。

演示：135 份财报，一个问题搞定

现场演示用的是从 Alphabet 财报提取的 135 个文件，混合了 HTM 和原始 PDF。智能体收到请求，给出 2021 到 2025 年的现金流量表，流程是：

先混合搜索定位相关片段，同时看到对应的页面截图，再 grep 确认具体文本，按偏移量精确读取内容。

整个过程不需要把文件下载到本地，直接操作远端存储。

最终结果是从多个文件里汇总出来的，每个数字都能追溯到具体文件。

George 的收尾一句话总结了全场：「搜索帮你找到信息，工具集给你能信任的结果」。

本集带走

• 代码仓库小、结构清晰、自带线索，本地 grep 就够，不必预建索引。
• 企业文档规模大、格式乱、权限敏感，必须有预索引加混合搜索。
• 上下文窗口再大，也别拿模型当解析器用，token 太贵。
• 最好的架构是给智能体一整套工具，搜索定位方向，文件遍历深挖细节。
• 解析复杂文档时存页面截图，让智能体能像人一样核对原文。

其中最重要的一点是，代码已经在磁盘上、在本地了，尤其是如果你的智能体有上下文的话，那为什么要用一个预检索系统把它复杂化呢？
And the largest part there is code is already on disk and local, especially if your agent has context, so why complicate it with a pre-retrieval system?
—— George He · [03:49]

你没法真正对一个公司数据集的文件夹做 grep，因为它不像代码那样组织有序。
You can’t really grep the folders across a company dataset because it’s not organized like code.
—— George He · [04:13]

但这里的主要结论其实是，它最终归结为你所拥有的数据的规模，以及你愿意投入多少整理成本来维护那套合理的检索系统或数据管理系统。
But the major takeaway here is actually it really comes down to the scale of the data that you have and how much curation effort you’re going to put in in order to maintain that retrieval system or that data management system that makes sense, right?
—— George He · [05:18]

一开始可能没问题，但如果你的 LLM 不理解位置和空间推理，到了某个时候就会崩掉。
It might be fine at the start, but if your LLM doesn’t understand the location and spatial reasoning, it falls apart at some point.
—— George He · [14:58]

这就是为什么 Anthropic 和许多其他公司差不多已经放弃了尝试预索引数据，因为如果你的数据复杂，数据新鲜度真的很难实现。
This is kind of why Anthropic, a lot of other companies have kind of given up on trying to pre-index data because data freshness is really hard to achieve if your datas are complex.
—— George He · [15:40]

但这里的要点和收获是：搜索帮你找到信息，而 harness 给你可信赖的结果。
But the idea here and the takeaway is that search helps you find information, and the harness gives you the results that you can trust.
—— George He · [22:49]