大模型一定程度改变了我们生活工作的思考方式，越来越多的个人和企业在思考如何将大模型应用到更加实际的生产生活。
1 LLM的问题
1.1 幻觉
LLM因为是一个预训练模型，它已有一些知识储备，我们提的问题跟他的知识储备不相符时，会产生一些幻觉问题，看上去正确的回答。
1.2 新鲜度
LLM预训练出来之后，不能感知到我们实时更新的工业数据，还有企业内部的一些私域数据。
1.3 数据安全
LLM训练依赖很多训练数据集，然后为了保证大语言模型的效果更好，训练集的质量及数据量越多，对LLM的训练最终效果更好，但又期望LLM帮解决一些垂类问题，又希望在数据安全有些防范，如企业内部敏感数据不能暴露出去，让公有的LLM去进行训练。
2 RAG是啥？
为解决LLM刚提到问题，提出RAG，将企业内部私域数据及实时更新的一些公域数据，通过一些处理后，变成可进行相似性搜索的向量数据，然后存储到向量数据库。
和LLM交互时，用户提问。先在我们的相同数据库中进行相似性检索，检索与提问相关的知识内容，检索后交给LLM，连同用户的提问一起让 LLM 去生成回复。
RAG帮助我们个人及用户去把企业内部的一些知识数据，很快构建出一个庞大知识库，然后结合目前已有LLM能力，可快速制作智能问答机器人应用。
小结
为LLM提供来自外部知识源的额外信息的概念。这允许它们生成更准确和有上下文的答案，同时减少幻觉
- 检索：外部相似搜索
- 增强：提示词更新
- 生成：更详细的提示词输入LLM
2 RAG应用咋构建？
使用到RAG的这条链路之后，用户先去构建好的知识库，即向量数据库里进行相似性检索，再带出一部分的知识知识文档。这部分知识文档会跟用户的query结合。
然后通过prompt技术组装成一个最终完成的一个输入给到LLM，让LLM回复。
最关键就是知识库生成这步，因为主要涉及把我们的知识文档去做内容提取及拆分。还要进行量化，入库。
2.1 RAG步骤
知识切片成Chunk
向量化Chunk入库
前两步都是去知识库生成。
Query检索知识Chunk
构建Prompts
调用LLM生成回答
后三步都是知识库生成后，在检索方面需要做的。
2.2 基于Langchain构建 RAG 应用
Langchain中RAG的实现：
各种文档 - 各种 loader - 文本切片 - 嵌入向量化 - 向量存储 - 各种检索链。
设计思想
把那五步拆成不同组件，然后由不同节点做相应处理。让用户去编写自己的业务逻辑的代码，然后把这整个过程串起。
优势
- 可快速构建一个demo，帮助开发者去理解RAG应用
- 庞大社区支持，如一些插件或它的一个版本更新迭代都很快
痛点
本质上通用性很强。为保证强通用性，效果层面不一定做到最好，需企业或个人投入较大精力，把整体的RAG在召回层的效果提升到最佳。
3 bad case
构建整个RAG应用过程中会遇到的一些问题和解决方案。
3.1 拒答
用户提问：请问A产品分析报告多久分析一次？
召回的相关知识：A产品的分析报告信息近30天的数据分析结果。
原因是我们用户的问题，在相关知识中没明确提到，只是有一定相似度。但跟我们用户问题不直接相关。这样的相关知识以及用户的问题。组装后交给LLM回答，本质上是人为制造干扰。
对此，有个工程化实践叫拒答。
3.2 消歧
提问：A课程适合多大年龄小孩。
知识库召回两条数据，其中一条是期望的一个知识，就在A课程文档。会有一段话跟提问相关，但还会召回其他的一个干扰知识。如其他文档里一些内容，像该课程适合3到7岁的小孩，适合6到8岁的女孩。这种知识内容也会被召回。
期望的召回内容携带一部分干扰信息，这干扰信息没有A课程这个关键字，然后也不会召回。在这两个知识内容交给大源模型处理，他也无法理解哪个字内容正确。
更希望在召回层，就有较好手段处理。工程化实践里，会对用户进行改写，增强query的一个效果。
也用到类似BM25这种倒排索引，提升关键字的权重。如干扰知识里没生成这个关键字，其相似度分数较低，就不会召回。
3.3 分类
可能有用户的提问类似：服务器连接不上，应当如何解决？
现在给知识库里面注入的文档，都是类似连接服务器应该有哪些步骤。
将这些知识内容召回，交给LLM也能引导用户。但不能直切要害，用户更希望，我现在连接不上，有啥排查手段。更好的还是通过提供一些专门QA文档，增强整个知识召回内容准确性。
用户可能问一些跟他实例相关的问题。如CPU占用变高或内存变高，实际响应可能是技术支持文档里的一些处理方案，就是我现在内存变更咋处理。但用户想知道为啥变高。有一个意图识别模型，判断用户他想要的问题具体是一个什么类的，需不需要用到RAG，也会判断他是否需要用到诊断引擎。类似问题2，需要用到诊断引擎，那我们会调用其他RAG无关的诊断相关技术为用户排查问题，并且给用户反馈一个结果。
4 咋提升RAG应用效果？
$$ 整体效果 = 文档处理效果 * Embedding效果 * Retrieval效果 * LLM效果 $$
demo易，但上手难，主要因为LangChain、LLamIndex框架盛行。很快接入就是初级的一个状态，可能只做到35%。
想提高整体一个准确率，在拆分那儿会拆更合理、提取内容时，把整个内容提取更好。做向量化时，去选择我们的向量，更好的一个embedding模型。
最终跟LLM交流时，选择效果更好的LLM，然后把这效果给提升到更高。
但60%的准确率还是达不到生产期望。希望准确率90%，在RAG应用构建各阶段，都有很多工程化手段。
目前RAG整体应用在界内的比较关注的一个地方就是在召回。因为涉及知识文档，思考方向：
- 优先保护保证这个召回率
- 优先保证这个精度
RAG召回是希望获得更多和用户提问相关的知识内容，还是说我只需要更关键的知识内容排在最顶。某云厂商相关数据库AI套件选择前路，期望召回更多跟用户相关的提问的内容。
精度尽量保证召回内容在top3、top5位置出现，因为召回的一些内容确实有一部分干扰信息。但目前LLM能力尚可，对这种干扰性信息的排除能力较好。
