← Resources
TUTORIAL · 2026-02-12
不用 LangChain 也能构建生产级 RAG 管线（2026）
通过直接组合各厂商 SDK、pgvector 与重排序模型，你可以在数百行代码内交付生产级 RAG 管线。在你真正遇到 LangChain 抽象能解决的具体需求之前，跳过它。
为什么团队在 2026 年开始拆解 LangChain
到 2026 年，把 LangChain 从生产中移除已成可识别的工程模式，曾经布道它的团队也公开了复盘。抱怨集合高度一致：层层抽象遮蔽了真正发送给模型的内容；小版本之间频繁不兼容；调试过程像在包装类里探洞。
更深层的变化是厂商 SDK 变好了。OpenAI、Anthropic 与 Google 的 SDK 现都一线支持流式、结构化输出、工具调用与批处理。Voyage、Cohere 与 Jina 暴露干净的 REST 端点用于向量化与重排序。带 pgvector 的 Postgres 可在无需专门向量数据库的情况下处理约 1000 万向量的 ANN 搜索。
对绝大多数 RAG 工作负载，2023 年你想要的框架，如今变成了四个函数调用加一条 SQL 查询。2026 年合理的默认选择是从原生 SDK 起步，等到真正吃痛时再加薄薄的管线抽象，把重型框架视为可选项。
每条 RAG 管线必备的五个阶段
无论用什么框架，每个生产级 RAG 系统都可拆为相同的五个阶段。显式命名能让代码更易于测试与逐段替换。
- 摄取：加载源文档、规范化编码、剥离样板。
- 分块：按稳定 ID 和源信息切分为检索单元。
- 向量化与建索：将分块编码进向量库，并配合用于混合检索的词法索引。
- 检索与重排：拉取一个较宽的候选集，再用 cross-encoder 重排器收敛。
- 生成与引用：拼装含检索上下文的提示，并返回带来源标注的答案。
把每个阶段写成入参与出参均有类型的纯函数。检索阶段不应知道是哪个 LLM 在生成；生成阶段不应知道用了哪个向量化模型。这正是框架承诺却很少兑现的事——因为它们通过不透明的 Chain 对象耦合各阶段。自己写需要一个下午，却能消除一类升级风险。
分块策略：语义、递归与 Agentic
分块决定了 RAG 质量的胜负。2026 年主流的有三种模式。
按分隔层级（段落、句子、字符）做递归字符切分是基线。它快、确定且对散文已足够。语义分块对候选切分点做向量化并合并向量相近的相邻块，以更高摄取成本生成主题连贯的单元。Agentic 分块则让小型 LLM 对合同或转录文本等结构化文档建议切分点，因为标题和回合边界比字符数更重要。
def recursive_chunk(text, max_chars=1200, overlap=150):
seps = ["\n\n", "\n", ". ", " "]
def split(s, depth=0):
if len(s) <= max_chars or depth == len(seps):
return [s]
parts, sep = [], seps[depth]
for p in s.split(sep):
parts.extend(split(p, depth + 1))
return parts
raw = split(text)
return [raw[i] + raw[i+1][:overlap] for i in range(len(raw)-1)] + [raw[-1]]
先用递归，量化评估，再仅在评估证明其值得的文档类别上升级到语义。
向量化与重排序：Voyage、BGE 与 Cohere
2026 年检索器的图景比一年前更清晰。Voyage AI（现已并入 MongoDB）以 voyage-3-large 提供强大的通用稠密模型，并在 2026 年初推出 voyage-4 系列，含瞄准 RTEB 榜首的 MoE 变体。Cohere 的 embed-v4 是另一位生产领跑者。对开源权重自托管，BAAI 的 bge-m3 仍是默认：单模型同时支持稠密、稀疏与多向量检索，覆盖 100 多种语言，上下文 8192 token。
重排序方面，Cohere rerank-v3.5 是主力：单一多语模型、4096 token 分块、典型负载下 P50 延迟约 80-150 毫秒。Voyage rerank-2 表现相当，若已用 Voyage 向量化则整合更顺滑。
实用法则：选定一个稠密向量化模型加一个重排器，把这一对冻在接口背后。日后更换只需重建索引，而非重写代码。
把检索、生成与引用串起来
用 pgvector 可在直接 SQL 中实现混合检索与引用。把分块、文档 ID、向量和用于词法召回的 tsvector 一同存储。先取一个较宽的候选集，重排后将 Top N 连同显式来源 ID 传入 LLM，并要求模型按 ID 引用。
import psycopg, voyageai, cohere
vo, co = voyageai.Client(), cohere.Client()
def retrieve(query, k=40, top_n=8):
qvec = vo.embed([query], model="voyage-3-large").embeddings[0]
with psycopg.connect(DSN) as conn:
rows = conn.execute(
"SELECT id, doc_id, text FROM chunks ORDER BY embedding <=> %s LIMIT %s",
(qvec, k)).fetchall()
docs = [r[2] for r in rows]
ranked = co.rerank(model="rerank-v3.5", query=query, documents=docs, top_n=top_n)
return [rows[r.index] for r in ranked.results]
```
对 pgvector，默认采用 HNSW 索引（m=16、ef_construction=64），并加上租户或时间预过滤以让 ANN 扫描从一个更窄的范围开始；总是把 `ORDER BY embedding <=> $1` 与 `LIMIT` 配对使用。把检索到的分块及其 ID 传给 LLM，并指示模型输出引用标记；之后在后处理阶段把这些标记解析回源 URL。
评估：命中率、MRR 与忠实度
没有评估套件的 RAG 管线就是猜测。先建评估套件，再调任何参数。最简配套是一套 100-500 例的标注查询集合，覆盖你实际期望的问题类型，加上三个指标。
Hit Rate @K 回答正确分块是否进入了候选集，从而隔离检索质量。Mean Reciprocal Rank 体现正确分块排在多靠前，这是重排器要改进的对象。忠实度（faithfulness）由 LLM 评判员对照引用分块逐条比对生成中的主张，捕捉模型是否越过上下文产生了幻觉。
每次变更都跑评估：新的分块大小、不同向量化模型、提示词修改。把三项指标随时间画在同一仪表盘。如果某次变更提升了 MRR 却拉低了忠实度，说明重排器把干扰项浮上来了——需要为生成提示加护栏，而不是继续调检索。
何时升级到托管编排器
手搓管线只要一个团队拥有且阶段不多，就能保持可维护。托管编排器的价值显现于：需要非工程师调检索；需要为不同文档类别并行运行多条管线；需要带版本的配置与不重新部署的 A/B 路由。
这时选择题就成了：选 LlamaIndex 或 Haystack 这类重型框架，还是把检索阶段作为声明式单元暴露的配置驱动平台。osFoundry 中的无代码编排编辑器 osStudio 走第二条路：上文五个阶段是一等配置对象，托管 Voyage 向量化与重排序藏在统一代理后——LLM 侧保留 BYOK，检索侧避免框架锁定。
真正有用的问题不是有没有框架，而是你的管线配置该是代码、配置还是 UI——这个答案会随团队规模变化。
Frequently asked questions
- 我真的需要为 RAG 上向量数据库吗？
- 在跨越数百万向量之前，大概率不需要。带 pgvector 的 Postgres 配合 HNSW 索引可舒适承载约 1000 万向量，通过 tsvector 实现混合检索，并用标准 SQL 过滤租户与时效。你直接继承所运行数据库的备份、复制与访问控制。Qdrant、Milvus 或 Weaviate 等专门向量数据库的运维成本，要在你需要十亿规模分片索引、超高 QPS 的特殊过滤，或 pgvector 尚未匹配的多向量检索能力时才划算。先用 pgvector，仅在量化瓶颈出现时再迁移。
- 重排器真的值这点延迟吗？
- 对大多数检索密集型工作负载，是的。Cohere rerank-v3.5 或 Voyage rerank-2 等 cross-encoder 重排器，在 40-100 个候选分块上 P50 通常增加 80-200 毫秒，并稳定地比仅做稠密检索提升 10%-30% 的 MRR。该延迟被后续 LLM 调用所掩盖——后者通常主导用户可感预算。仅在端到端 200 毫秒以内的自动补全类延迟敏感流程中跳过重排，或在候选集已足够小、稠密排序已可靠时跳过。
- 如何在不膨胀存储的前提下处理分块重叠？
- 使用块大小 10%-15% 的小重叠，按字符偏移存入源文档而非复制文本。检索时可按需取相邻块做上下文扩展。这样能保持索引精简，避免在向量化时为相同 token 付两次费。如果生成阶段需要更丰富的上下文，父文档模式很合适：以小分块入索以保证检索精度，命中后再解析回所在父级章节再传给 LLM。父级查找只是一次有索引的查询，延迟可忽略。
- 评估 RAG 质量最简单的办法是什么？
- 构造一套 100-200 条代表性查询，标注应被检索的分块 ID。仅从检索阶段计算 Hit Rate @K 与 MRR，把检索质量与生成噪声隔离开。对忠实度，使用 LLM 评判员对照引用分块逐条比对生成中的主张，按落地与不支持打分。每次有意义的变更都跑这三个数字，并把回退视为阻断项。这套三指标设置可在实践中捕获绝大多数 RAG 回归，避免优化一个数字却悄悄拉低另一个的陷阱。
Sources