简述企业落地RAG技术时遇到的困境_rag落地人才能力要求、

大模型如火如荼，企业在去年的喧嚣过后今年开始进入正经的落地阶段。落地的第一步就是选择场景。这本身就是一个非常困难的工作，因为选好场景，对大模型最终提供的服务质量影响太大了。选场景这个事可以另开一篇文章来讲，从目前接触的客户来看，使用RAG技术落地大模型还是比较普遍的一个选择，但各家也都遇到了许多的困难。本文就目前遇到的客户问题，进行一些整理和归纳，后续对我们深入研究大模型的应用有所指导。

为什么选择RAG技术来落地大模型呢？

首先再啰嗦一下RAG是什么。
检索增强生成（Retrieval-Augmented Generation, RAG）技术研究旨在提供更有依据、更依赖事实的信息来帮助解决生成式AI的幻觉倾向、专业力弱等固有缺陷。具体来说，大模型在回答问题或生成内容前，首先在外部数据库中进行检索，将相似度高的内容返回给大模型再进一步整理生成。这种模式能够提高输出的准确性和相关性，避免大模型产生“幻觉”生成事实不正确的内容。

大多数企业之多以选择RAG技术落地相关场景，最重要的一点就是投入相对较少，不是一定需要微调模型。我们知道微调一个模型不仅成本高，还有可能吧模型“调坏”，忘记了基本的逻辑和知识。选用RAG更像是用工程化的思路，从务实的、白盒的角度去落地大模型应用。选用一个开源基础大模型，加上一个开源向量数据库，使用LangChain的框架，很快就能搭建一个“naive RAG”。

企业落地RAG遇到的困境有哪些？

企业遇到的困境分为两部分，第一部分是来自于本身运营层面的困境，如数据无法收集、发无法保证百分之百的准确率从而不能真正直面客户、多个部门都在搞重复基建等等。第二部分则是面临的技术困境，如基础大模型如何选型、向量化应该使用什么模型、如何提高召回准确率等等。
本文主要讲一下企业面临的技术困境，这方面无论大小企业，都还有一些相通之处。

落地层面的技术困境

1.关于数据：

如何收集领域数据

例如公司内部的业务规则，操作文档，流程文档，规章制度等等，可能需要协调各个部门上传文档（有些涉及到机密难以上传），且各部门文档格式五花八门，需要统一规范整理；
外网公开数据收集，则需要设计爬虫程序，选择性爬取公开数据，整理成规范的文档并存储，例如证券行业的研报、财报、监管制度等等；
所以使用RAG的第一步，就是先收集未来要向量化的数据。

如何chunk文档

chunk的准确性直接影响到后续向量召回的准确性。
首先说分块的大小。切分合适大小的块很重要，如果块太小或太大，可能会导致不精确的搜索结果或错过展示相关内容的机会。另外切分出来的文本块应是语义独立的，也就是没有对上下文很强的依赖，这样对语言模型来说是最易于理解的。
然后是分块的方法。分块有不同的方法，每种方法都可能适用于不同的情况：

• 固定大小分块，这是最常见、最直接的分块方法。只需决定块中的tokens的数量，以及它们之间是否应该有任何重叠。一般来说，我们会在块之间保持一些重叠，以确保语义上下文不会在块之间丢失。在大多数情况下，固定大小的分块将是最佳方式。与其他形式的分块相比，固定大小的分块在计算上更加经济且易于使用，因为它在分块过程中不需要使用任何NLP库，速度块。
• 分割符切分，例如使用langchain，支持对md、html、py、js等各种特殊文本或代码进行切分。
• 语义相似度切分和利用大模型Agent分分，利用这种方式对文档的切分，能最大程度的保留每一段的完整性，但是对技术的要求很高，需要做调研和选型。
  最后是对不同格式数据的准确预处理方法不同，上述chunk方法对文字类型的数据处理，相对有一些成熟方法，但是对图片和表格，处理起来会很费劲。如从图片中数据抽取，或者对pdf中的原生表格进行提取。传统的OCR需要大量的标注和训练，不太适合这个场景。有些性能较好的基础大模型已经具备了多模态提取信息的能力，但有些不行仍需微调，具体方法也要视情况而选择。

如何向量化数据/Embedding

文档切分完成后，下一步要做的就是embedding（嵌入）每个文档块。
在机器学习和自然语言处理中，embedding是指将高维度的数据（例如文字、图片、音频）映射到低维度空间的过程。embedding向量通常是一个由实数构成的向量，它将输入的数据表示成一个连续的数值空间中的点。简单来说，embedding就是一个N维的实值向量，它几乎可以用来表示任何事情，如文本、音乐、视频等。
生成Embedding的方法有很多。这里列举几个比较经典的方法和库：
Word2Vec：是一种基于神经网络的模型，用于将单词映射到向量空间中。Word2Vec包括两种架构：CBOW (Continuous Bag-of-Words) 和 Skip-gram。CBOW 通过上下文预测中心单词，而 Skip-gram 通过中心单词预测上下文单词。这些预测任务训练出来的神经网络权重可以用作单词的嵌入。
GloVe：全称为 Global Vectors for Word Representation，是一种基于共现矩阵的模型。该模型使用统计方法来计算单词之间的关联性，然后通过奇异值分解（SVD）来生成嵌入。GloVe 的特点是在计算上比 Word2Vec 更快，并且可以扩展到更大的数据集。
FastText：是由 Facebook AI Research 开发的一种模型，它在 Word2Vec 的基础上添加了一个字符级别的 n-gram 特征。这使得 FastText 可以将未知单词的嵌入表示为已知字符级别 n-gram 特征的平均值。FastText 在处理不规则单词和罕见单词时表现出色。
OpenAI的Embeddings：这是OpenAI官方发布的Embeddings的API接口。目前有2代产品。目前主要是第二代模型：text-embedding-ada-002。它最长的输入是8191个tokens，输出的维度是1536。
这些方法都有各自的优点和适用场景，选择最适合特定应用程序的嵌入生成方法需要根据具体情况进行评估和测试。不过，有人测试过，OpenAI应该是目前最好的。收费价格是1000个tokens需要0.0004美元，也就是1美元大约可以返回3000页的内容。获取之后直接保存即可。
选择不同的向量化模型，会对后续的召回产生影响。上述列举的几个embedding模型主要针对文本数据，企业仍需花时间调研和探索其效果。如果是图片或其他类型数据，则需要选择更加复杂的embedding模型，或许还需要选择自己微调。这块儿的成本和效果都难以把控。

2.关于召回：

召回准确率

RAG中重要的一步就是召回相关文档，并将相关文档跟问题一起喂给大模型，然后让大模型根据这些内容组织语言并回答，以减少模型幻觉。但是如果召回的是错误的文档呢？如果文档相关性不高呢？诸如此类的问题一直困扰着召回模块的落地。
常用的方式直接用用户的问题进行文档召回。例如根据用户query一次召回文档片段，让模型生成答案。开源的向量化模型效果可能一般，需要微调一下向量化模型。
只进行一次文档召回在长文本生成的场景下效果往往不好，生成的文本过长，更有可能扩展出和query相关性较弱的内容，如果模型没有这部分知识，容易产生模型幻觉问题。而且用户的问题是十分口语化的，描述的也比较模糊，一种解决思路是随着文本生成，多次从向量库中召回内容，或者使用大模型辅助召回，但计算开销/响应时间是否能够接受就要看具体使用场景了。

召回数据量

数据量的考量主要是受制于大模型的上下文长度，过量的找回数据无法传给大模型，而且召回的数据越多，越影响大模型的理解能力。
在推理层，Transformer模型中自注意力机制（Self Attention）的计算量会随着上下文长度的增加呈平方级增长，比如上下文增加32倍时，计算量实际会增长1000倍。同时，超长上下文也将带来显存与带宽压力。当然现在也有一些针对长文本的大模型，如Moonshot的Kimi Chat，支持128K的上下文长度。但笔者认为在不是必要情况下，减少召回数据量是更加经济可行的方式。
但是召回的数据过少，有可能错过大模型所需要的信息。因此召回的数据需要进行一定的排序，比如一轮粗排，一轮精排等，给大模型最相关的、最有效的文档数据，才能在不影响模型性能的情况下提高达模型会回答的准确率。相关的研究内容包括语义空间对齐、混合检索、检索结果重排和检索效率优化等技术，需要进一步深入研究。

3.关于基础大模型的选择：

场景对模型大小的要求

在不同行业或者不同需求的场景下，什么样模型能力可以覆盖当前需求？比如，在一个“翻译助手”的场景下，6B的基模就可以达到很好的效果，但是在“text 2 sql”的场景下，13B的模型都难以达到80%的准确率。这在企业选择不同尺寸的模型时也造成了一定的困难。也容易造成不同部门、不同场景需要引入不同基模的混乱情况。

模型效果验证

当然，我们可以通过公布的一些排行榜看到不同模型的排行顺序，选择某些评测标准下表现更好的模型。但是基于企业特定的场景，通用的评测标准可能还不够，往往需要结合不同类型的问题来判断某个场景下模型的精度，比如纯检索问题，分析类问题，比较类问题，结论类的问题等。这也涉及到评测任务的设计，评测数据的准备，例如使用公开评测数据集、构建评测问答对、人工介入检验计算逻辑等。

从ChatGPT大火到现在已经一年多了，很多企业的大模型落地之路也已经尝试很多条了，但以RAG为基础的问答知识库类的场景还是落地最多的，那么解决好上述的问题和困难，就离想象中的体现业务价值的大模型应用，更近一步。