大模型在问答领域的探索和实践

随着大模型应用的持续升温，入门的门槛确实在一点点降低。去年年底开始，团队用少量精力投入了一些AI探索和落地实践，最终完成了一个面向垂直领域的答疑机器人。这篇文章更多是从普通使用者的视角出发，把一边学一边做的过程梳理出来，算是经验记录，也希望能给大家带来一些参考。

这篇文章定位**无门槛**，面向的主要是入门玩家，或者那些对大模型感兴趣、想在业务中尝试提效的工程人员。 ## 背景 说实话，目前大模型的应用整体还处在早期探索阶段。拿物流领域来说，很多场景对准确性和可控性的要求，跟当前大模型的能力边界有比较明显的冲突。在生产环境真正落地之前，我们更倾向于先在容错性比较高的场景里跑一跑。于是，我们用大模型来优化答疑机器人，希望能为后续更深入的实践积累一些经验。（下图由大模型生成，仅作示意）

### 传统答疑机器人的痛点 在大模型出现之前，传统答疑机器人基本就两条路： 1. 靠多级目录，让用户自己一层一层翻找知识。 2. 靠关键词检索，根据用户输入去知识库里匹配相关内容。 核心问题其实很简单：**不能快速、准确地找到用户真正想要的答案。** ### 我们的目标 我们的答疑机器人面向的是内部作业人员，而不是C端用户。所以，语言风格上不需要太花哨，但我们希望它具备这样几个特质： 1. 能**准确理解**用户用自然语言提出的问题，并给出标准答案。 2. 回答要**快**，最好在5秒以内。 3. **不能答非所问**——如果问题不在业务范围之内，需要明确拒绝并引导到人工客服。 ## 迭代过程 结合业内的方案和我们自己的诉求，整个过程大致经历了五个阶段的迭代，下面展开聊聊。 ### 阶段一：向量搜索 先补充几个基础概念： - **嵌入（Embedding）**：一种把文本、图像等数据转成向量的方法，它特别擅长保留数据间的语义关系。比如，“苹果”和“橘子”在向量空间中的距离，要比“苹果”和“太阳”近得多。 - **Embedding 模型服务**：提供向量化能力的在线服务，可以直接调用 OpenAI、阿里云等，也可以本地部署。想低成本试用，阿里云灵积是一个不错的选择。 - **向量数据库**：用来存储和检索高维向量的数据库，尤其擅长做相似性搜索。低成本试用可以考虑阿里云的 Hologres。 向量搜索，其实可以类比传统的关系型数据库检索，只不过它是按**语义**来做相似度匹配。文本被转成向量后存入数据库，不同Embedding模型的维度不同，通常可以达到上千维。 #### 向量搜索流程 下图是一个简化版的流程，分数据准备和在线推理两部分： 1. **数据准备**：把历史积累的知识库数据清洗成QA问答对，把问题、答案以及问题的向量一并存入向量数据库。 2. **在线推理**：先将用户的问题通过向量服务转为向量，然后在向量数据库中找出最相似的一条数据。接着通过相似度阈值来判断用户提问和标准问题是否足够相似，最终决定是否把答案返回给用户。 #### 效果分析 假设有一个标准问答对： Q：遇到不可抗力因素无法配送，如何操作？ A：1. 系统进行提报，详细步骤XXX | 提问类型 | 现场提问 | 结果分析 | | --- | --- | --- | | 长度和语义相似的泛化提问 | 不可抗力因素无法配送，**该怎么办？** | 问题接近时，取向量距离最小的答案，正确率较高 | | 问题较长且**看起来差不多但语义不同**的提问 | 不可抗力因素**比较难以**配送，怎么办？下雪封路了，不能作业该怎么办？ | 问题较长或语义近似但实际不同时，纯向量难以很好区分，错误率较高 | | 不相关问题的提问 | 今天天气怎么样？ | 拒绝回答的向量距离阈值不好把控 | 尝试下来，纯向量搜索的优势在于：原始问题或细微修改的问题，能比较**快速、准确**地找到答案。 **但不足也很明显：** 1. 问题较长且多个问题语义相近时，准确率会下降。 2. 向量距离的阈值很难调，对于**无关问题的拒绝回答**机制不好处理。 ### 阶段二：RAG RAG是知识问答领域落地最广泛的实践，同时也是一种非常好上手的大模型应用方式。 > **RAG（检索增强生成）**：大模型本身不掌握垂直领域的知识。RAG的核心思路就是先“查资料”，再“写答案”——先用检索系统找到跟问题相关的资料，再用大模型（类似GPT）来生成详细的答案，从而提高回答的准确性。 **RAG 就像让一个知识储备丰富的大学生（大模型）拿着初中历史课本参加开卷考试。他虽然本来不会，但靠着查资料，准确率还不错。就算课本上没有，他也能凭自己的本事把试卷填满（这就是所谓的“幻觉”）。** #### RAG流程 下面是一个简化版的RAG知识问答流程图。可以看到，整体和第一阶段的向量搜索类似： 1. **数据准备阶段**：原始数据可能是大量文档，需要尽量清洗成统一格式，并按照一定规则分段。分段规则和大小需要多次试错，才能找到最适合当前场景的参数。分段后的知识向量化后存入向量数据库。 2. **在线推理阶段**：先把用户的问题从数据库中检索出N条最相似的分段，作为大模型总结的“参考资料”。大模型拿着这些资料，按要求总结出答案。 #### RAG上手 目前有很多现成的产品可以快速体验RAG，推荐阿里云百炼的应用中心。平台有详细的教程，准备好基础文档后，五分钟就能搭出一个智能体应用。下面用一个简单示例演示核心步骤（截图来自阿里云百炼平台）： 1. **创建RAG智能体应用**：主要关注模型选择、prompt（希望大模型怎么总结）、知识库、召回策略等。 2. **上传知识库**：重点关注向量模型的选择和分段规则。 3. **检索配置**：设置召回类型和规则。 4. **测试问答效果**。 #### 效果分析 **优势：** 1. 【正确率高】正确率基本可以达到90%以上。 2. 【话术灵活】回复话术可以根据prompt灵活控制，包括语气、格式等。 3. 【兜底机制】可以控制知识库里没有的内容拒绝回答，只返回固定文案。 **不足：** 1. 耗时较长，一次完整回复经常超过10秒。 2. 按调用量收费，QPS较高时费用也会比较可观。 3. 因为允许大模型发挥，所以会存在“幻觉”偶发答非所问。 ### 阶段三：SFT 上面两种方案各有优劣，于是我们开始尝试垂直领域的模型微调，看能不能训练出一个“无所不知”的领域小模型。先贴一些概念： > - **PT（预训练）**：用大量机器和未标记数据训练，如GPT-4、Qwen2-7B等。 > - **SFT（监督式微调）**：用少量标注好的领域数据训练基座大模型，获得可处理专属领域任务的模型。 > - **FFT（全参数微调）**：模型全部参数结构和权重都会变，需要资源多，训练彻底，但容易过拟合和灾难遗忘。 > - **LoRA微调（部分参数微调）**：通过矩阵运算原理，只微调一小部分参数，达到和全参数微调相近的效果。 > - **Instruction-Tuning（指令微调）**：旨在提高模型处理多种自然语言指令的多任务能力，训练数据有特定格式要求。 **SFT的过程，就像教一个五岁的小孩背20首古诗。背了三天发现还是不会（欠拟合）；背了三个月，倒背如流（到位了）；背了三年，还是只会这几首（过拟合），不仅不会自己写诗（没理解本质），而且连1+1等于几都忘了（灾难性遗忘）。** #### SFT流程 一个简化的SFT流程图一般包含三块： 1. **构建数据**：高质量数据极为关键，数据量的大小和质量会极大影响最终效果。 2. **模型微调和评测**：这是最核心的部分。除了选择合适的基座模型，重点是根据评测效果反复调整训练所需的超参数，直到模型表现符合预期。 3. **模型部署**：根据评测结果，选择表现最佳的模型快照部署上线。 #### SFT上手实践 目前也有很多微调平台，这里继续用阿里云百炼演示核心步骤（截图来自平台）： 1. **数据准备**：以知识问答机器人为例，需要整理日常积累的原始问答数据，经过人工打标，转换成指令微调数据集的格式并上传。 2. **创建微调任务**：重点关注基座模型的选择。评测下来，小模型中最新的qwen2-7B表现不错。 3. **调整训练配置**：几个比较核心的配置： - **循环次数**：模型看几遍训练数据。测试下来，次数越多，模型泛化能力越差，但也更稳定。 - **学习率**：模型开始更新参数时的幅度，决定了是否能学习到数据特征。 - **批次大小**：根据训练轮数选择合适的步数，保证一次完整训练能保存若干个快照。 4. 等待训练完成，观察日志，确认是否有loss跳跃过大、未收敛等异常。 5. **模型评测**：选择训练好的模型进行推理评测，可以人工评测，也可以借助更强大的大模型来完成。 6. 对推理结果打分，可以根据需求选择评分方式，比如写脚本与标准答案做完全匹配，或用评测大模型打分。 7. 测评通过后，将模型部署上线，进行测试、运维和服务。 #### 一些尝试下来的有效手段 **数据构造：** 1. 通过人工 + 通义千问72B等大模型对问题做同义改写，扩充训练数据量，让模型更好学习特征。我们做了十倍扩充。 - **大模型改写**： “遇到不可抗力因素无法配送，如何操作？” -> “遇到不可抗力因素无法配送，该怎么办？” - **人工改写**： “遇到不可抗力因素无法配送，如何操作？” -> “遇到大雪等特殊情况，不能作业了！” 2. 打乱训练数据中相似数据的顺序，防止模型学到错误的顺序特征。 3. 是否需要加入大量无关数据集？这部分取决于训练的目标。如果希望模型回答稳定、只处理训练数据相关的知识，那不需要混合数据训练。 **微调：** 1. 通过观察loss收敛曲线和评测效果，调整初始学习率和训练轮数。在我们场景下，一般会把最终loss收敛控制在0.1以下。 2. 尝试在loss曲线不再收敛时选择对应的快照作为最终模型，避免过拟合。 **评测——构建丰富的评测数据集：** 1. 【检验欠拟合】先使用训练集数据推理评测，再用改写后的同语义测试集推理评测，保证两者都有较高分数。 2. 【检验过拟合】对与训练数据语义无关的问题进行评测，看答案是否来自训练数据集。 #### 效果分析 **实践下来的一些不一定对的认知：** 1. 【过拟合】经过SFT，大模型的通用能力遗忘和过拟合行为是常事，不必完全避免，关键看是否匹配自己的目标。 2. 【prompt】对于微调后的小模型，常见的提示词工程技术作用不大，保证提问时和训练时的prompt保持一致即可。 3. 【推理能力】可能与较少的原始训练数据量（万条）和训练目标（保证准确率）有关，微调后的小模型很难有举一反三的能力。因此，构造多样化的训练集和评测集格外重要。 **优势：** 1. 使用7B的小模型，响应快，全量结果一般在3秒左右返回。 2. 准确率高：经过完整评测流程，只要提问与训练数据语义相关，就能有较高准确率。 **缺点：** 1. 有一定微调和部署成本。 2. 对于未训练过的问题，模型无法自行判断，存在乱回答的情况。 ### 阶段四：多种技术结合使用 1. **SFT+向量数据库** 希望微调后的大模型对未训练过的问题直接拒绝回答。思路：如果SFT大模型的返回结果与向量搜索的前几条结果相似度不高，就认为是未训练的数据，直接拒绝。 2. **RAG+SFT** - **将SFT后的模型作为RAG里的总结推理模型？** —— 不可行。因为RAG的总结推理依赖的是大模型的通用总结能力，而不是QA问答能力，不适合用经过QA微调的模型。 - **命中SFT未训练过的问题时，跳转到RAG流程回答？** —— 综合考虑RAG强大的兜底能力和费用问题，可以根据需要选择性开启。 于是，我们开始让向量搜索、RAG、SFT各司其职，以下的简化流程图展示了在一次问答中它们是如何协同工作的：

### 阶段五：工程优化 1. **【体验优化】** 丰富点赞、点踩、图片和视频回答能力，展示相似问题列表等。 2. **【自我迭代】** 通过工程自动化实现数据清洗、模型训练部署等环节的自动化，让模型具备“自我学习”能力——毕竟大模型在快速发展，微调模型和快速切换的能力很重要，而未来成本一定会下降。 3. **【数据沉淀】** 一线用户的反馈和高质量的人工答疑数据，统一沉淀为文档，作为后续数据资产。 ## 结语 作为工程应用领域的开发者，我们不能仅仅根据“目前AI能做什么”来构建产品，更要看到未来的方向。比如，以前大家一直诟病大模型推理能力弱，于是诞生了很多繁重的提示词工程和思维链方法。但当OpenAI O1这样的模型发布后，很多复杂的解决方案可能就不再那么必要了。 可以预见的是，大模型的能力只会越来越强，调用成本会越来越低，模型定制的确定性也会越来越好。除了保持学习与实践，更值得思考的问题是：哪些才是工程应用真正需要沉淀的能力和方向。