一、项目背景

我们给一家制造企业做 RAG 知识库时，第一版直接用了通用开源 embedding 模型。跑起来后答非所问的问题集中在一个方向：企业内部的行话、设备代号、工艺参数同义词，通用模型基本"听不懂"。比如"主轴温升报警"和"SPINDLE TEMP ALARM"应该召回同一篇文档，通用模型给出的相似度很低；长工艺文档切出来的片段，召回也明显偏弱。客服和工程师的转人工率没降下来，反而因为"答错"更烦。

我们当时判断，核心矛盾是"检索底座用的通用语义空间，落不到垂直领域的词汇与表达"。这个项目里，我们采用私有化 AI 底座承载 embedding 与向量库（Milvus/pgvector 类），并把重心从"换更大模型"转到"先把检索语义对齐领域"。底座确定后，真正的难点是怎么科学地选 embedding、怎么用领域语料做自适应而不把通用能力训坏。

二、落地场景

第一类场景是 embedding 选型评测。我们没盲信榜单，而是用企业自己的查询—文档对构建了小型评测集，在候选模型上跑召回率@k，用真实业务语言说话，而非公开 benchmark。

第二类场景是领域语料继续训练。把企业内部的手册、工单、工艺文档作为继续训练语料，让 embedding 在保留通用语义的同时，把领域同义词拉近。训练以"对比学习"为主，正样本来自同文档片段与人工同义对，负样本来自易混淆的不同类目。

第三类场景是维度与索引协同。领域微调后我们重新评估了向量维度与索引类型（HNSW/IVF），在保证召回的前提下压低存储与检索时延，因为维度翻倍意味着存储和查询成本同步翻倍。

第四类场景是召回评估闭环。每次模型或索引变更，都回到那套评测集跑回归，防止"为某类查询优化却拖垮另一类"。

落地过程中我们还补了一块常被忽略的能力：查询改写前置。很多"召回差"其实是用户问法太口语，我们在检索前用轻量模型做查询规范化，把领域同义词先对齐， embedding 的压力小了很多。

三、关键技术挑战与解决思路

第一个挑战是 embedding 选型与评测。公开榜单与实际业务差距大，我们坚持用自有评测集。下面是评测配置与维度权衡的脱敏片段。

# embedding 评测与微调配置（已脱敏）
eval:
  dataset: corp_eval_qd_pairs.jsonl   # 企业自有查询-文档对
  metrics: [recall@5, recall@10, mrr]
  candidates:
    - {name: "general-base", dim: 768}
    - {name: "domain-ft",   dim: 768}  # 领域继续训练版
index:
  type: HNSW
  m: 16
  ef_search: 64

第二个挑战是领域语料继续训练。关键不是"堆数据"，而是"控正负样本"。我们构造了同文档相邻片段为正、跨类目易混淆片段为负的对比对，训练时冻结底层、只微调上层投影，避免通用语义崩塌。

第三个挑战是维度与索引协同。微调后我们实测了不同维度下的召回与成本，最终维持 768 维而非盲目升到 1024，因为在自有评测集上 768 维 recall@10 已达可接受区间，存储成本却低约三成。

四、效果数据

改造前后，我们拉通了四组口径一致的脱敏示意指标：

上表为脱敏示意值，用于说明趋势而非审计口径；评测集规模有限，结果为多次取均值。

五、可复用经验总结

第一，先评测再微调。我们早期差点直接上最大的通用模型，幸好先用自有评测集跑了对比，发现瓶颈在领域语义而非模型规模。用业务自己的查询—文档对做标尺，比任何公开榜单都准。

第二，领域适配优于盲目加层。继续训练时冻结底层、微调上层投影，既把行话拉近，又不把通用语义训崩。维度也不是越高越好——在自有评测集上够用就行，存储和时延都要买单。

第三，正负样本决定微调质量。领域微调最怕"数据堆一堆就训"，结果把噪声也学进去。同文档相邻为正、跨类目易混淆为负，这个对比构造法让召回提升明显且稳定。

第四，召回评估要闭环。每次 embedding 或索引变更都回评测集回归，防止"修一类、坏一类"。能持续看见召回变化，比一次性调好更重要。

案例片段（已脱敏）：一条查询"主轴温升报警怎么处理"，通用 embedding 在向量库里把最相关工艺文档排到第 9 位，超出 top5 阈值未被召回。领域微调后，因"主轴温升报警"与"SPINDLE TEMP ALARM"在训练正样本中被对齐，该文档升至第 1 位，同类中英混写查询的 recall@10 由约 58% 提升到约 82%。

案例片段（已脱敏）：一次索引维度从 768 升到 1024 的尝试，存储成本涨约 33%，但在自有评测集上 recall@10 仅提升不到 1 个百分点。我们据此回退到 768 维并优化 HNSW 参数（ef_search 64），召回维持、时延与成本双降，避免了"为边际收益买单"的坑。

结语

Embedding 看似是 RAG 链路里最不起眼的一环，却往往决定检索质量的上限。我们的体会是：不要在通用模型上盲目堆规模，先把领域语义对齐、把评测闭环建起来，收益比换大模型实在得多。embedding 的运维（选型、微调、索引、回归）应该像模型服务一样被持续关注，而不是"训一次用一年"。当检索质量开始随业务语料漂移时，最早的信号往往就藏在自有评测集的 recall 曲线里。