Chat with Wiki - WayToAGI

以下是关于 RAG 架构图和实现案例的相关内容： RAG 是当今大多数现代人工智能应用程序的标准架构。以 Sana 的企业搜索用例为例，其工作原理如下： 1. 应用程序加载和转换无结构文件（如 PDF、幻灯片、文本文件），跨越企业数据孤岛（如 Google Drive 和 Notion），通过数据预处理引擎（如 Unstructured）转换为 LLM 可查询格式。 2. 这些文件被“分块”成更小的文本块，以实现更精确的检索，并作为向量嵌入存储在数据库（如 Pinecone）中。 3. 当用户提出问题时，系统检索语义上最相关的上下文块，并将其折叠到“元提示”中，与检索到的信息一起馈送给 LLM。LLM 从检索到的上下文中合成答复返回给用户。在生产中，AI 应用程序具有更复杂的流程，包含数十甚至数百个检索步骤，通常具有“提示链”，不同类型的任务并行执行多个“提示链”，然后将结果综合在一起生成最终输出。随着 RAG 的发展，出现了自适应的检索（也被称作主动检索），其核心思想与 LLM Agent 相似。根据判断依据可分为 Promptbase 和 Tuningbase： 1. Promptbase：通过 Prompt Engineering 的方式让 LLM 对流程进行控制。典型实现案例是 FLARE，其核心思想是 LM 仅在缺乏所需知识时进行检索，以避免被动检索增强的 LM 中出现不必要或不适当的检索。FLARE 迭代地生成下一个临时句子，并检查是否包含低概率标记。如果是这样，系统将检索相关文档并重新生成句子。 2. Tuningbase：对 LLM 进行微调使其生成特殊的 token，以此来触发检索或生成。典型案例是 SelfRAG，具体步骤包括：给定输入提示和前面的生成结果，首先预测特殊 token“Retrieve”判断是否通过检索段落对继续的生成进行增强是有帮助；如果有帮助，调用检索模型，模型会生成一个 critique token 来评估检索段的相关性、下一个响应片段和一个批判令牌来评估响应片段中的信息是否得到了检索段的支持；最后，一个新的批判令牌评估响应的整体效用。模型会并行处理这些内容，并选择最佳结果作为最终的输出。此外，系统的内存是 LMM 的上下文窗口，存在架构限制，窗口越大推理越慢，同时模型会失焦，降低推理的准确度。前沿模型研发团队都力争做到吞吐量、速度还有准确度的最佳平衡。大模型应用领域常用的方法是 RAG，例如 Perplexity、面向企业知识库的 Glean 以及面向个人知识库的 Maimo 等应用。