聊聊大模型 RAG 探索之路的血泪史，一周出Demo，半年用不好

大家好，今天我们来继续看看 RAG 落地的一些有趣的事儿，从技术社群早上的讨论开始，喜欢技术交流的可以文末加入我们

在这里插入图片描述

一、从一周出Demo、半年用不好说起

最近读了读2024-傅盛开年AI大课，其中有讲到RAG环节，三张片子比较有趣。

首先，用检索的方法配合大模型进行任务处理，可以很好的使用企业数据进行知识问答

这是继是当前为大家所熟知的RAG问答范式了。

其次，RAG开源框架很多，可现实很骨感

片子里的那句话说的很现实，一周出Demo，半年用不好

例如，目前已经开源的RAG框架包括12种【还不全面】，其中，排在前5的为大家所熟知：

1）LangChain： https://github.com/langchain-ai/langchain/

2）QAnything： https://github.com/netease-youdao/QAnything/tree/master

3）LlamaIndex： https://github.com/run-llama/llama_index/

4）langchainchat： https://github.com/chatchat-space/Langchain-Chatchat/releases/tag/v0.2.8

5) FastGPT ：https://github.com/labring/FastGPT

6）langchain4j ：https://github.com/langchain4j/langchain4j

7）Unstructured ：https://github.com/Unstructured-IO/unstructured

8）GPT-RAG ：https://github.com/Azure/GPT-RAG

9）Quivr ：https://github.com/StanGirard/quivr

10）Dify ：https://github.com/langgenius/dify

11）Verba ：https://github.com/weaviate/Verba

12）danswer：https://github.com/danswer-ai/danswer

最后，给出的高级套件，其中涉及到知识预处理、语义理解和改写、混合检索引擎、自动化质量评估体系、微调效果校准等多个例子。

二、现实实践优化探索与真实反馈

最近技术社群，一个小伙伴分享了一个工作《RAG探索之路的血泪史及曙光》，读了一下，讲的也很不错，推荐给大家读一读。

agent的技术发展流程：

朴素RAG的实现方式：

针对文本切割的一些经验：

此外，在chatglm金融问答比赛中的一些方案

在总结侧，可以同时结合正则、关键词抽取、文档问答、ICL、分块文本信息加入标题等，提升效果。

当然，方案是方案，其中一些有趣的讨论：

Q:我对于RAG相当没有信心。两个问题实在让我跪了：1）Retrieval明明是对的。但是LLM根据Retrieval结果回答问题出错。睁眼说瞎话的几率还是明显大于用户可以接收的概率（用户一般只能接受0.1%的错误率）;2）多跳逻辑无法通过Retrieval来做。比如查询Elon musk的兄弟叫什么名字，可能资料里只有Elon的妈妈是谁，Elon妈妈生了几个孩子。需要合成这个逻辑。优化prompt template+使用GPT4+使用CoT+使用reference generation+使用NLI，都没办法让错误率到1%以下。还是会偶尔胡编……

A: reasoning 还是有存在价值的，用 llm 推理是一条路径。不过也不唯一。好问题。第一个我们遇到过，最后通过优化 prompt template 和自定义答复模板解决；第二个建议试试用graph database 用来召回，特别适合解决多度和多跳关系。rag 使用 embedding 我只能说局限太大。

Q:第二个问题，不是graph能解决的。我刚才举的例子能用graph。实际上没法用Graph的例子海量。比如一些客服机器人在回答优惠券的组合使用的问题。

Q:提到的普通文本上下文检索优化中转为html方式后优化检索的方式我非常感兴趣，请问您知道是否有这方面的论文或者公开数据集吗？

A: 数据源有以下几种形式：Markdown。直接使用 Python-Markdown转化到 Html。pdf。可以找相关库转化为 Markdown，再转化为 Html，有些包也支持直接转。Html。拿来用即可。关于 Html 检索，是我自己实现的逻辑，主要阶段有两个：分片入库。

主要思路是，识别 html 中的 header，paragraph和 ol，ul 等标记。并将其转化为元数据，连同 embedding 的结果一同保存到vector store 中。

元数据应该包含：分片来自的源文件分片 id，应该符合源文件中出现的原始顺序递增。这个挺重要，会用于后面上下文检索。分片的 html tag，特别是需要通过 header 体现自己隶属于哪个层级。

检索。如果命中某个分片，则获取分片的元数据。然后根据所属的层级信息进行处理上下文补全：vector store 中当前层级的所有分片都找到。这里就不是基于 vector similarity 检索了，一个小技巧是将层级直接体现在字段中，按字段直接索引。如果发送给 llm context 还有剩余，可以再找兄弟平行层级；如果还有剩余可以找父层级。