关于垂直领域大模型的探索和尝试

最近这一两周看到不少互联网公司都已经开始秋招提前批面试了。

不同以往的是，当前职场环境已不再是那个双向奔赴时代了。求职者在变多，HC 在变少，岗位要求还更高了。

最近，我们又陆续整理了很多大厂的面试题，帮助一些球友解惑答疑，分享技术面试中的那些弯弯绕绕。

总结链接如下：

《大模型面试宝典》(2024版) 发布！

喜欢本文记得收藏、关注、点赞。

在过去一年多的实践工作中，我们团队围绕大模型在专业领域的应用做了一些尝试和探索。在此也把这两年的一些技术经验分享出来，希望跟大家一起交流和探讨。

垂直领域大模型的特点

垂直领域大模型是指以通用大模型作为base model，再喂以特定领域或行业的领域知识，经过训练和优化的大语言模型。与通用语言模型相比，垂直领域大模型更专注于某个特定领域的知识和技能，具备更高的领域专业性和实用性。但因为一些特殊性（比如对于准确性的要求、知识库的频繁迭代等），也面临着不一样的挑战。

▐ 优势

• 领域专业性：垂直领域大模型经过专门的训练，能够更好地理解和处理特定领域的知识、术语和上下文。

• 高质量输出：由于在特定领域中进行了优化，垂直领域大模型在该领域的输出质量通常比通用大模型更高。

• 特定任务效果更好：对于特定领域的任务，垂直领域大模型通常比通用大模型表现更好。

▐ 挑战

• 准确性：消费者对于大模型的产出都有一定的容忍度，比如写个小说、画个图。大模型只要回答的不是太差，消费者对于结果都会一定程度的接受。但商家对于大模型产出的结果的准确性更加敏感。同时大模型的试错成本很高，如果一次结果不满意，商家可能就不愿意用第二次。

• 知识库维护：商家经常频繁的更替、维护自己的知识库，并且知识库里面的素材多种多样，有流程图、ppt、pdf等。如何保证大模型高效、准确的识别不同知识库体系里面的相关知识，并为后续的RAG召回高质量的答案是需要面临和解决的挑战。

• 适用性限制：垂类大模型在特定领域中的适应性较强，但在其他领域的表现可能相对较弱。但我们在实际使用中，又不能完全杜绝使用者会问一些非相关的问题，所以在实际的微调过程中，需要与一些通用数据集合并在一起进行微调。

挑战及解决方案

▐ 对齐增强

主要作用：在实际的答疑场景中，提问者并不会将问题进行过多的描述，所以我们借鉴了BPO的思路，通过优化提问和提供思路使得大模型更好的理解问题和回答问题，可以有效的提升大模型的回答质量和准确度。（关于BPO的思路，可以详见文章“Black-Box Prompt Optimization: Aligning Large Language Models without Model Training”），BPO的大致过程：

Step1: 给某一个大模型A init instruction ，让A针对标准问题pair（Q1，A1）的问题，生成答案（Q1， A1’），因此每个标准问题对都变成了三元组（Q1, A1, A1’)， 这边A1对应的是good answer， A1’ 对应的是bad answer；

Step2: 然后让GPT4对比good answer 和 bad answer 以及 问题Q 去优化 init instruction 生成 tuned instruction；

Step3: 训练一个seq2seq模型，输入是 问题Q ，输出是 tuned instruction；

Step4: 将这个seq2seq模型，放到大模型体系里面，所有的用户问题 都可以利用这个seq2seq生成对应的提示信息，然后将 提示信息 + 问题 放到大模型里面去进行回答。

通过使用BPO给我们回答准确率带来了1.8%的提升！

用了对齐增强后的效果：

原问题： 下班后帮我推荐个附近好吃的店？

通过对话增强优化后的提问： 今天是周五，路上比较拥挤。想吃点辣的，给我推荐下周围车程不超过10分钟有什么好吃的店？

备注：BPO这个方法在这届WAIC会议GLM专场中也有专门提到过，可见确实是好用。

▐ Text2API

主要作为： 大模型作为一个Agent，学会使用现有工具去解决较复杂的逻辑问题是大模型区别于传统答疑类机器人的一个显著特点。我们有超过1000个需要高频调用的API，同时部分API还具备一定的相似性（比如查询商品信息、查询组套信息、查询货品信息等）。并且因为用户体验，查询api的时间通常要压缩在2s以内，如何高效和准确识别问题中的参数、和找到对应的api是我们需要去解决的2个问题。

最开始的时候我们使用langchain中自带的react框架进行text2api的构造，但发现几个问题：

• langchain完全依赖底座模型，在chatgpt4上表现很好。但在一些中文模型上无法很好识别api的输入参数，经常出现幻觉导致乱编参数的现象。

• langchain调用链路很长，导致我们在改写较复杂问题text2api的时候会有大量的工作。并且react框架因为没有penalty机制，如果出现调用错误的情况，只能人工检查然后通过增强prompt的方式进行修正。

后来我们尝试引进了Reflexion框架，（详见文章：Reflexion: Language Agents with Verbal Reinforcement Learning），相较于传统的Reactor，Reflexion提供了自我反思机制，然后在memory模块中保存之前的短期记忆和长期记忆，从而在之后的决策中，基于储存的记忆诱导大模型生成更好的答案。通过reflexion返回的api准确率提升了4%。值得一提的是，在实际使用前，我们还通过对齐增强模块对某个api的描述进行提示性的补充增强，从而解决部分相似api无法识别的问题。

▐ RAG

RAG是经典、高效的垂类大模型应用方案，就是通过自有的垂域数据库检索相关信息，然后合并成为提示模板，喂给大模型生成最终的答案。但因为内容素材的多样性，例如下图是我们实际官方上门的某一个白皮书文档，里面包含了pdf式的合同、表格、系统界面截图和操作流程图。如何在文档注入的时候能够很好的解析这些素材，并且在做RAG时候能精准的返回对应的结果是我们核心要解决的问题。

如何解决复杂的素材： 以流程图为例，我们首先让chatgpt帮我们描述流程图里面对应的步骤，然后我们人工对近1000个chatgpt4生成的结果进行review，并最终放到我们的基座模型中进行sft + dpo。

文本结构重组织：

关于文本切分，目前只要有基于深度模型的切分和基于规则的切分。我们第一个版本用的是基于transformer的切分，但实际效果并不好，后面沿用了基于规则的切分，不过依然有一些经验可以和大家分享：

• 如果将文本分割的结果直接作为embedding，需要特别注意chunk_size大小，太长了大模型容易忘掉中间的内容，太短了又不能包含有效的信息，从而导致关键信息而被忽略。

• 不需要拘泥于原来的文章的行文结构来决定内容的前后关联度，我们引入了一个聚类的方法重新把内容通过「语义逻辑」重新组合，目前来看效果还不错。

• 为了使LLM处理长文本，如果不能无限制的提升context的话，就只能掉过头来先把长文本「压缩」成短文本而尽量不要减少信息量。

• 当聚类之后的 chunk 数量超过了预定的值之后，递归总结的过程还会在内部再次进行递归总结，一直优化到需要的长度。基于上面几步优化，文本信息被重新组织、优化成一棵树。

▐ SFT

我们沉淀了几万条标注过的场景测评数据。这些测评数据是让我们选定基座模型、微调方法 和 后续一直迭代模型的一个重要指引。

在这些测评数据的基础上，我们测评了市面上几乎所有的开源基座模型，以及能看到的几乎全部微调方法，并利用embedding similarity、人工打分、chatgpt4打分这3个维度分别测试 “基座模型” 和 “基座模型+微调” 的表现情况，从而挑选适合我们场景的基座模型和微调方法。

在实际sft时候，我们还夹杂了部分公开数据集为了解决垂类大模型通用能力退化，适用性限制这一问题。公开数据集主要参考了有COIG-CQIA、alpaca-gpt4-data-cn等。

最近，我们也参考ORPO（详见文章：ORPO：Monolithic Preference Optimization without Reference Model)，尝试将SFT + DPO的模式变成单纯在SFT中增加一个惩罚项来让大模型做更好的偏好对齐。通过实验对比，ORPO相较于之前的链路，整体回答效果提升了约5.2%。

结语

以上就是我们团队这段时间在垂类大模型的一些思考和实践。经过一年多的探索，虽然我们在不少的场景上都有突破和进展，但肉眼可见依然有很多领域尚未完善，未来有很多工作需要进一步展开，也非常欢迎大家一起交流大模型技术。