介绍

bge代码链接：https://github.com/FlagOpen/FlagEmbedding/blob/master/README_zh.md
为什么要微调嵌入模型：

在大模型落地企业服务的浪潮中，知识库问答（RAG）已成为最核心的应用场景之一 —— 无论是内部文档检索、客户服务智能应答，还是垂直领域知识查询，都离不开 “文本嵌入→向量检索→上下文生成” 的核心链路。而嵌入模型作为整个链路的 “地基”，其性能直接决定了检索精度与最终回答质量。BGE（BAAI General Embedding）作为中文场景下表现突出的开源嵌入模型，凭借优异的通用性和易用性，成为众多开发者的首选。但在实际接入 Dify 等低代码平台搭建私有知识库时，很多人会发现：通用预训练的 BGE 模型，在面对行业术语、企业内部话术、特定格式文档时，往往会出现 “理解偏差”—— 检索结果与用户需求错位、相关文档排序靠后、无关信息干扰核心答案，让精心搭建的知识库沦为 “看似能用，实则不好用” 的摆设。​通用嵌入模型的训练数据覆盖广泛的公开语料，擅长捕捉通用语义，但面对企业专属场景时，其局限性会被无限放大，这也是我们必须进行微调的核心原因。
基于前文对微调必要性的铺垫，接下来聚焦“构建问答对”这一核心第一步——这是让模型学习业务语义的核心数据基础，我会从数据来源、构建原则、实操方法、质量校验四个维度展开，确保内容兼具指导性和可操作性：

微调嵌入模型第一步：构建高质量问答对，筑牢数据基础

如果说微调是让BGE模型“读懂业务”的训练过程，那么问答对就是模型的“教材” ——高质量的问答对能精准传递业务语义关联、术语对应关系，而低质量数据只会让模型越调越偏。这一步的核心目标是：构建“用户真实查询（Query）- 业务核心答案（Answer）”的精准映射，让模型学习“业务场景下，什么样的问题该匹配什么样的信息”。

一、问答对的核心数据来源：从业务场景中“挖”真实数据

优质问答对的本质是“还原真实业务交互”，因此数据来源必须紧扣实际场景，推荐以下4类核心渠道（按优先级排序）：

1. 历史交互数据（优先级最高）
   提取Dify平台、企业原有客服系统、内部协作工具（如飞书/钉钉知识库）的历史数据：
   • 用户实际提问记录（如“如何开通XX功能？”“XX报错代码001怎么解决？”）；
   • 人工回复或系统推荐的有效答案（需筛选被用户标记“有用”或点击率高的内容）；
   • 价值：完全还原真实查询习惯、话术风格，模型训练后能直接适配实际使用场景。
2. 业务文档结构化拆解
   对企业核心文档（产品手册、操作指南、合同模板、行业规范）进行人工/半自动拆解：
   • 规则：每段核心信息对应1-2个问答对，避免信息过载；
   • 示例：从“产品XX功能支持3种部署方式，分别为本地部署（需满足CPU≥8核）、云服务器部署（推荐2核4G）、容器化部署（支持Docker）”中，可拆解出：
     • Query：“XX功能有哪些部署方式？”
     • Pos：“本地部署（CPU≥8核）、云服务器部署（2核4G推荐）、容器化部署（支持Docker）”；
     • Query：“XX功能本地部署需要什么配置？”
     • Pos：“XX功能本地部署需满足CPU≥8核”。
3. 模拟用户场景提问
   针对未覆盖的业务场景，组织产品、运营、技术人员模拟用户视角提问：
   • 覆盖维度：基础查询（如“XX功能是什么？”）、操作查询（如“怎么修改XX参数？”）、问题排查（如“XX功能无法启动的原因？”）、边缘场景（如“无网络时XX功能是否可用？”）；
   • 技巧：加入业务俚语、缩写（如将“项目A-Phase2”直接作为Query关键词），强化模型对专属表述的识别。
4. 行业公开数据集补充
   若业务数据较少，可引入行业公开问答数据集（需确保版权合规）：
   • 中文场景推荐：医疗领域（CHIP数据集）、金融领域（FiQA数据集）、通用技术领域（Stack Overflow中文数据集）；
   • 用法：筛选与业务相关的子集，替换为企业专属术语（如将通用医疗数据中的“CT报告”替换为企业内部“CT影像解读规范”）。

二、构建问答对的3个核心原则：避免“无效训练”

1. 精准匹配：1个Query对应1个核心Pos，不冗余
   避免“1个Query对应多段无关信息”或“1个Answer对应多个不相关Query”。例如：
   • 错误示例：Query“XX功能怎么用？”对应Answer包含功能介绍、部署步骤、常见问题（3类信息混杂）；
   • 正确示例：拆分为“XX功能基础操作步骤？”“XX功能部署流程？”“XX功能常见问题？”3个Query，分别对应单一核心Answer。
2. 贴合真实：Query模仿用户口语化表达，拒绝“书面化”
   通用模型的训练数据多为书面语，而实际用户查询常是短句式、口语化、模糊化的。例如：
   • 不推荐：Query“请简述XX产品的退款政策及操作流程”（过于书面）；
   • 推荐：Query“XX产品怎么退款？”“退款需要多久到账？”“退款条件是什么？”（贴合真实查询习惯）。
3. 覆盖全面：兼顾“高频场景”与“长尾场景”
   • 高频场景（占比70%）：覆盖80%用户会遇到的核心问题（如产品核心功能使用、常见报错排查）；
   • 长尾场景（占比30%）：包含边缘问题、专业术语查询、特殊场景需求（如“海外用户如何使用XX功能？”“术语XX是什么意思？”），避免模型“偏科”。

三、实操工具与方法：高效构建问答对（兼顾人工与自动化）

根据数据量大小，可选择不同的构建方式，平衡效率与质量：

1. 小数据量（1000条以内）：纯人工构建
   • 工具：Excel/飞书表格（列名：Query、Answer、场景标签）；
   • 流程：2人一组，1人拆解文档/模拟Query，1人审核Answer准确性，最后交叉校验（避免个人主观偏差）。
2. 中大数据量（1000-10000条）：“自动化+人工校验”
   • 自动化工具：使用大模型辅助生成（如调用GPT-3.5/通义千问，输入“基于以下文档，生成10个用户可能的提问及对应答案：[文档内容]”）；
   • 人工校验：重点审核3类问题：① Query是否贴合真实场景；② Answer是否准确无歧义；③ 术语使用是否符合企业规范；
   • 效率技巧：用Python脚本批量清洗重复数据（如去重相同Query）、筛选长度异常数据（Query＜5字或＞50字的需人工核查）。
3. 格式规范：统一输出为模型可识别的格式
   微调BGE模型时，参考BGEgithub教程：问答对格式为：

   {"query": str, "pos": List[str], "neg":List[str], "pos_scores": List[int], "neg_scores": List[int], "prompt": str, "type": str}

我们目前仅需要query以及pos。

{"query": "生活饮用水水质检测报告的出具机构有什么要求？", "pos": ["生活饮用水水质检测报告应当由具备资质的检验检测机构出具。"]}
{"query": "生活饮用水水质检测报告的有效期是多久？", "pos": ["生活饮用水水质检测报告出具的日期与申请备案日期之间不超过 1 个月。"]}

四、质量校验：3个关键指标，过滤低质量数据

问答对构建完成后，需通过以下指标筛选，确保“教材”质量：

1. 相关性：Query与Answer的语义匹配度≥90%
   • 校验方法：人工抽样（抽取20%数据），判断Answer是否能准确回答Query；或用通用BGE模型计算Query与Answer的相似度（阈值设为0.7，低于则剔除）。
2. 唯一性：无重复/近似Query
   • 校验方法：用Python的fuzzywuzzy库检测近似Query（如“XX功能怎么退款”与“XX功能退款流程”视为近似，保留1个更常用的表述）。
3. 完整性：核心场景覆盖率≥95%
   • 校验方法：梳理业务核心场景清单（如产品功能、操作流程、问题排查、术语解释），检查每个场景是否有对应的问答对，未覆盖的需补充。

小结

构建问答对的核心不是“数量多”，而是“质量高、场景真”——1000条精准匹配的问答对，远胜于10000条杂乱无章的数据。这一步完成后，我们就有了模型的“专属教材”，接下来才能进入模型微调的技术实现环节。

例子： 我们目前根据一篇文档构建出符合格式的问答对，并进行手动清洗：

提示词如下：

#role 
你是一名专业的问答对抽取助手
#skill
你具有丰富的换位思考能力；
你可以按照固定的格式，在理解文档的基础之上，每个知识点抽取出1-2条问答对。
#output format
{"query": str, "pos": List[str]}
#example
{"query": "生活饮用水水质检测报告的有效期是多久？", 
"pos": ["生活饮用水水质检测报告出具的日期与申请备案日期之间不超过 1 个月。"]}
#limit
你只能输出固定格式的问答对

最终得到一批由AI辅助生成的数据集，你需要对它进行清洗，清除掉一些不符合预期的数据，
最终形成问答对数据集：