8大策略，让你的AI应用性能飞上天！| 抄作业啦

编者按：关于什么是RAG（检索增强生成），我们在往期的文章里介绍过，是目前提升AI回复准确性疗效最好的技术路径：

这时候我们就要借助检索增强生成技术（Retrieval Augmented Generation，RAG）的力量了，简单来讲，它是一种允许我们在基础模型外部检索数据，且把检索到的相关性数据注入到上下文中，以增强提示信息，确保响应的质量和准确性。

但也不得不说，用RAG构建系统体验犹如坐过山车——从0到1搭建一个AI知识库或ChatBot原型让人感到兴奋，可真要让它作业环境下运行到行云流水可太难了，简直要令人抓狂。（前者的话，像LangChain、LlamaIndex等框架、Zion之类的无代码AI搭建工具都做的到。）

从“能用”到“用得好”，中间就要发挥好“黑魔法”的力量了。简单讲，提到RAG性能优化的策略时，我们基本上都是在回答“找到最匹配的上下文”和“生成符合期待的回复”这两个问题。

就此，博主Matt Ambrogi刚好整理了一些实用套路，另外，为了大家更好地理解，我让ChatGPT帮忙给了场景示例，希望会有一些帮助。

数据清洗

RAG让LLM得以结合私有数据实现总结、提炼、创作、推理等目标。但私有数据的质量，会直接影响生成质量。比如，用来作为上下文的数据源如若存在“主旨不清、结构混乱，信息相互矛盾，数据冗余”等缺陷，都会影响检索的质量，简言之，找不到匹配度高的上下文，大模型就表现不佳。

如果你正在为公司产品的帮助文档构建一个AI机器人，却发现它运行得并不理想，那么首先需要审视的就是数据预处理的质量——这些主题是否被逻辑性地划分了？某些主题是集中在一个地方，还是散布在多个不同的地方？如果连你作为一个人类都难以轻松判断出要查看哪个文档，从而回答用户的常见问题，那么检索系统也同样无法做到。

这个过程非常简单，跟你以主题为轴心对文档合并同类项没有本质区别。我见过的一种更有创意的方法是，使用大型语言模型（LLM）来创建所有提供的文档的摘要。待到要检索的时候，先是对这些摘要进行搜索，在必要时才深入到细节中。——有些框架甚至整合了这种抽象化处理。

探索多元索引方式

在LlamaIndex和LangChain的世界里，索引是不可或缺的核心，也是检索系统的基石。通常来讲，RAG的实现方法涉及到嵌入（编者注：可理解为—词空间构建）和相似性搜索两大块内容。

简单来说，就是以某种逻辑把上下文数据切成块，作嵌入处理，当查询发生时，按照相似度定位与query相关的上下文就好了。

这个方法效率极高，但不是在所有场景下都行之有效。如果在电商场景下，很可能仅仅考虑基于关键词的索引就够了。

不过，索引方式的选择并非非此即彼，许多应用实际上采用的是混合方式。举个例子，针对某特定产品的查询，你可以使用基于关键词的索引；但切换到客服问答场景下，向量索引就更合适。

（编者注：比如我们前面在试验研报生成这个项目时，就同时用到了关键词索引、向量索引的方式等。其它的索引方式还包括树状索引、列表索引等等，在此不一一赘述了。）

文本分割思路意义重大

在构建RAG（检索增强生成）系统时，文本分割也是一项基本功。很多框架和工具都会把分割能力封装进去，用一个“自动分割”的按钮回应这个问题，让用户直接跳过思考这个问题。但实际上，分块的大小、分割逻辑很重要，你需要探索什么颗粒度最适合你的场景。

通常来说，小块通常能提高检索效率，但可能会因为缺乏足够的上下文而使生成质量受损。分块的方法有很多种，唯一不行的就是盲目地去做。（编者注：按字数分割、按自然段分割，按主题分割都是不一样的效果。）我有一组测试问题集，就这个问题做过实验。我用小、中、大三种不同的块大小分别遍历了每组数据一次，结果发现小块效果最佳。这就像科技界中的其他事物一样，没有固定的答案，关键在于你要敢于尝试，敢于探索，找到最适合自己的解决方案。

玩转基本提示语（base prompt）

以LlamaIndex本身为例，它使用的一个基本提示是这样的：

“下面是上下文信息。仅凭这些上下文信息而非先前知识（prior knowledge)，回答这个查询。”

你完全可以改写这个提示，甚至反着来——让大型语言模型（LLM）在找不到上下文中的好答案时，依赖它自己的知识（编者注：预训练的知识）。你还可以调整提示语，以指导它接受哪些类型的查询，比如，指示它如何回答主观性问题。至少，修改提示语让LLM了解它的工作定位是有帮助的。例如：

“你是一个客户支持代理。你的设计目的是在提供事实信息的同时尽可能地提供帮助。你应该保持友好，但不能像个话唠那样。下面是上下文信息。仅凭这些上下文信息而非先前知识，回答这个查询。”

这其实就像在技术的海洋中航行，你需要不断地尝试和调整，找到最适合你自己的航线。在这个过程中，保持创造性和灵活性是关键，这样你才能充分利用工具，达到最期待效果。

元数据过滤

提高检索效率的一个非常有效的策略是给文本块（chunk）添加元数据，然后利用这些元数据来处理结果。日期就是一个常见的元数据标签，因为它允许你按照最新性(recency)来过滤信息。想象一下，如果你正在构建一个允许用户查询邮件历史的应用。更近期的邮件很可能更加相关。但我们并不知道从嵌入的角度来看，这些邮件是否与用户的查询最为相似。这引出了构建RAG时需要牢记的一个普遍概念：相似≠相关。

你可以将每封邮件的日期添加到其元数据中，然后在检索过程中优先考虑最近的上下文。LlamaIndex内置了类似节点后处理器，专门用于此类任务。这就像是给你的检索系统增加了一副眼镜，使它在浩瀚的数据海洋中更加精准地找到你需要的东西。在这个过程中，关键是要灵活运用各种工具和策略，不断试验和优化，最终构建出一个既高效又精准的检索系统。

基于查询匹配索引路径（query routing）

在构建检索系统时，多个索引并行通常行之有效的。这样，当查询发生时，你可以稍加调度，将它们与最合适的索引路径作匹配。

例如，你可能会有一个处理摘要问题的索引，一个处理具体问题的索引，还有一个擅长处理与日期相关的问题的索引。相较于试图优化一个索引来应对所有查询，引入调度机制收效更高。

另一个应用场景是，如第二小节所讨论的，将某些查询引导至基于关键词的索引。一旦你构建了你的索引，你只需要用文本定义每个索引的用途。然后在查询时，大型语言模型（LLM）将选择合适的选项。

这就像是为你的检索系统打造一个多功能的仪表板，每个按钮都有其特定的功能和用途。通过精心设计和布局，你可以确保在面对各种不同的查询时，总有一个最适合的工具可用。这不仅提高了效率，也确保了查询结果的质量和相关性。

重排（Reranking）

重新排序（reranking）是解决相似性与相关性冲突的一个有效方案。在这种方法中，你的检索系统像往常一样获取上下文的顶层节点。然后，它会根据相关性重新对它们进行排序。无论你的使用场景如何，如果你在使用RAG（检索增强生成），你应该尝试重新排序，看看它是否能改善你的系统。

这就像是给你的检索系统加入了一个智能的调节器。虽然原始的检索结果可能就像是一堆原料，但通过重新排序，你可以将它们转化为更加精准和有用的信息。在技术的世界里，不断实验和优化总是关键。

“查询（query）文本”的预处理

基础提示本身对用户的查询请求有一定约束，不过有时候，进一步改动也是挺有必要的。这里有几个做法：

措辞调整（rephrasing）：如果系统没有找到和查询相关的上下文，可以让大型语言模型（LLM）重新表述这个查询，然后再试一次。在人类眼里看似相似的两个问题，在嵌入空间里可能差别很大。

HyDE策略：HyDE会拿一个查询，生成一个假设性的回答，然后用这两个信息进行嵌入查找。研究显示，这种做法能显著提高效果。

子查询：LLM在处理复杂查询时，把问题拆分成多个小问题往往效果更好。你可以把这个方法融入到RAG系统里，让一个查询分解成多个小问题。

这就像给你的检索系统加装了一个智能变速器。通过巧妙的查询转换设计，你的系统不仅能更准确地把握用户需求，还能在海量信息中更有效地找到最相关的答案。在信息爆炸的今天，能够精准捕捉并理解用户意图的技术，绝对值得深入探索和优化。

关于Zion

Zion 是一款强大的无代码开发平台，让创建简单应用更迅速、开发复杂系统更经济、成为数字化专家更容易。我们致力于提供一个全方位的无代码云开发环境，帮助您轻松完成页面设计、业务流程和数据模型的可视化，大幅降低参与跨平台应用开发的技术难度。设计完毕后，您可以便捷地进行代码生成、应用部署和上线发布，实现从概念到交付的全自动化。简而言之，Zion 旨在使技术创新更加触手可及，帮助您快速实现数字化转型。