将 RAG 从概念验证（POC）扩展到生产

原文towardsdatascience.com/scaling-rag-from-poc-to-production-31bd45d195c8?sourcecollection_archive---------0-----------------------#2024-10-07启动和扩展的常见挑战与架构组件https://medium.com/bhagatanurag03?sourcepost_page---byline--31bd45d195c8--------------------------------https://towardsdatascience.com/?sourcepost_page---byline--31bd45d195c8-------------------------------- Anurag Bhagat·发布于Towards Data Science ·阅读时长 7 分钟·2024 年 10 月 7 日–https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ee14c78dc3f1d708f7e587a83fe8d0db.png来源在 AIOpenAI 的 Dall-E 模型的帮助下生成1. 引言1.1. RAG 概述那些沉浸于生成性 AI 及其在个人生产力应用之外的大规模应用的朋友们可能已经接触过检索增强生成RAG的概念。RAG 架构由两个关键组件组成——检索组件它使用向量数据库对大量文档进行基于索引的搜索然后将其传送给大语言模型LLM以生成基于提示中更丰富上下文的有依据的响应。无论你是在构建面向客户的聊天机器人以回答重复性问题并减少客户服务代表的工作负担还是在为工程师构建一款协同助手帮助他们一步步浏览复杂的用户手册RAG 已经成为大语言模型LLMs应用的关键原型。这使得 LLM 能够根据成千上万的文档的事实基础提供上下文相关的响应从而减少幻觉现象并提高基于 LLM 的应用的可靠性。1.2. 为什么要从概念验证POC扩展到生产如果你在问这个问题我可能会挑战你回答如果没有打算将其投入生产为什么要构建一个 POC概念验证“试点地狱”是组织在开始实验时常见的风险之后却陷入了实验模式。请记住POC 是昂贵的真正的价值实现只有在进入生产并按规模执行时才会发生——无论是释放资源、提高效率还是创造额外的收入流。2. 扩展 RAG 的关键挑战2.1. 性能RAG 中的性能挑战有很多种形式。检索速度通常不是主要挑战除非你的知识库有数百万份文档即便如此这个问题也可以通过搭建合适的基础设施来解决——当然我们也受到推理时间的限制。我们遇到的第二个性能问题是如何获取“正确”的文段以便传递给大语言模型LLM进行生成且要保证高精度和高召回率。检索过程越差LLM 的回应就越缺乏上下文相关性。2.2. 数据管理我们都听过那句古老的谚语“垃圾进垃圾出GIGO”。RAG 不过是我们手头的一组工具真正的价值来自于实际数据。由于 RAG 系统处理的是非结构化数据因此它有自己的一系列挑战包括但不限于——文档版本控制和格式转换例如从 PDF 到文本等等。2.3. 风险企业从试水到全面投入的最大犹豫之一是使用基于 AI 的系统可能带来的风险。尽管使用 RAG 可以显著减少幻觉现象但它们仍然存在非零的可能性。还有其他相关的风险包括偏见、毒性、合规性风险等这些风险可能带来长期的影响。2.4. 集成到现有工作流程中构建离线解决方案比较容易但引入最终用户的视角至关重要以确保解决方案不会让用户觉得负担重。没有用户愿意为了使用“新 AI 功能”而切换到另一个屏幕——用户希望 AI 功能能够内嵌到现有工作流程中这样技术就能成为一种辅助工具而不是日常工作中的干扰。2.5. 成本嗯这一点似乎很显而易见对吧组织正在实施生成式人工智能GenAI用例以便创造业务影响。如果实际收益低于我们的预期或者出现成本超支影响将大大减少甚至可能完全抵消。3. 扩展所需的架构组件如果我们只谈论挑战而不谈论“那么我们该怎么做”那就不公平了。你可以在架构堆栈中加入一些必要的组件以克服或减少我们上面提到的一些问题。3.1. 可扩展的向量数据库许多团队通常会首先使用开源向量数据库如ChromaDB因为它们易于使用和定制非常适合概念验证POC。然而它在大规模部署中可能会面临挑战。这时可扩展的向量数据库就发挥了作用例如PineconeWeaviateMilvus等这些数据库针对高维向量搜索进行了优化能够实现快速亚毫秒级、准确的检索即使数据集的大小增加到百万或十亿向量它们仍然能够高效运作因为它们使用近似最近邻搜索技术。这些向量数据库提供 API、插件和 SDK方便与现有工作流集成同时支持横向扩展。根据平台的不同可能需要探索Databricks或AWS提供的向量数据库。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/6f8562c4e112308a47a06f348db3715d.png来源借助 AIOpenAI 的 Dall-E 模型生成3.2. 缓存机制缓存的概念几乎与互联网的诞生一样久远可以追溯到20 世纪 60 年代。这个概念同样适用于生成型 AI——如果有大量查询可能达到数百万在客户服务功能中非常常见很可能许多查询是相同的或极为相似的。缓存技术可以避免向 LLM 发送请求如果可以从最近的缓存响应中返回结果这样不仅能减少成本还能提高常见查询的响应速度。这可以通过内存缓存如Redis或Memcached来实现针对较少的查询使用磁盘缓存或使用分布式缓存如 Redis 集群。一些模型提供商如 Anthropic提供提示缓存作为其 API 的一部分。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/eb99db871ae334a898f3493fc951fc01.png来源借助 AIOpenAI 的 Dall-E 模型生成3.3. 高级搜索技术虽然并非一个明确的架构组件但多种技术可以帮助提升搜索效率和准确性。以下是其中一些方法混合搜索与仅依赖语义搜索使用向量数据库或关键词搜索不同采用两者结合的方法来提升搜索效果。重新排序使用 LLM 或 SLM 计算查询与每个搜索结果的相关性得分并重新排序从而仅提取并分享最相关的结果。这对于复杂领域或有许多文档返回的领域尤其有用。一个例子是 Cohere’s Rerank。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/10211b4b3b6985b8800c7a4427794dc8.png来源通过 AIOpenAI 的 Dall-E 模型生成3.4. 负责任的人工智能层您的负责任人工智能模块必须设计用来减轻偏见确保透明度与您组织的伦理价值观对齐持续监控用户反馈并跟踪符合相关行业/功能的法规要求。方法有很多但从根本上来说必须通过编程启用并由人工监督。可以采用几种方式来实现预处理在用户查询发送到基础模型之前进行过滤。这可能包括检查偏见、有害内容、非预期用途等。后处理在结果从基础模型返回后向最终用户展示之前应用另一组检查。这些检查可以作为小型可重用模块启用您可以从外部提供商购买或者根据自己的需求进行构建/定制。组织通常采用的一种方式是使用精心设计的提示和基础模型来编排工作流程确保结果在通过所有检查之前不会呈现给最终用户。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/184aa917e7c7eebc06ae752d9ef78de8.png来源通过 AIOpenAI 的 Dall-E 模型生成3.5. API 网关API 网关可以发挥多种作用帮助管理成本以及负责任的人工智能的各个方面提供统一的接口与基础模型互动进行实验。帮助开发精细化的成本和使用情况视图按团队/用例/成本中心进行划分 — 包括速率限制、速度控制、配额管理作为负责任的人工智能层在请求/数据达到模型之前过滤掉不适当的请求/数据。启用审计追踪和访问控制https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/cb937658eacc1f107b854540ff8edb4e.png来源通过 AIOpenAI 的 Dall-E 模型生成4. 这样就够了吗还是我们需要更多当然不是。还有一些其他因素也需要考虑包括但不限于该用例是否在您的用例路线图中占据战略地位这使您能够获得领导支持并获得适当的投资以支持开发和维护。一个明确的评估标准用于衡量应用程序在准确性、成本、延迟和负责任的人工智能等维度上的表现。改善业务流程保持知识的最新性维护版本控制等。设计 RAG 系统时确保它仅在最终用户权限级别的基础上访问文档以防止未经授权的访问。使用设计思维将应用程序集成到最终用户的工作流程中。例如如果你正在构建一个通过 Confluence 作为知识库回答技术问题的机器人你是否应该构建一个独立的用户界面还是将其与 Teams/Slack/其他用户已经使用的应用程序集成5. 结论RAG 是一个典型的使用案例原型也是组织首次尝试实施的几个用例之一。从 POC 到生产环境的 RAG 扩展面临诸多挑战但通过精心的规划和执行许多挑战是可以克服的。其中一些可以通过在架构和技术上的战术性投资来解决而另一些则需要更好的战略方向和巧妙的规划。随着大语言模型LLM推理成本的不断下降无论是由于推理成本的降低还是开源模型的广泛采用许多新用例的成本壁垒可能不再是问题。本文中的所有观点仅代表作者个人意见并不代表对任何产品或服务的认可。