别在 AI 交付中迷信“长上下文”：为什么“精准切片 + 语义路由”才是生产环境的性能底线

在 AI Lab 的实际交付过程中，随着模型上下文窗口（Context Window）从 128K 扩展到 1M 甚至更多，很多团队产生了一个危险的错觉：“既然模型能吃下整本书，我为什么还要费劲地做复杂的 Chunking（切片）和 RAG 策略？”

这种“全量喂入”的思维在 Demo 阶段非常惊艳，但在真正的生产环境（Production）中，它往往是性能崩溃和成本失控的导火索。

“长上下文”的三个工程陷阱

在实际部署一个企业级知识库助手时，如果你简单地将所有相关文档全部塞进 Prompt，你会迅速撞上这三堵墙：

1. “迷失在中间” (Lost in the Middle)

尽管模型宣称支持百万 token，但注意力机制并非均匀分布。大量实验证明，模型对 Prompt 开头和结尾的信息捕捉最强，而中间部分的信息极易被忽略。当你把 50 个文档片段全部堆在一起时，关键答案如果落在第 25 个片段，模型大概率会告诉你“文档中未提及”。

2. 推理延迟的线性增长

TTFT (Time to First Token) 与输入长度呈正相关。在低延迟要求的对话场景中，用户无法忍受因为你塞了 100K 的背景资料而导致的 5-10 秒首字延迟。对于商业应用，响应速度就是转化率。

3. Token 成本的无谓浪费

在 API 调用模式下，每一万个 token 都是真金白银。如果一个问题只需要 500 字的精准片段就能回答，而你每次都发送 50K 的上下文，你的运营成本将增加 100 倍。

从“全量喂入”到“语义路由”：工程化路径

一个成熟的 AI 工程团队应该构建的是一套“漏斗式”的信息检索链路，而不是一个简单的“大桶”。

第一层：语义路由 (Semantic Routing)

不要直接进入向量检索。先通过一个轻量级的分类器（或 LLM-based Router）判断用户的意图。
- 意图 A (通用问答) $\rightarrow$ 直接调用基础模型。
- 意图 B (特定产品手册) $\rightarrow$ 定向路由至 product_manual 索引空间。
- 意图 C (实时数据查询) $\rightarrow$ 调用 Tool/API 而非检索文档。
通过路由，我们可以将检索范围瞬间缩小到最相关的子集。

第二层：精准切片与多粒度索引 (Multi-granular Indexing)

放弃单一的固定长度切片（如每段 500 字）。采用“父子索引” (Parent-Document Retrieval)：
- 子块 (Child Chunks)：极小粒度（如 100-200 字），用于高精度的向量匹配。
- 父块 (Parent Chunks)：较大粒度（如 1000 字），当子块命中后，将整个父块提供给 LLM 以保证上下文完整性。
这样既保证了检索的精度（Precision），又保证了生成的质量（Recall）。

第三层：重排序 (Reranking) 的强制介入

向量检索（Cosine Similarity）只能找到“看起来像”的内容，不能找到“真正有用”的内容。在 Top-K 片段返回后，必须引入一个 Cross-Encoder 重排序模型（如 BGE-Reranker）。
将 Top-50 的候选集通过 Reranker 精筛至 Top-5 $\rightarrow$ 这才是喂给 LLM 的最终上下文。

实战总结：AI Lab 的交付准则

在 AI 工程化中，“少即是多”是一个铁律。一个高性能的交付方案应该是：
1. 极简的 Prompt：只包含必要的指令和经过精筛的 Context。
2. 深层的检索链路：路由 $\rightarrow$ 子块匹配 $\rightarrow$ 父块还原 $\rightarrow$ 重排序 $\rightarrow$ 生成。
3. 严格的 Token Budget：为每个请求设定硬性的上下文上限，强制工程团队优化检索质量而非依赖模型窗口大小。

不要让你的系统变成一个依赖于“运气”和“超大窗口”的黑盒，要把确定性交给工程链路，把创造力交给模型生成。