检索工程 2026：为什么 AI 代理把它变成了核心工程学科

The New Stack 在 2026 年 8 月 30 日发表了一篇值得每个 AI 团队读三遍的文章：AI 代理正在把检索工程变成一门核心工程学科。文章引用 GigaOm 决策简报的观点：当组织从聊天机器人走向「代替用户调查、推理、行动」的 AI 系统时，检索成了应用质量的地基。传统搜索和大多数 RAG 应用都能容忍不完美的检索——用户没搜到想要的东西，会换个说法再试一次。代理没有这个奢侈：它自己规划、自己推理、自己调工具，没有一个人类在中间复查每一步。你的检索系统给它的证据是错的、过时的、或者缺一块，它就会基于错误证据做出错误的决定，而且不会有人拦它。

1. 代理把检索的门槛抬高了

文章的核心判断是：「随着组织从聊天机器人转向代表用户调查、推理和行动的 AI 系统，检索正在成为应用质量的基础。」代理会规划、推理、调用工具，并且在越来越多的情况下，在没有人类复核每一步的情况下做决定。这极大地抬高了门槛：检索不再只是「找到相关信息」，而是「在正确的时间稳定地交付正确的证据」。对工程师来说，这意味着一系列熟悉的新挑战：用户问的问题和演示里的很像，但措辞略有不同；账户记录不完整；工具返回错误；上周策略变了。这些都不是提示词问题——它们发生在模型开始行动之前的那一步。

// Hybrid retrieval: BM25 catches exact terms, vectors
// catch meaning. Agents cannot rephrase their own query,
// so recall at the edge is everything.
async function hybridSearch(query, topK = 20) {
  const [bm25, vec] = await Promise.all([
    bm25Search(query),            // exact terms, TF-IDF style
    vectorSearch(embed(query)),   // semantic neighbors
  ]);
  // Reciprocal Rank Fusion: stable across score scales
  const fused = new Map();
  [bm25, vec].forEach((list, i) => {
    list.forEach((doc, rank) => {
      const score = 1 / (60 + rank); // RRF constant
      fused.set(doc.id, (fused.get(doc.id) || 0) + score);
    });
  });
  return [...fused.entries()]
    .sort((a, b) => b[1] - a[1])
    .slice(0, topK)
    .map(([id]) => id);
}
// "Those aren't vector database problems. They're
// Retrieval Engineering problems." -- The New Stack

2. 这不是向量数据库问题

文章里最扎心的一句话是：「那些不是向量数据库问题，它们是检索工程问题。」团队常见的失败模式——召回率不够、命中的文档太旧、排序把关键证据压到第 20 位、同一概念在多个知识源里有多种说法——都不能靠换一个向量库解决。它不再只是嵌入和向量搜索：而是要工程化整个检索工作流，把混合检索、实时信号、排序、机器学习推理和持续实验组合起来，在服务时刻交付最好的决策依据。换句话说，向量数据库是你的存储层，检索工程才是决定系统聪明还是愚蠢的那一层。

// Reranking: retrieval returns 20 candidates, but the
// agent only needs the 3 best pieces of evidence. A
// cross-encoder scores query-doc pairs precisely.
async function rerank(query, candidates, topK = 3) {
  const pairs = candidates.map(doc => ({
    query, doc: doc.text, id: doc.id,
  }));
  const scores = await crossEncoderScore(pairs); // expensive, precise
  return scores
    .sort((a, b) => b.score - a.score)
    .slice(0, topK)
    .map(r => ({ id: r.id, score: r.score }));
}
// Retrieval = cheap and broad. Reranking = expensive and
// narrow. The agent never sees the 17 irrelevant docs.

3. 决策权：新的竞争层

GigaOm 决策简报提出了一个关键论断：「随着检索日益商品化，竞争优势转移到决策权上——决定一个应用或 AI 代理在行动之前应该看到什么、以什么顺序看到。」这正是检索工程的核心：不是把「所有相关内容」都塞给模型，而是精心选择「此刻最该给的那 4 份证据」，并且排好顺序。文章还给了我们一句可以裱起来的话：「提示词工程影响模型如何推理。检索工程决定模型要推理什么。」提示词再完美，如果模型拿到的证据是错的，推理也是错的。

// Decisioning: what the agent should see, and in what
// order, before it acts. GigaOm: as retrieval commoditizes,
// advantage shifts to decisioning.
{
  "decisioning": {
    "evidenceBudget": { "maxDocs": 4, "maxTokens": 8000 },
    "ordering": [
      { "when": "user asks about account state", "source": "account-service", "freshness": "realtime" },
      { "when": "task references internal APIs", "source": "docs", "freshness": "indexed" },
      { "when": "task is a code change", "source": "repo-context", "freshness": "git-head" }
    ],
    "gates": {
      "requireFresh": ["account-service", "inventory"],
      "neverInclude": ["draft-*", "internal-bugs"]
    }
  }
}
// The model reasons about what you HAND it. Retrieval
// Engineering decides what that is.

4. 混合检索实战：BM25 + 向量 + RRF

第一步是混合检索。BM25 擅长精确词匹配（「quote_id」「APPROVAL_REQUIRED」这类术语），向量搜索擅长语义近邻（「这个账户为什么被扣了两次款」）。代理不会自己改写查询，所以边缘召回率就是一切：漏掉一个关键文档，整个行动链就歪了。代码块一演示了标准做法：并行跑 BM25 和向量检索，然后用 Reciprocal Rank Fusion（RRF）把两路结果融合成一个稳定排序。RRF 的好处是不依赖两套分数体系可比——它只看排名，把排名倒数相加，天然稳定。

5. 重排：让代理只看到最好的证据

检索返回 20 个候选，但代理只需要 3 份最好的证据。cross-encoder 重排器把 query-doc 对逐对打分，比双编码器精确得多——代价是慢，所以它的位置在检索之后、进上下文之前：检索要便宜而宽泛，重排要昂贵而精准。代码块二演示了这个两步流水线：先用 hybridSearch 拿到 20 个候选，再用 rerank 挑出前 3，代理永远看不到那 17 个无关文档。在代理时代，「看不到无关内容」和「看到相关内容」同样重要——无关内容会污染推理，浪费宝贵的上下文窗口。

// Evaluation harness: agents fail when evidence is wrong,
// stale, or missing. Measure retrieval the way the agent
// experiences it -- end to end, not top-5 accuracy.
const EVALS = [
  {
    name: "account-lookup-uses-latest-billing",
    query: "Why was this account charged twice?",
    requiredEvidence: ["billing/2026-08", "account/status"],
    forbidStale: true, // any doc older than 30 days fails
  },
  {
    name: "code-change-references-existing-api",
    query: "Add a retry flag to the payments endpoint",
    requiredEvidence: ["payments/api-spec"],
    forbid: ["payments/legacy-v1"],
  },
];

async function runRetrievalEvals() {
  let pass = 0;
  for (const ev of EVALS) {
    const docs = await hybridSearch(ev.query);
    const ok = ev.requiredEvidence.every(id => docs.includes(id))
      && (ev.forbid ? !ev.forbid.some(id => docs.includes(id)) : true);
    if (ok) pass++;
    console.log(ev.name + ": " + (ok ? "PASS" : "FAIL"));
  }
  return pass + "/" + EVALS.length;
}
// Your benchmark score measures response quality. It will
// not tell you the agent pulled the wrong account record.

6. 评估与保鲜：代理视角的检索质量

最后两段代码解决「怎么证明它真的行」。评估框架（代码块四）模拟代理的真实体验：给定一个真实任务查询，检查返回的文档里是否包含必需证据、是否混入了禁止文档、是否出现过期的内容——而不是只看 top-5 准确率这种静态指标。保鲜缓存（代码块五）则处理「过时即错误」：账户类数据永远实时读取，文档缓存一小时，仓库上下文五分钟。文章引用的话收尾最有力：「检索不再只是找到相关信息——而是在正确的时间稳定地交付正确的证据。」2026 年，这就是一门和提示词工程、模型工程并列的核心学科。

// Freshness-aware cache: agents act on the world, so stale
// evidence is worse than no evidence. TTLs per source.
const SOURCE_TTL = {
  "account-service": 0,     // realtime, never cache
  "docs": 3600,             // 1 hour
  "repo-context": 300,      // 5 minutes (git moves fast)
  "public-reference": 86400 // 24 hours
};

async function getEvidence(source, key) {
  const ttl = SOURCE_TTL[source] ?? 3600;
  if (ttl === 0) return fetchLive(source, key);
  const cached = await cacheGet(source, key);
  if (cached && (Date.now() - cached.at) < ttl * 1000) return cached;
  const fresh = await fetchLive(source, key);
  await cacheSet(source, key, fresh);
  return fresh;
}
// "Retrieval is no longer about finding relevant info --
// it's about consistently delivering the right evidence
// at the right time." -- The New Stack