大模型LLM在垂直领域的应用分析

        大模型在垂直领域内如何应用，是自己最近关注的问题。通用大模型很好，但对于to B商业化，特别是垂直的商业领域，还需要做垂直化适配的很多工作。这篇文章仅仅作为自己在调研分析过程的一次笔记记录，如果有其他好的分享或者见解，欢迎留言评论。

        本篇主要从垂直化大模型技术选型、选型技术分析、效果评估、可能面临的技术&业务问题及解决方案等方面进行阐述相关的技术方案。

1. 大模型垂直化技术选型

        大模型一般可以分为通用大模型和垂直领域大模型。通用数据进行预训练的大模型具备跨任务的通用性和跨域的通用性，一般适用于聊天等非领域任务性场景。而垂直领域大模型是指在特定的领域或行业中经过训练和优化的大型语言模型。与通用大模型相比，垂直领域大模型更专注于某个特定领域的知识和技能，具备更高的领域专业性和实用性。

        某具体的商业领域垂直大模型预期是能够深入理解和处理该领域的特定知识和术语，从而提供更准确的结果。可以针对该领域的常见任务进行优化，提高任务完成的效率和效果。建立垂直领域的大模型能够更好地满足To B商业化的需求，提供面向具体业务需求的解决方案。

        经过调研，通用大模型垂直化，采取的方式主要有：预训练模型、模型微调、检索生成。首先只使用垂直领域数据预训练大模型，需要大量的高质量训练数据（普遍在TB量级），算力要求也极其庞大（比如百亿参数规模的大模型通常需要数百到数千个高性能GPU（如NVIDIA A100、V100）来并行训练，以月为训练时间单位），比如训练GPT-3的成本大概是2500万人民币，并且还需要不断尝试迭代，才可能拿到好的效果，这种模式要求高、代价大。

        相对来说，模型微调与检索生成对于一般的业务场景应用代价较预训练低很多。基于垂直领域知识对通用大模型的微调，通过目前主流的微调方式（如LoRA、P-Tuning、Prefix Tuning等）对通用大模型进行微调，这种方式优势是算力资源的要求可以大幅降低，但同样还是需要大量的高质量标注数据，而标注数据往往需要投入大量资源获得，并且微调模型需要反复迭代，迁移学习效果可能不理想。而使用领域知识库结合通用大模型完成知识问答，具体就是先使用词向量模型找到文档中和问题相似的文本，利用大模型的总结能力对文本进行汇总作为输出，通常也被称为检索赠强生成(RAG)，这一路线是目前国内解决大模型垂直化的可落地确定性高的技术方案。

        参考文献【1】中对RAG与FT做了对比，可以参考自身业务和资源投入情况进行选择对应的技术路线。

图1. RAG vs FT 流程

模型	RAG	Fine-tuning
成本 - 输入token规模	增加的提示语规模	最小
成本 - 输出token规模	更冗长，难以控制	精确，简明
初始成本	低 - 创建嵌入	高-微调
准确性	有效	有效
新的知识	数据在上下文中	领域内的新技能

        微调通过使用特定领域的数据集，更新模型大部分或全部参数，从而定制一个专门用于特定领域的预训练 LLM。这种方法需要更多的数据，同时成本比较高，它更适用于风格迁移的场景，但能为专门的用例提供很高的准确性。

        提示工程可以在不改变模型参数的情况下，通过改变大模型提升词输入来引导模型输出。这是一种最节省资源的方法，适用于数据和计算资源有限的应用。RAG 利用外部数据库中的信息增强了 LLM 提示功能，它本质上是一种复杂的提示工程，更适用于通用场景。

        使用大模型构建应用程序时，可以首先使用 RAG，借助外部信息快速提升模型的响应性，提高模型返回结果与垂直领域的相关性。本文接下来会重点分析RAG技术。

RAG优势：

RAG 更具可扩展性

RAG 比FT更便宜，因为后者涉及更新大型模型的所有参数，需要大量的计算能力。

RAG 不需要标记和制作训练集，构造数据是一个人力密集型的过程，可能需要数周甚至数月的时间才能完善每个模型。

RAG 可带来更值得信赖的结果。微调在很大程度上就像一个黑匣子，因此很难查明模型如何生成特定结果，从而降低了信任和透明度。

RAG 可以更好地处理动态数据，从最新数据的精选数据集中生成确定性结果。

2. 面向垂直领域的RAG解决方案

        检索增强生成（Retrieval-Augmented Generation, RAG）技术是一种新型的自然语言处理技术，旨在通过结合垂直领域专有数据，提高Chatbots的智能交互能力。是在2020年，由Meta提出《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。

图2. 一种通用的微调方案，用于检索增强生成（RAG）用于语言生成。

将一个预训练的检索器（查询编码器 + 文档索引）与一个预训练的seq2seq模型（生成器）结合起来，并进行端到端微调。对于查询 x，使用最大内积搜索（MIPS）来找到前 K 个文档 。对于最终的预测 y，将 z 视为潜变量，并在给定不同文档的情况下对seq2seq预测进行边际化处理。

        RAG技术结合了检索和生成两种方法，既能够从大规模语料库中检索相关信息，又能够利用生成模型生成自然语言文本。 RAG技术的核心在于将检索和生成过程相结合。首先，通过垂直领域专有数据构建一个知识库，为Chatbots提供丰富的信息和知识。然后，使用生成模型（如Transformer或GPT系列模型）根据用户的输入和上下文信息，生成自然语言回复。同时，RAG技术还引入了检索步骤，从知识库中检索与当前对话相关的信息，为生成模型提供更准确的回复。

图3. 基于RAG的垂直领域问答系统

RAG系统相关要点：

1. 构建知识库数据：这指的是模型原始训练数据集之外的新数据。这些数据可以来自多个来源，如API、数据库或文档库，并且可能以文件、数据库记录或长文本等多种形式存在。通过另一种AI技术，即嵌入语言模型，将数据转换为数值表示，并存储在向量数据库中。这个过程创建了一个知识库，供生成式AI模型理解。

2. 检索相关信息：接下来进行相关性搜索。用户查询被转换为向量表示，并与向量数据库进行匹配。例如，考虑一个可以为组织回答人力资源问题的智能聊天机器人。如果员工搜索“我有多少年假？”系统将检索与年假政策文件以及个人员工过去的休假记录相关的文档。这些特定文档将被返回，因为它们与员工输入的内容高度相关。相关性是通过数学向量计算和表示来确定的。

3. 增强LLM提示：RAG模型通过添加检索到的相关数据来增强用户输入（或提示）。这一步使用提示工程技术与LLM有效沟通。增强的提示使得大型语言模型能够针对用户查询生成准确的答案。

4. 更新外部数据：如果外部数据变得过时怎么办？为了保持检索信息的时效性，需要异步更新文档并更新文档的嵌入表示。这可以通过自动化的实时过程或周期性的批处理来完成。根据实际应用效果和用户反馈，不断优化和调整RAG技术的参数和策略，以提升Chatbots的交互体验。

2.1 RAG相关技术选型

       图4. RAG分层架构

         构建本地知识库的RAG，需要三个核心内容：1）大模型（包含embedding模型）；2）向量数据库；3）知识内容（垂直领域数据）。

        大模型：基于行业内的实践，发现在13B这种规模的参数下，领域模型是可以优于通用模型，因此可以使用百亿参数的开源版本。百亿参数规模的面向中文语言的LLM模型，比如Qwen、ChatGLM、Baichuan2。

        向量数据库：有很多可选，milvus，qdrant，pg-vector等等，硬件资源充足的可选milvus、qdrant容器化部署。

        知识库：需要提供知识库管理，可以满足对不同知识库RAG的构建需求。增强可以采用多种形式的数据，包括非结构化的文本数据，如文本段落、短语或单个词汇。此外，也可以利用结构化数据，比如带有索引的文档、三元组数据或子图。

        应用构建框架：可以使用开源框架，比如选择的对中文支持更友好的工具，提供在线web UI的使用，还需要考虑部署的环境搭建等。

2.2 模型参数规模及算力要求

        对于大模型的选择，选择百亿参数级别的大模型作为RAG中的基础大模型使用，这样对于算力资源的要求可以相对可控，这里给出一个大概的模型参数与算力资源的要求，我们只需要使用到大模型的推理能力。

对于Llama 2 13B模型，显存需求如下：

• 全精度（float32）：每个参数需要32位（4字节）的存储空间。因此，对于13B参数的模型，理论上需要 13B * 4字节 = 52GB 的显存。这仅考虑了模型参数本身，并未包括其他运行时所需的额外空间，如优化器状态、激活等。

• 半精度（float16）：在半精度下，每个参数占用16位（2字节）。这样，13B模型的显存需求降低到 13B * 2字节 = 26GB。

• 更低精度：随着精度的降低，显存需求进一步减少。例如，8位精度（int8）和4位精度（int4）的模型分别需要 13B * 1字节 = 13GB 和 13B * 0.5字节 = 6.5GB 的显存。

        显卡性能要求，除了显存大小，显卡的其他性能参数，如核心数、内存带宽和计算能力，也会影响模型的运行效率。高性能的显卡可以提供更快的数据处理速度和更高的并行计算能力，从而缩短模型推理和训练的时间。

    推荐显卡配置：

• NVIDIA A100（单价约 100k人民币）：拥有80GB的显存，适合运行大规模的LLMs，如Llama 2 13B模型。A100的高内存带宽和强大的计算能力使其成为大型模型训练的理想选择。

• RTX 3090（单价约 10k人民币）：作为消费级市场的顶级显卡，RTX 3090提供了24GB的显存，对于13B规模的模型来说，可能需要在精度上做出妥协，或者利用模型并行技术来分散显存需求。

• RTX 3080（单价约6k - 7k人民币）：拥有10GB显存的RTX 3080在半精度或更低精度下可以运行13B模型。根据用户反馈，3080（8G）可以运行7B模型，因此对于13B模型，可能需要在精度上做出调整。

2.3 知识库构建

图5. 垂直领域知识库构建索引及检索流程

知识库构建主要包括数据加载，文本切片和内容向量化三个部分，其中核心处理模块是文本切片。目前主要有2类切分方法，一种是基于策略规则，一种是基于算法模型。

1. 基于策略规则的切分方法,可以参考:

       1.截断 截取前510个或后510个或前128+后382；

       2.分段 分段k=L/510,然后各段可以求平均、求max；

       3.滑动窗口 （Sliding window），即把文档分成有重叠的若干段，然后每一段都当作独立的文档送入模型进行处理。最后再对于这些独立文档得到的结果进行整合；

2. 基于算法模型的切分方法(这类方法可能较难落地): 主要是使用类似BERT结构的语义段落分割模型，能够较好的对段落进行切割，并获取尽量完整的上下文语义。

内容向量化: 将切片后的文本信息转成相应的语义向量。关于text2vec， 可以使用text2vec模型，bge和m3c等语义模型支持的长度均为512。从使用效果来看，可以优先选择bge-large。另外也可以选择一些其他预训练模型进行embedding，一般都有提供这类接口能力。

基于以上所述，在索引方面，首先要将知识库分解成多个文本块。将每个知识片段传递给嵌入机（embedding machine）进行处理，然后得到该文本的嵌入表征。然后，将该片段与其嵌入一起保存在向量数据库中，这是一种专门用于处理数字向量的数据库，可用于存储和检索嵌入向量。

2.4 RAG效果评估

        RAG 的评估方法多样，主要包括三个质量评分：上下文相关性、答案忠实性和答案相关性。此外，评估还涉及四个关键能力：噪声鲁棒性、拒答能力、信息整合和反事实鲁棒性。这些评估维度结合了传统量化指标和针对 RAG 特性的专门评估标准。

        在评估框架方面，存在如 RGB 和 RECALL 这样的基准测试，以及 RAGAS、ARES 和 TruLens 等自动化评估工具，它们有助于全面衡量 RAG 模型的表现。

1. RGB (Relevance, Grammaticality, Brevity)

     RGB 是一种用于评估生成文本质量的基准。它从三个维度来评估文本生成模型：

1. Relevance（相关性）：生成文本与输入或上下文的相关程度。

2. Grammaticality（语法性）：生成文本的语法是否正确。

3. Brevity（简洁性）：生成文本的简洁程度，避免冗长。

2. RECALL (Relevance and Conciseness Oriented Assessment of Language Models)

        RECALL 是一种评价生成模型的框架，特别关注生成内容的相关性和简洁性。通过量化生成文本相对于参考文本的质量，RECALL 帮助研究人员和开发者优化模型的生成性能。

3. RAGAS (Relevance, Accuracy, Grammar, and Style)

    RAGAS 是一个综合的评估框架，用于评估文本生成模型在多个维度上的表现：

1. Relevance（相关性）：生成文本与输入或预期输出的匹配程度。

2. Accuracy（准确性）：生成文本的事实准确性。

3. Grammar（语法）：生成文本的语法正确性。

4. Style（风格）：生成文本的风格和可读性。

4. ARES (Automated Reasoning Evaluation System)

        ARES 是一种用于评估文本生成和理解模型的系统，特别关注模型在逻辑推理和复杂任务上的表现。它通过自动化的方式来评估模型在推理任务中的准确性和效率。

5. TruLens

        TruLens 是一种用于理解和解释生成模型行为的工具。通过可视化和分析模型的内部机制和生成过程，TruLens 帮助研究人员和开发者更好地理解模型的决策过程，并改进其性能。

图6. RAG生态圈

2.5 其他常见的RAG模式

图7. RAG模式

        除了一次检索外，RAG 还包括三种类型的检索增强过程。 （左）迭代检索涉及在检索和生成之间交替，允许在每个步骤从知识库中获取更丰富和更有针对性的上下文。 （中间）递归检索涉及逐步细化用户查询，并将问题分解为子问题，然后通过检索和生成持续解决复杂问题。 （右）自适应检索侧重于使RAG系统能够自主确定是否需要外部知识检索以及何时停止检索和生成，通常利用LLM生成的特殊token进行控制。

2.6 RAG可能会面临的问题及相应的解决方案

  参考文献【5】中列举了RAG系统中可能存在失败的7类环节的问题，如图8标红的方框所示。

图8. 创建检索增强生成（RAG）系统所需的索引和查询过程。索引过程通常在开发时进行，查询在运行时进行。识别的故障点以红框表示。所有必需的阶段均用下划线标出。        

1. 第一个故障情况是提问无法从现有文档中找到答案。在理想情况下，RAG系统会回复类似“抱歉，我不知道”的内容。然而，对于与内容相关但没有答案的问题，系统可能会被欺骗而给出一个回应。

2. 第二个故障是问题的答案存在于文档中，但没有排名足够高而无法返回给用户。理论上，所有文档都会被排名并在接下来的步骤中使用。然而，实际上只会返回前K个文档，其中K是根据性能选择的值。

3. 第三个故障是整合策略的局限性，含有答案的文档从数据库中检索出来，但未能进入生成答案的上下文中。这发生在从数据库返回了许多文档并进行整合以检索答案时。

4. 第四个故障是答案存在于上下文中，但大型语言模型未能提取出正确的答案。通常，这发生在上下文中有太多噪音或相互矛盾的信息时。

5. 第五个问题涉及以特定格式（如表格或列表）提取信息，而大型语言模型忽略了这一指示。       

6. 第六个故障是答案已在回复中返回，但不够具体或过于具体，无法满足用户需求。这发生在RAG系统设计者对特定问题有期望的结果时。在这种情况下，应提供具体的内容而不仅仅是答案。当用户不确定如何提问且过于笼统时，也会出现特异性不正确的情况。

7.第七个故障是答案不够完整。

以上给出了一些容易产生问题的关键点，接下来继续给出一部分垂直领域优化可能面临的挑战以及应对策略，如下所示：

1. LLM的安全问题

问题：处理提示注入、不安全输出以及防止敏感信息泄露等问题。

解决方案： 需要支持集成敏感词检测服务，自动识别和过滤掉可能引起安全问题的词汇。
 配置敏感词库、添加删除修改敏感词、模型输出预处理、自动过滤替换敏感词等。

2. 内容缺失

问题：知识库中缺少必要的上下文信息，当知识库没有包含正确答案时，RAG 系统可能会给出一个貌似合理但实际上错误的回答，而不是明确表示它不知道答案。

解决方案： 设置阈值，在回答问题前先设定一个质量标准。如果召回内容达不到标准或无召回，
系统不会提供答案，而是告诉用户需要更多信息或返回固定话术，防止错误或不准确的信息误导用户。

3. 遗漏关键知识

问题：在初始的检索步骤中，有时会漏掉关键文档，导致它们没有出现在系统返回的最顶端结果之中。这就意味着正确的答案可能被忽略了，使得系统无法准确回答问题。

解决方案： 1. 分析用户意图：通过分析用户的查询词汇和历史交互，缩小搜索范围，提高检索的相关性。
 2. 混合增强 RAG：关键词检索解决没有 Embedded 的内容检索正确性，语义检索解决 Query 和 
Doc 语义不一致的问题，综合提高检索的准确性。 3. 引入重排序模型：根据用户的实际反馈和文档的
相关性指标，对召回的文档进行二次排序，确保最相关的内容出现在结果的顶部。

4. 脱离上下文

问题：没有明确的事实验证机制，数据库检索到了包含答案的文档，但这些文档没有被纳入生成答案的上下文中，生成听起来合理但是错误的声明，会损害结果可信度。

解决方案： 通过标签分类文档，在搜索时通过标签来缩小搜索范围，减少无关信息干扰，检索与用户查询
最相关的文档。 开发辅助头部直接从检索上下文预测真实性。将结构化知识库纳入以根据已知的实体和关
系对响应进行事实检查。 设计置信度估计方法以量化确定性并标记未经验证的声明。尽量减少开放式
生成，以便从已验证的上下文中进行提取性总结。

5. 错误的特定性

问题：回答在响应中返回，但不够具体或太具体，无法满足用户的需求。

解决方案： 级联增强，根据用户的初始查询生成回答，系统分析第一次回答的结果，识别出更多细节，
并据此生成更具体的问题，系统使用更具体的问题再次进行 RAG，逐步提高回答的质量。

6. 信息提取困难

问题：有时系统难以从提供的上下文中提取正确答案，特别是当上下文信息量过大时。关键细节可能会被忽略，影响回答的质量。

解决方案： 将这些信息转化为结构化的知识，并与现有索引系统相结合，快速有效地响应用户的查询。

7. 输出不完整

问题：有时输出虽不完全错误，但却未能提供所有详细信息，尽管这些信息在上下文中是存在且可以获取的。例如，询问文档 A、B 和 C 讨论的主要方面时，分别询问每个文档可能更能确保获得全面的答案。

解决方案： 使用大模型对用户提出的问题进行拆解，将其分解为更小、更具体的子问题，接着，系统对每个
子问题分别进行 RAG 流程，以确保每个文档的关键信息都能被充分考虑和提取，从而提供更完整、更全面
的回答。

8. 结构化数据的查询应答

问题：对于复杂或含糊的查询，准确解释用户查询并检索相关结构化数据可能颇具挑战。

解决方案： CoT 和 ToT 流程：鼓励大模型在生成答案之前进行更深入的思考。CoT 流程要求模型展示
其推理过程，而 ToT 则进一步让模型对自己的推理进行反思，从而提高大模型在处理结构化数据查询时的
表现。

9. 长下文长度

问题：检索内容过多，超过窗口限制怎么办 ？如果 LLMs 的上下文窗口不再受限制，RAG 应该如何改进？

解决方案: 采用分布式处理框架提升力，确保系统在面对大规模数据时仍能保持高性能和高可用性

10. 推理速度慢

问题：检索与生成的耦合使RAG模型无法匹配标准语言模型的延迟。推理管道缺乏针对需要毫秒级响应的实时应用的优化。

解决方案： 优化标记化、编码和检索推理以在生成之前最小化开销。使用像NMSLIB、FAISS或ScaNN这样
的库实现高效的 近似最近邻索引。利用模型并行性和批量检索+生成来提高管道效率。

11. 备用模型

问题：在使用 LLM 时，可能会遇到比如 OpenAI 模型的速率限制错误等问题。在主模型出现故障时，你需要一个或多个备用模型作为后备。

解决方案： 支持接入多种模型，可以根据需要快速切换不同的LLM。

12. 关于Query重写

        参考材料【21】提到关于知识库中检索到与用户query不相关的内容，可能是因为用户的问题描述不利于检索，这个时候除了使用更强的意图识别模型，还可能涉及到重写query。

        重写query模块主要利用大模型重新组织用户query，而不是直接使用原始的用户query进行检索。这是因为对于RAG系统来说，在现实世界中原始query不可能总是最佳的检索条件。

        参考文献【6】提出Hypothetical Document Embeddings（HyDE），该方法是一种生成文档嵌入以检索相关文档而不需要实际训练数据的技术。首先，LLM创建一个假设答案来响应query。虽然这个答案反映了与query相关的模式，但它包含的信息可能在事实上并不准确。接下来，query和生成的答案都被转换为嵌入。然后，系统从预定义的数据库中识别并检索在向量空间中最接近这些嵌入的实际文档。

       参考文献【7】引入了一个新的框架--Rewrite-Retrieve-Read，从查询重写的角度探讨了用于检索增强型LLMs的方法。与先前的研究集中于调整检索器或阅读器不同，该方法关注于调整搜索查询本身，因为在检索过程中输入文本与所需知识之间不可避免地存在差距。首先提示LLM生成查询，然后使用网络搜索引擎检索上下文。此外，为了更好地对齐查询和冻结模块，提出了一个可训练的方案。采用一个小型语言模型作为可训练的重写器，以适应黑盒LLM阅读器。重写器通过强化学习利用LLM阅读器的反馈进行训练。在下游任务、开放域问答和多项选择问答中进行了评估。

        参考文献【8】该工作探索了LLM如何通过抽象和推理两个步骤来处理涉及许多低级细节的复杂任务。抽象，不直接解答问题，而是首先提示LLM提出关于更高级别概念或原理的一般步回问题，并检索与该高级概念或原理相关的事实。步回问题针对每个任务都是独特的，以检索最相关的事实。推理，基于关于高级概念或原理的事实，LLM可以推断出原始问题的解决方案。我们称之为抽象引导推理。使用 LLM "后退一步"生成高层次的抽象概念，将推理建立在抽象概念的基础上，以减少在中间推理步骤中出错的概率。这种方法即可以在有检索的情况下使用，也可以在无检索的情况下使用。当在有检索情况下使用时，抽象的概念和原始问题都用来进行检索，然后这两个结果都用来作为LLM响应的基础。

3. RAG论文项目

github项目“awesome-generative-ai-guide”维护了一个与RAG相关的论文列表，可以参考。

图9. RAG论文列表截图

4. 参考资料

【1】Balaguer, Angels, et al. "RAG vs fine-tuning: Pipelines, tradeoffs, and a case study on agriculture." arXiv e-prints (2024): arXiv-2401.

【2】Gao, Yunfan, et al. "Retrieval-augmented generation for large language models: A survey." arXiv preprint arXiv:2312.10997 (2023).

【3】Zhao, Penghao, et al. "Retrieval-augmented generation for ai-generated content: A survey." arXiv preprint arXiv:2402.19473 (2024).

【4】Lewis, Patrick, et al. "Retrieval-augmented generation for knowledge-intensive nlp tasks." Advances in Neural Information Processing Systems 33 (2020): 9459-9474.

【5】Barnett, Scott, et al. "Seven failure points when engineering a retrieval augmented generation system." Proceedings of the IEEE/ACM 3rd International Conference on AI Engineering-Software Engineering for AI. 2024.

【6】Gao, Luyu, et al. "Precise zero-shot dense retrieval without relevance labels." arXiv preprint arXiv:2212.10496 (2022).

【7】Ma, Xinbei, et al. "Query rewriting for retrieval-augmented large language models." arXiv preprint arXiv:2305.14283 (2023).

【8】Zheng, Huaixiu Steven, et al. "Take a step back: Evoking reasoning via abstraction in large language models." arXiv preprint arXiv:2310.06117 (2023).

【9】The Moat for Enterprise AI is RAG + Fine Tuning – Here’s Why

【10】RAG with Knowledge Graph

【11】垂直领域大模型的思考

【12】RAG带来蓬勃应用生态

【13】本地化知识库RAG系统的构建

【14】RAG技术全解析：打造下一代智能问答系统

【15】知识检索增强（RAG）

【16】RAG开发中常见的12个痛点及天壤解法

【17】开源大模型训练及推理所需显卡成本

【18】Model Memory Calculator

【19】在大模型RAG系统中应用知识图谱

【20】基于知识图谱的检索增强技术与优势对比

【21】RAG实战全解析：一年探索之路