RAG 从哪里开始：Retrieval 边界、架构模式与 Ingestion

前置：ContextManager；知道 Retrieval Result 最终如何进入 Model Context
核心问题：当答案错了时，怎样区分是文档没被正确摄取、没有召回，还是证据已经进 Context 但模型没用对？

检索器没有召回正确政策属于 retrieval failure；正确政策已进入 context 但模型仍给错答案属于 generation/grounding failure。FAQ 适合固定 retrieve→answer；调查型任务可以让 Agent 多轮检索并改写 query，但要限制轮数和成本。

Mental Model

Source → ingestion/chunk/index → Query → retrieve/filter → rerank → evidence set → Context → generation

在线链路要能拆成 query → filter → candidate recall → rerank → evidence → context；离线 ingestion/index 另有版本和质量指标。

Retrieval 与 RAG 的边界

Retrieval 只负责从外部数据源找到候选证据；RAG 则把 retrieve → evidence → generation 串成完整回答链。数据源可以是向量索引，也可以是 SQL、搜索 API 或其他 Retriever。诊断时必须把“没找对证据”和“找对了但模型没用对”分成两类指标。

2-Step RAG / Agentic RAG / Hybrid RAG

2-Step RAG 把检索固定在生成之前，路径短、容易测试；Agentic RAG 让模型根据中间 Observation 决定是否再次检索或改写 query；Hybrid 则保留固定的最低证据流程，再允许局部动态搜索。选择标准是任务是否每次都需要检索、query 能否预先确定，以及能接受多少额外 latency/控制复杂度。

Document Ingestion

Ingestion 是把原始来源发布成可重建、可追踪、可授权检索的语料版本。流水线通常包含加载/解析、清洗与去重、结构化 chunk、metadata/ACL、embedding/index 和版本发布；任何解析失败或增量更新都要可观测。这里最重要的不是“把文件传进去”，而是保住 source/version、标题层级、权限和时间等 provenance，否则后面的 Retriever 无法补救。

最小实现 / 数据结构

class Retriever(Protocol):
    async def retrieve(self, query: RetrievalQuery) -> list[Evidence]: ...

@dataclass
class Evidence:
    text: str
    source_id: str
    score: float
    metadata: dict

在 Shadow Harness 中怎么落地

定义 Document、Chunk、Retriever、RetrievalQuery、RetrievalResult、Reranker；ContextManager 消费标准化结果，不直接依赖具体 vector DB。

自测

1. 正确文档根本没进索引，与文档已召回但模型没引用，是两种完全不同的失败。你会分别在哪一段链路定位？
2. 一个最小 RAG 链路里，ingestion、retriever、context injection 的责任边界分别是什么？

Sources

• OpenAI API — Vector stores
• LangChain — Retrieval
• LangGraph — Agentic RAG
• LangChain — Cross encoder reranker