为什么多代理RAG管道在生产数据库上卡顿（以及拯救我们的架构）

Reddit r/AI_Agents 新闻
multi-agent rag production latency async-processing architecture ai-agents

摘要

文章讨论了多代理RAG管道在生产中因同步工具调用和上下文膨胀而导致高延迟的原因，并提出了微代理、使用Redis缓存和异步处理等解决方案来提高性能。

当你演示一个AI代理查询一个只有50个PDF的单个向量数据库时，性能感觉是即时的。但当你将代理部署到具有混合搜索（pgvector + Elastic）、遗留SQL数据库和并行工具调用的实时企业环境中时，延迟会急剧上升。在我们最近的构建中，用户每次查询要等待18-25秒，因为我们的主要协调代理试图一次性做所有事情：解析用户请求、查询3个不同的API、清理上下文并生成响应。以下是我们遇到的问题以及如何修复基础设施：“智能代理”反模式：让一个代理访问10多个工具会使LLM困惑并使上下文长度增加四倍。我们将架构分解为微代理：一个路由代理、两个专门的检索代理和一个合成代理。上下文膨胀：我们没有将原始向量搜索结果直接倾倒到代理的上下文窗口中，而是在合成步骤之前在Redis中引入了严格的排名和去重层。未监控的工具调用：代理正在发出顺序阻塞API调用。我们使用Celery和Redis锁将工具执行移动到异步后台任务，以防止重复的数据库访问。工程现实检查：构建代理逻辑本身大约花了一周时间。设置缓存层、异步工作队列、连接池和CI/CD管道以处理非确定性代码几乎花了两个月。因为我们的内部团队完全专注于提示逻辑和数据模型，我们引入了来自Svitla Systems的嵌入式云和后端工程师来构建底层基础设施、Redis缓存层和部署管道。这再次强调了我们的一大教训：代理式AI主要是伪装成机器学习的高并发软件工程。你们是在同步处理代理工具调用，还是将执行推送到异步队列？你们如何在生产中处理整体管道延迟？
查看原文

相似文章