共计 3690 个字符，预计需要花费 10 分钟才能阅读完成。
近日，bilibili 出名科技 UP 主“Ele 实验室”公布了一个视频，题目为“当我开发出史料检索 RAG 利用，野史怪又该如何应答？”。
视频间断三天被平台打上“热门”标签，并迅速登上科技板块全区排行榜前列。截至目前，视频的观看量近 70 万，评论区探讨异样强烈，很多技术爱好者、开发者都在评论区中提出了技术实现上的问题。作为该视频的技术支持方，Zilliz 最分明其中的技术细节，明天咱们就和大家聊聊这个「B 站最火 RAG 视频中的利用——Mr History 是如何炼成的」。
01.Mr History RAG 利用的背景介绍
经验了大型语言模型（LLM）疾速倒退的 2023 年，业内越来越多地探讨起了检索加强生成（Retrieval-Augmented Generation，简称 RAG）技术，这个技术要害之处在于它联合了两个重要的元素：检索和生成。首先，它会通过搜寻内部信息源（比方网页或数据库）来收集与问题相干的信息。而后，它会将这些信息奇妙地融入到它的答复中，生成一个更加精确、贴近理论状况的回应。
这意味着无论你提出的问题是对于最新新闻、特定畛域常识还是其余任何内容，RAG 都能提供更全面、有深度的答案。RAG 探讨比拟多的利用场景次要是在企业外部常识问答，但作为一个技术，咱们想在它与人文的交叉点做一些乏味的摸索——应用 RAG 进行史料答复的摸索，一是摸索以后技术在具体的实际中产生的利用场景，二是想看一下 RAG 在利用时会遇到的具体挑战。
二十四史是从黄帝记录到明代崇祯十七年（1644）的二十四部史书的合称，如果能做一个对于二十四史的问答我的项目也是一个很乏味的事，毕竟喜爱历史的敌人也往往对一些史实晓得个粗略，想去理解一些更加具体的细节。有一些敌人会说去找对应的人物传就好了，然而在纪传体中人物传记并不是主人公的全貌，他的事迹很有可能作为主角扩散在别人的传记中。所以 RAG 的用途天然就是依据发问找到分布在全书中的线索，推理出问题的答案。
先看了一下二十四史的数据，就发现了几个很重要的特点:
- 文言文十分喜爱省略主语，比方“高贵乡公即尊位，赐爵关内侯。”这句话就会把配角钟会给漏掉。
- 文言文通常只称说名，比方“表念同为皇族之情“，从这句话中就须要模型能推理出表是刘表，从而被召回。
- 古代的 embedding 模型大部分都在对齐白话文与白话文，白话文与文言文不足对齐训练。
通过以上的初步剖析，咱们决定先从白话文动手。指标和办法十分的明确，目前社区曾经有了大量的 RAG 利用的教程，应用 LlamaIndex（齐全能够是其余的 RAG 框架，比方 LangChain 等），将文档导入向量数据库 Milvus（https://milvus.io/）或者 Zilliz Cloud（https://zilliz.com.cn/cloud），接入 ChatGPT 的 API 作为 query_engine，就实现了一个教科书式的对于史料的 RAG 利用，后果如下：
显然，目前的 RAG 零碎给出了一个出其不意的答案。在实现了一个规范的 RAG 后，咱们对最终出现的后果并不称心。当然，对 RAG 的品质评测通常是一个很简单的系统工程，尤其是在不足数据标注的状况下，所以咱们采纳的是针对个例具体分析的办法来进行调优，依据“奥卡姆剃刀”法令，如果咱们针对的个例的调优是简洁优雅的状况下，那针对大部分其余案例都会带来改善，咱们先试着把这个问题给解决好。
02. 进步 embedding 对于细节的捕获能力
在 RAG 中，文本首先会依据 chunksize 来进行切分，每一个 chunk 计算出向量来不便检索。典型的历史问题通常都是波及到（人物）(工夫)（地点）的行为，所以咱们心愿找回的语料内容可能与问题在这些点的语义重合度较高。
咱们应用的 embedding 模型是在开源社区中比拟热门的（BAAI/bge-base-zh-v1.5），它在大规模的中文数据集上经过训练，可能在成果和性能上获得一个不错的均衡，须要剖析的第一个起因可能是因为 chunksize 设置的过大，导致 embedding 对于细节刻画得不是很好。所以咱们采取了 LLamaIndex 中的 SentenceWindowNode，按句来进行 embedding 的计算，然而最初返回给 LLM 来进行浏览的文章的确蕴含了更多的上下文的一个窗口，这样能够让 LLM 进行信息剖析时可能找到更多的线索。当初应用向量检索的确发现对于细节的相关性有了很好的改善，然而也蕴含了一些对于关羽的其余内容甚至是和关羽的无关内容。
03. 重排序进一步提高召回文本的相关性
即便咱们通过 SentenceWindowNode 很好地进步了 embedding 对于细节的捕获水平，仍然会呈现不现实的排序。这可能与 embedding 模型是在大规模通用语料上训练失去的无关。想要对此的改善通常是人工标注数据进行 embedding 模型的 finetune，然而咱们心愿应用更加通用的模型来进行解决。
咱们应用 cross-encoder 形式设计的 rerank 模型（BAAI/bge-reranker-large）来进行文本相关性的计算，rerank 模型通过输出（问题，文档片段）间接生成分数，所以能够同时接管到二者的信息。用比喻来说，embedding 召回就是看简历留下大抵印象，rerank 就是一对一的进行面试，所以通常的状况下都能进一步提高后果的相干水平。通过这个技术，咱们找到了所有关羽杀死别人的文本，当然也蕴含了一些关羽被吴国杀死的信息。
04. 大模型的抉择
在咱们提供了尽可能高质量的史料信息后，就到了大模型最初的浏览了解阶段，咱们一开始采纳的是 gpt-35-turbo-1106，发现在这个问题上体现并不是很现实（可能是因为语料都是比拟碎片化的段落），十分呈现容易幻觉。在通过了肯定的 prompt 工程后（例如：通知它须要忠诚地参考原文），但最终还是无奈达到期待的成果。刚好 OpenAI 年底公布了更便宜的 gpt4 版本 gpt4-turbo-1205, 无论是对于格局的要求，以及对于幻觉的克服，都有了显著的晋升，咱们抉择了 gpt4-turbo 作为最初的 reader。
05. 为段落加上援用
作为一个史料的 RAG 利用，咱们心愿可能在给出蕴含常识的原文同时可能给出它在原文中的具体传记名，因为语料中能够通过格局辨别进去传记名和注释，所以通过简略的一些规定就能够提取进去每个段落对应的传记名，并且通过将其作为文本的 metadata。咱们能够对 metadata 进行管制，只心愿将传记名通知给 LLM 让其来进行出处的标记，而不心愿在 embedding 和 rerank 阶段带来影响，就能够管制它在只在 LLM 的 prompt 中出现进去。
06. 总结
当初，咱们就能够产生出一个可能初步合乎预期的 RAG 零碎了，这个 RAG 可能捕捉到细粒度的相关性高的史料，并且能够精确地援用其对应出处。同时更强的 LLM 模型也能够从繁冗的史料片段中提取到对问题答复有帮忙的常识。
咱们在这个我的项目中首先剖析了数据的特点，采取了更加适宜现有模型的文本计划，接下来所采纳的晋升技术次要是尽可能地进步召回文本的与问题的相关性，并且通过让 embedding 的文本与展现给 LLM 的文本不同的技巧来达到进步检索精度，领有足够上下文，获取援用信息的目标。咱们尽可能地采取了通用的技巧，针对历史 RAG 的场景，咱们也能够去辨认“人名”而后进行片段的过滤解决，或者额定剖析一下产生的朝代，依据朝代信息来将召回片段进行过滤。
归根结底就是当给出一个 query 后，怎么尽可能地找到最相干的常识，不节约 LLM 中的 prompt 空间。话说到这里，必须要附上我的项目地址供感兴趣的小伙伴参考呀，欢送 Clone 体验：https://github.com/wxywb/history_rag。
此外，在社区的应用过程中，也有不懂编程的小伙伴在应用 history_rag 遇 到了算力有余，以及部署数据库的问题。目前，history_rag 除了须要本地部署数据库和向量模型的 Milvus 模式外，还反对了 Zilliz Pipeline 的模式。
Zilliz Pipeline 是 Zilliz Cloud 推出的一项云托管服务，能够将文本转换为向量插入到云数据库中。这样搭配着其余在云端部署的 LLM 能够使用户不须要高性能的算力设施，以及解脱简单的数据库治理。同时这个计划也能够与具体的 LLM 解耦，方便使用各种 LLM，社区也奉献了通义千问的计划能够一键切换。
所以如果你对历史十分感兴趣，那么你不须要会编程或计算机，间接来 GitHub 跟着文档走一遍就好。
相干链接：
- LlamaIndex:https://github.com/run-llama/llama_index
- Milvus:https://github.com/milvus-io/milvus
- Zilliz Cloud Pipelines: https://zilliz.com/zilliz-cloud-pipelines
- history_rag:https://github.com/wxywb/history_rag
本文由 mdnice 多平台公布
