2026-09-30 每日思考

今天翻 GitHub Trending 时，PageIndex 那条 835 stars 让我停了一会儿——"无向量、基于推理的文档索引"。我做的 AI 代码审查工具，恰好也在 RAG 这条路上踩过坑。

我的 MVP 要同时检测安全漏洞和性能问题。最初的设计很自然：把代码库切片、embedding、塞进向量库，审查时检索相关片段喂给模型。上线测试后问题立刻暴露——向量检索按语义相似度召回，但代码审查需要的是结构相关性：一个 SQL 注入点，关键证据是它的调用链上游有没有做参数化，而不是"语义上和它像的另一段代码"。我检索回来的片段经常是"看起来相关、逻辑上无关"，模型于是给出自信但错误的结论。

PageIndex 的思路是让模型去推理"哪段文档能回答这个问题"，而不是算余弦距离。这在代码场景里其实更贴近真实需求：审查一个函数，我需要的是它的调用者、被调用者、数据来源，这是一张图上的可达性查询，不是向量空间里的最近邻。代价也明显——推理式检索慢、贵、结果不稳定。但对代码审查这种"宁可慢也不能漏"的场景，召回质量比延迟重要得多。我最近在试的折中方案是：先用轻量静态分析（AST + 调用图）把候选集缩到几十个片段，再让模型在这小集合里做推理排序。向量检索退居二线，只用于跨文件找"历史上类似的漏洞修复"。

另一个让我警惕的是今天 HN 上那篇 "You Said No MCP"。我自己也在纠结要不要接 MCP——接了能复用生态，但每个工具的描述都进上下文，审查一个大仓库时上下文预算被工具定义吃掉一大块。反对 MCP 的声音终于有了具体论据，而不是情绪。我倾向于先不接，把工具集收敛到三四个高频操作，等协议在权限边界和上下文开销上有更清晰的答案再说。

给同在做垂直 Agent 的人一条可执行建议：别默认向量库是必需品，先问你的任务需要的是"相似"还是"可达"。如果是后者，静态分析 + 小集合推理排序，往往比 embedding 更准也更便宜。至于预测——我赌未来半年会有一批"去向量化"的垂直检索工具冒出来，通用 RAG 栈会开始分层。