检索增强生成 Retrieval-Augmented Generation

LLM 优化方向

1. 模型微调(Fine-Tuning)

采用预训练的LLM并在较小的特定数据集上进一步训练它以使其适应特定任务或提高其性能的过程。通过调优,我们根据数据调整模型的权重,使其更适合应用程序的独特需求。

微调方法:监督指令微调SFT、基于人类偏好的强化学习RLHF等,需要消耗大量的资源,并且需要相当长的时间,知识更新迭代慢。

2. 检索增强生成(RAG)

将检索(或搜索)的能力集成到LLM文本生成中。结合了检索系统(从大型语料库中获取相关文档片段)和LLM(使用这些片段中的信息生成答案)。本质上,RAG帮助模型"查找"外部信息以改进LLM的响应。

成本低,改善效果明显,知识迭代快。检索步骤作为事实检查机制,降低了模型虚构的能力,生成器被限制为合成检索上下文支持的响应,可以很有效的抑制幻觉。

具有很好的可解释性,微调就像是一个黑盒,每次输出都有太多不确定性,RAG 可以看到检索的过程,增加结果的信任感。

数据安全性,可以将领域内的知识本地化部署,不需要联网。

两者的详细对比:

检索增强生成(RAG)

RAG本质上是通过工程化手段,解决LLM知识更新困难的问题。其核心手段是利用外挂于LLM的知识数据库(通常使用向量数据库)存储未在训练数据集中出现的新数据、领域数据等。通常而言,RAG将知识问答分成三个阶段:创建索引、知识检索和构造提示词问答。

1. 创建索引

  1. 数据提取:图片、pdf、word 等多格式数据加载、不同数据源获取,根据数据自身情况,将数据处理为文本格式。
  2. 分割文本:根据换行、句号、问号、感叹号等切分文本,以保证语义完整性和合适向量化 chunk 大小为原则。语料分割成 chunk 块,检索时会取相关性最高的top_n。实践证实,小块比大块对于提升准确率帮助更大,但也不是越小越好,512token 左右比较合适。由于每个 chunk 块之间关联性会被切断,可以通过在头尾增加一定冗余量来缓解。
  3. 向量化(embedding):将文本数据转化为向量矩阵的过程,该过程会直接影响到后续检索的效果。常用的embedding模型:moka-ai/m3e-baseGanymedeNil/text2vec-large-chinese
  4. 数据入库:数据向量化后构建索引,并写入向量数据库的过程可以概述为数据入库,适用于RAG场景的向量数据库包括:facebookresearch/faiss(本地)、ChromaElasticsearchMilvus 等。

2. 知识检索

常见的数据检索方法包括:相似性检索、全文检索等。 根据检索效果,一般可以选择多种检索方式融合,提升召回率。

  1. 相似性检索:即计算查询向量与所有存储向量的相似性得分,返回得分高的记录。常见的相似性计算方法包括:余弦相似性、欧氏距离、曼哈顿距离等。
  2. 全文检索:全文检索是一种比较经典的检索方式,在数据存入时,通过关键词构建倒排索引;在检索时,通过关键词进行全文检索,找到对应的记录。

3. 构造提示词

提示词都没有固定模板,下面是个示例,需要针对不同模型进行测试。理论来说,参数大的模型效果肯定更好,它的归纳总结能力更强。同时,也需要了解一些提示词工程技术,比如COT思维链等,辅助写出高效的提示词。

python 复制代码
prompt_template = "
    【任务描述】
    请根据用户输入的上下文回答问题,并遵守回答要求。

    【背景知识】
    {context}

    【回答要求】
    - 你需要严格根据背景知识的内容回答,禁止根据常识和已知信息回答问题。
    - 对于不知道的信息,直接回答"未找到相关答案"
    -----------
    {question}
"

Prompt的设计只有方法,没有语法。

以上是理论介绍,目前开源的主流实现框架有:

  • LlamaIndex:是一个"数据框架",它在 LLM 和外部数据源(如 API、PDF、SQL 等)之间提供一个简单的接口进行交互。提供独特的数据结构:向量存储索引、树索引、列表索引等等。
  • LangChain:旨在构建具备 LLM 强大功能的应用程序,管理整个应用的流程,提供各种工具和抽象,以提高大模型生成的信息的定制性、准确性和相关性。

问答效果不好,可以多研究一下LlamaIndex,希望使用更多外部工具或者构建复杂流程,可以多研究一下LangChain。

总结

RAG 可以理解为一个拿着参考资料的人和你对话,侧重于信息检索。微调之后的 llm 则像是一个领域内的人和你沟通,说话风格,表达方式会更贴近领域内的专业人士,一个是形似,一个是神似。如果 llm 的参数量足够大,能力足够强,也是可以模拟一些领域内的风格去回答问题。

优点

  1. 数据源可以是任何格式的,可以较低成本接入知识库。
  2. 可以随时新增数据,延迟非常低,可以忽略不计,因此RAG架构理论上能做到知识的实时更新。
  3. 虽然现在有的模型提示词可以支持到最大200k的长度,但是提示词越长,回复越慢。而RAG无此问题。
  4. 调试方便,输出内容的路径可以追溯,具有可解释性。

缺点

  1. 知识检索阶段依赖相似度检索技术,并不是精确检索,因此有可能出现检索到的文档与问题不太相关。
  2. 推理之前的搜索可能会增大响应延迟和推理成本,增加了向量数据库等额外服务。
  3. 擅长小范围的描述性问题回答,不擅长关系推理,或者时间跨度很长的总结。
  4. 风格变化可能没有微调效果好。

参考资料:

相关推荐
monkey_meng30 分钟前
【遵守孤儿规则的External trait pattern】
开发语言·后端·rust
Estar.Lee1 小时前
时间操作[计算时间差]免费API接口教程
android·网络·后端·网络协议·tcp/ip
新知图书1 小时前
Rust编程与项目实战-模块std::thread(之一)
开发语言·后端·rust
盛夏绽放2 小时前
Node.js 和 Socket.IO 实现实时通信
前端·后端·websocket·node.js
Ares-Wang2 小时前
Asp.net Core Hosted Service(托管服务) Timer (定时任务)
后端·asp.net
我爱学Python!2 小时前
大语言模型与图结构的融合: 推荐系统中的新兴范式
人工智能·语言模型·自然语言处理·langchain·llm·大语言模型·推荐系统
Rverdoser3 小时前
RabbitMQ的基本概念和入门
开发语言·后端·ruby
Tech Synapse4 小时前
Java根据前端返回的字段名进行查询数据的方法
java·开发语言·后端
.生产的驴4 小时前
SpringCloud OpenFeign用户转发在请求头中添加用户信息 微服务内部调用
spring boot·后端·spring·spring cloud·微服务·架构
微信-since811924 小时前
[ruby on rails] 安装docker
后端·docker·ruby on rails