blog-hexo/source/_posts/AI/rag.md
2024-03-28 13:54:22 +08:00

76 lines
4.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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