JD 里的 RAG，其实是 LangChain 调参

Tue, 17 Jun 2025 00:00:00 +0000

招聘网站上搜"RAG"，跳出来的 JD 长得都差不多。

熟悉 Retrieval-Augmented Generation。了解向量数据库（FAISS、Pinecone、Chroma）。掌握 Embedding 模型（OpenAI、BGE、M3E）。有 LLM 应用开发经验，熟悉 LangChain / LlamaIndex。

我一开始也以为这是在招算法工程师——那种能从头训练 Embedding 模型、能设计新的向量索引结构、能在论文里挂名的人。

面了几轮才发现，大部分公司要的不是这个。他们想要的是：给你一个文档库，你能用 LangChain 搭一个问答系统，调调参数，让回答别那么离谱。至于向量数据库选 FAISS 还是 Chroma，Embedding 模型选 OpenAI 还是开源的，很多时候只是配置项的问题。

JD 里写的 RAG、向量数据库、Embedding，翻译成人话就是：你会不会用 LangChain 调参。

向量数据库不需要 SQL boys 和 SQL girls，但又不能说不是一回事。它说的就是数据库，只是存的东西不是行和列，而是坐标。没有 JOIN，没有 WHERE。只有"给我找离这个点最近的几个邻居"。

这篇文章从调参的视角，把 RAG pipeline 里每个环节的参数过一遍。不重复基础概念，只讲实际写代码时会遇到的选择。

切

chunk_size 设多少？

RAG 的第一步是把文档切成块。LangChain 里最常用的工具是 RecursiveCharacterTextSplitter。

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=1000,
 chunk_overlap=200,
 separators=["\n\n", "\n", "。", "，", " ", ""]
)

chunk_size

这个参数的单位是 token 数，不是字符数。设得太小，一个完整的句子被拦腰截断，语义支离破碎。设得太大，单个块包含太多主题，检索时容易引入无关信息。

通用文档（论文、报告）：500-1000 tokens
代码：200-400 tokens，按函数或类切分更合理
对话记录：300-500 tokens，保留完整回合

一个容易踩的坑是盲目追求大 chunk。“大一点，信息多一点，模型回答更完整”——听起来对，但检索精度会下降。一个 2000 token 的块可能包含五个段落，用户的问题只匹配其中一段，其余四段都是噪声。

Embeddings on TouchingFish.top

JD 里的 RAG，其实是 LangChain 调参

切