blog-hexo/source/_posts/AI/rag.md

76 lines
4.1 KiB
Markdown
Raw Normal View History

2024-03-28 11:14:49 +08:00
---
title: RAG知识库召回率
categories:
- AI
status: done
abbrlink: 21037
---
# 通用的RAG方案的召回率
2024-03-28 12:11:12 +08:00
不一定召回率越高越好,对于准确性也需要考虑,通用的召回率大概在`70%`,不论是`dify`还是`fastgpt`,对于生产场景,要求起码到`90%`的水平
2024-03-28 11:14:49 +08:00
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
# 如何提升召回率
2024-03-28 12:11:12 +08:00
2024-03-28 13:12:04 +08:00
首先是针对搜索query来说通过文本框的`打字输入`的角度,人类一定是倾向于偷懒,只输入关键词,这就是给表达真实意图带来的难度。
语音交互,才有可能让大家使用起来更舒服。
2024-03-28 12:59:20 +08:00
## 数据预处理
2024-03-28 12:32:12 +08:00
2024-03-28 12:59:20 +08:00
针对`LLM`模型来说,数据治理变的很重要,在数据切分的过程中,需要符合人的逻辑去`分词`。按照人的逻辑,例如:表格、章节、目录……
2024-03-28 12:32:12 +08:00
2024-03-28 12:59:20 +08:00
### 分词 chunk
2024-03-28 12:32:12 +08:00
2024-03-28 12:59:20 +08:00
`chunk`的`size`越大,召回越少。但是分的越精细,同样会损失上下文连贯性
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
# 意图分类
2024-03-28 12:32:12 +08:00
2024-03-28 12:59:20 +08:00
用户提问的内容,很短、缩写的情况,如何命中用户的`真实意图`。
2024-03-28 12:32:12 +08:00
2024-03-28 12:59:20 +08:00
## 缓存库
2024-03-28 12:32:12 +08:00
2024-03-28 12:59:20 +08:00
可以做一个缓存库,直接命中返回结构就行,不需要走`LLM`
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
## QA
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
处理成`QA`的格式,类似 `xxx企业的董事长是谁`,答案是必须正确的,上一代的客服系统必备。直接数据级别的匹配就行,召回一般都是比较准确的。
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
## 关键词+词典+迭代
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
成本非常低,可控。思路是帮用户模糊,先提取关键词,再结合词典的词条解释,让表达更加的领域话、专业化,再扔给大语言模型。
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
例如:某个提问`什么是RAG`,首先`RAG`对应的解释是:`增强向量检索的知识库`,那对应又引入的新的`关键词`,继续递归对新的`关键词`给出解释,通常迭代个`2-5轮`,就会有非常好的召回效果。字典里面通常会定义:同义词、类别、上下关系。私用飞书的话,内部标准自带一个`词典`应用,统一的业务领域的知识、语言体系。并且提供`api`从词典中提取关键字。直接通过关键字,把词条的内容读取出来。文本提取`关键词`也有很多开源模型能够提取,但是针对某些专业领域,一些开源不一定具备这样的提取能力。
2024-03-28 12:11:12 +08:00
2024-03-28 12:59:20 +08:00
针对某些场景例如`2021年的xxxx`,同样的`2022年的xxxx`也发生了,使用`embedding`容易给错误召回的,而`ES`的效果会更好。相当于通过从用户的问题中,捕捉关键词,然后通过这些`关键词`去库里召回。这样的`关键词`,可以不断的积累`字典`,针对关键词给解释。
2024-03-28 11:14:49 +08:00
2024-03-28 12:59:20 +08:00
但是针对有日期、数字类的一般效果会非常不好,可以考虑采用`nl2sql`的方案,使用`fine-tuning`,能够做到召回率`90%`,有专门的模型针对这块,例如微软的`RAT-SQL`模型。
2024-03-28 11:14:49 +08:00
2024-03-28 12:59:20 +08:00
针对`excel`类型的文件,直接把数据存到一张`宽表`中,不要跨表,降低复杂度。针对`nl2sql`的开源模型的能力基本都是`单表`,基本可以达到预期
## 知识图谱
难点在于构建知识图谱,例如`dify`在针对某些回答不满意的情况,可以对回复进行修正。这样的话会让下次回答更加可控
2024-03-28 11:14:49 +08:00
# embedding哪个算法好
2024-03-28 12:59:20 +08:00
目前openai的最好能够输入1536个输入输出结果能切分到700多个维度。针对模型来说重要性并不是很高。可以考虑替代方案。差距不会非常大从实际角度来说并不是很重要。
2024-03-28 11:14:49 +08:00
# 国内知识库方案哪些底座比较好
2024-03-28 12:59:20 +08:00
`qWen` 和 gpt 做过对齐,然后 `14B`、`72B int4` 效果就比较好,虽然比较慢,针对中文语料还是比较好的。
另一个就是 `yi-34b` 也还行。
2024-03-28 13:12:04 +08:00
# 如何设计大模型测试样本
从用户的提问当中选取50-100个场景作为`大模型`选择、`知识库`效果的测评的数据集,例如需要测`text2sql`的场景的模型效果,首先就是要找到哪些查询的频次最高。
# RAG的发展方向
2024-03-28 13:54:22 +08:00
1. 知识库作为专业领域的基座,大模型一定是无法覆盖的
2. 从用户的角度来说大厂商可能会说服开发者去接入自家agent贡献领域知识
3. 逐渐变成 Agent 场景下的底层设施,有清晰地 SOP目标明确