RAG知识库召回率
通用的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的发展方向
- 知识库作为专业领域的基座，大模型一定是无法覆盖的
- 从用户的角度来说，大厂商可能会说服开发者去接入自家agent，贡献领域知识
- 逐渐变成 Agent 场景下的底层设施，有清晰地 SOP，目标明确
重拾纯粹的写作