Ai on TouchingFish.top

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 的块可能包含五个段落，用户的问题只匹配其中一段，其余四段都是噪声。

当你连 scale 也量化了

Fri, 30 May 2025 00:00:00 +0000

上次算到，160 亿参数的模型用 Q4_0 量化后，光 scale 和 $\alpha$ 这些"说明书"就要吃掉 2 GB。

2 GB 不小。一台 16 GB 显存的显卡，模型权重压缩后大概 8 GB，结果说明书自己占了四分之一。这就像你去宜家买了一张桌子，包装盒里一半是螺丝和安装图纸。

K-quants 要解决的就是这个问题。思路很直白——既然权重可以量化，那说明书也可以量化。

套娃

K-quants 的核心结构叫 super-block。做法是把 8 个普通 block 打包成一组，然后对 8 个 scale 再做一次量化——从 FP16（16 bit）砍到 INT8（8 bit）：

super-block: 256 个 INT4 权重
├── block 0: scale = 0.10 (FP16 → INT8)
├── block 1: scale = 0.14 (FP16 → INT8)
├── block 2: scale = 0.11 (FP16 → INT8)
├── block 3: scale = 0.18 (FP16 → INT8)
├── block 4: scale = 0.08 (FP16 → INT8)
├── block 5: scale = 0.16 (FP16 → INT8)
├── block 6: scale = 0.13 (FP16 → INT8)
├── block 7: scale = 0.09 (FP16 → INT8)
└── super-scale = 0.00142 (FP16) ← 新加的，用来还原上面那些 INT8

来走一遍完整的计算。假设这 8 个 block 里 256 个权重已经量化完了——每个 block 的 scale 是上面那 8 个 FP16 值。现在的任务是把这 8 个 scale 自己也量化掉。

当你把模型从16位砍到4位

Mon, 19 May 2025 00:00:00 +0000

第一次在本地跑 Llama 的时候，下载页面那一排 Q4_0、Q4_K_M、Q5_1 让我愣了半天。

选了最大的文件，跑不起来。显存不够。选了最小的文件，跑起来了，但回答像喝了假酒。后来才知道，这一排名字背后是一整套妥协方案——在模型的"胖瘦"和"聪明程度"之间找平衡。

这篇文章讲最早的那套方案：legacy quants。GGUF 现在已经有 K-quants 和 I-quants 了，但 legacy 是地基。搞懂了它，后面那些花里胡哨的变体无非是在这个地基上换砖头。

FP16 和 INT4

在聊量化之前，先搞懂两样东西：模型权重长什么样，以及我们想把它变成什么样。

FP16 是半精度浮点数。16 个 bit（2 个字节），存一个带小数点的数。C 语言里没有 FP16，但你想象一个比 float（32 位）更省空间的浮点数就行。大模型的权重——那些矩阵里的每一个数字——出厂的时候就是 FP16。一个 70 亿参数的模型，70 亿个 FP16，也就是 14 GB。不大不小，刚好塞不进一张 12 GB 的消费级显卡。

INT4 是 4 位整数。4 个 bit，能表示 $2^4 = 16$ 个不同的值。如果你只写过 C，你熟悉的整数是 int（32 位）、short（16 位）、char（8 位）。4 位的整数在 C 里没有——太小了，小到没法单独寻址，必须打包存储。

打个比方：FP16 像女生的口红色号——豆沙、枫叶、烂番茄，每一格都有名字。INT4 是男人的衣柜——黑、白、灰、深蓝，能数的就那几种。

量化的核心问题就是：怎么用男人的衣柜里那几种颜色，还原出口红色号的全部渐变？

这是有损压缩。丢掉的信息永远捡不回来。

假装天平是平的

GGUF 的量化不是把每个 FP16 单独转成 INT4。那样做的话，每个权重需要一个 scale（缩放系数）来告诉你怎么"还原"，而 scale 本身就是 FP16——16 位。用 16 位存 scale 去压缩一个 16 位的权重？没有意义。