LangChain 的 DocumentLoader / TextSplitter / Retriever 如何选型？

这三个组件是 LangChain RAG 流水线的前半段，串起来就是「加载 → 切分 → 嵌入入库 → 检索」。

DocumentLoader：按数据源选

职责是把各种来源的原始数据读成统一的 Document（page_content + metadata）。选型完全由数据源决定：PDF 用 PyPDF / Unstructured，网页用 WebBaseLoader，Markdown、CSV、数据库、Notion、S3 等都有对应 Loader。要点是保留好 metadata（来源、页码、标题），后续过滤和溯源都靠它。扫描件 PDF 还要叠加 OCR。

TextSplitter：按结构与长度选

文档太长无法整篇塞进上下文，也不利于检索精度，所以要切块。选型看内容结构：

• RecursiveCharacterTextSplitter：通用首选，按段落→句子→词逐级递归切，尽量不破坏语义边界。
• TokenTextSplitter：按 token 而非字符计数，能精确控制每块不超模型限制。
• SemanticChunker：用 Embedding 在语义转折处切分，块内主题更聚合，代价是更慢更贵。
• 专用切分器：代码、Markdown、HTML 有结构感知的切分器，按函数/标题切。

核心参数是 chunk_size 和 chunk_overlap，重叠用来避免把一句话从中间切断丢失上下文。

Retriever：按召回需求选

Retriever 决定「给定 query 取回哪些块」，是影响 RAG 质量的关键：

• VectorStore Retriever：纯向量相似度召回，最常用的基线。
• MultiQueryRetriever：让 LLM 把原始 query 改写成多个变体分别检索再合并，缓解「问法和文档措辞不一致」导致的漏召回。
• ParentDocumentRetriever：用小块做精准匹配、但返回其所属的大块（父文档），兼顾检索精度与上下文完整。
• SelfQueryRetriever：让 LLM 从自然语言里抽出元数据过滤条件（如时间、作者），做「语义 + 结构化过滤」混合检索。
• EnsembleRetriever：融合多个 Retriever（如向量 + BM25 关键词），用 RRF 重排，兼顾语义与精确匹配。
• ContextualCompressionRetriever：召回后再用 LLM 或重排模型压缩/过滤无关内容，减少喂给生成模型的噪声和 token。

选型逻辑：先用 VectorStore 跑基线，再针对具体短板叠加——召回不全加 MultiQuery 或 Ensemble，上下文破碎用 ParentDocument，需要元数据过滤用 SelfQuery，上下文太长太杂用 ContextualCompression。