Lyzr 如何通过 Qdrant 大幅提升 AI Agent 性能
Daniel Azoulai
·April 15, 2025
Lyzr 如何通过 Qdrant 大幅提升 AI Agent 性能
扩展智能 Agent：Lyzr 如何通过 Qdrant 大幅提升性能
随着 AI Agent 能力越来越强且日益普及，其背后的基础设施必须随之发展，以应对不断增长的并发量、低延迟需求和持续扩大的知识库。在 Lyzr Agent Studio（已有 100 多个 Agent 部署到不同行业）中，这些挑战迅速且大规模地出现。
当他们现有的向量数据库基础设施开始在压力下不堪重负时，工程团队需要一个不仅仅是跟上步伐，而是能够加速前进的解决方案。
他们就是这样重新思考其技术栈，并采用 Qdrant 作为实现快速、可扩展 Agent 性能的基础。
早期技术栈选择的扩展限制
Lyzr 的架构使用了 Weaviate，并对 Pinecone 进行了额外的基准测试。最初，这种设置对于开发和受控测试来说是足够好的。系统管理着大约 1,500 个向量条目，少量 Agent 以稳定的模式发出适度的查询负载。
初始设置
| 参数 | 详细信息 |
|---|---|
| 部署类型 | 单节点或小型集群（Weaviate 及其他向量数据库） |
| 嵌入模型 | Sentence-transformer（768 维度） |
| 并发 Agent 数 | 10 到 20 个知识搜索 Agent |
| 每个 Agent 的查询速率 | 每分钟 5-10 个查询 |
| 流量模式 | 稳定，无明显峰值 |
在这些条件下，两个数据库表现都足够好。查询延迟徘徊在 80 到 150 毫秒之间。索引操作在几个小时内完成。整体性能可预测且稳定。
但随着平台扩展—语料库更大、工作流更复杂以及并发量显著增加—这些系统开始出现问题。
增长带来延迟、超时和资源瓶颈
一旦知识库超过 2,500 条目且在线 Agent 并发数超过 100，平台就开始承受压力。
查询延迟增加了近 4 倍，达到 300-500 毫秒。在高峰使用期间，Agent 有时会因等待向量结果而超时，这影响了下游决策逻辑。索引操作也变慢了，消耗了过多的 CPU 和内存，并在数据更新期间引入了瓶颈。
这些问题在生产环境中造成了真正的摩擦—并明确表明需要一个更具可扩展性、更高性能的向量数据库。
替代向量数据库评估
随着数据量增长和 Agent 并发量上升，Lyzr 需要一个更具可扩展性和效率的向量数据库。
他们需要一种能够处理更大负载同时保持快速响应时间和减少运营开销的方案。他们根据以下标准评估了替代方案：
| 标准 | 重点领域 | 对系统的影响 |
|---|---|---|
| 可扩展性与分布式计算 | 水平扩展，集群 | 支持不断增长的数据集和高 Agent 并发量 |
| 索引性能 | 摄取速度，更新效率 | 减少停机时间并实现更快的批量数据更新 |
| 查询延迟与吞吐量 | 负载下的搜索响应 | 确保 Agent 保持快速、实时的响应 |
| 一致性与可靠性 | 处理并发与故障 | 避免高峰使用期间的超时和查询失败 |
| 资源效率 | CPU、内存和存储使用情况 | 在扩展工作负载的同时优化基础设施成本 |
| 基准测试结果 | 实际负载模拟 | 验证在 >1,000 QPM 负载下的持续性能 |
Qdrant 将查询速度提升 >90%，索引速度快 2 倍，并降低了 30% 的基础设施成本。
这一转变伴随 Qdrant 的到来，它在每个关键指标上都迅速超出了预期。
使用 Qdrant 后，查询延迟降至仅 20–50 毫秒，相比 Weaviate 和 Pinecone 提升了 >90%。即使有数百个并发 Agent 每分钟生成超过 1,000 个查询，性能仍然保持一致。
索引操作显著改善。大型数据集的摄取时间快了 2 倍，且系统完成这些操作所需的计算和内存资源大大减少。这使得团队能够将基础设施成本降低约 30%。
Qdrant 还表现出更高的一致性。虽然 Weaviate 和 Pinecone 在扩展时都遇到了性能下降，但 Qdrant 在每分钟 1,000+ 查询下保持稳定—支持 100 多个并发 Agent，没有出现延迟尖峰或减速。最值得注意的是，Lyzr 在分布式 Agent 中维持了每秒超过 250 个查询的吞吐量，同时没有牺牲速度或稳定性。
| 指标 | Weaviate | Pinecone | Qdrant |
|---|---|---|---|
| 100 Agent 并发下的平均查询延迟 (ms) | 300-500 | 250-450 | 20-50 (P99) |
| 索引时间（小时）（2,500+ 条目） | ~3 | ~2.5 | ~1.5 |
| 查询吞吐量 (QPS) | ~80 | ~100 | >250 |
| 资源利用率（CPU/内存） | 高 | 中高 | 中低 |
| 水平可扩展性 | 中等 | 中等 | 高可扩展性 |
Qdrant 基于 HNSW 的索引技术使得系统能够在不停机或无需重新索引的情况下处理实时更新—消除了先前设置中最大的摩擦源之一。
用例聚焦：NTT Data 提升检索准确性
为 NTT Data 构建的一个部署专注于自动化 IT 变更请求工作流。该 Agent 最初运行在 Azure 的 Cosmos DB 上。虽然集成很顺畅，但向量搜索性能有限。索引精度不足，且随着数据量增长，系统难以呈现相关结果。
迁移到 Qdrant 后，差异立竿见影。检索准确性大幅提高，即使对于长尾查询也是如此。系统在并发负载下保持高响应性，并且水平扩展变得更简单—确保随着项目需求的演变保持一致的性能。
用例聚焦：NPD 支持 Agent 的准确、低延迟检索
另一个例子涉及 NPD，他们在六个网站上部署了面向客户的 Agent。这些 Agent 的任务是回答产品问题，并根据动态的、全站范围的知识库引导用户到正确的 URL。
Qdrant 的向量搜索实现了跨越数千个条目的准确、低延迟检索。即使在不断增加的用户流量下，平台也提供了稳定的性能，消除了先前解决方案遇到的延迟峰值。
总结
Lyzr 的经验教训很明确：生产级的 AI 平台需要生产级的向量数据库。
Qdrant 满足了这一需求。它让 Lyzr 大幅降低了延迟，扩展了查询吞吐量，简化了数据摄取，并降低了基础设施成本—所有这些同时保持了大规模下的系统稳定性。
随着 AI 生态系统的发展，向量数据库的性能将越来越决定 Agent 本身的性能。有了 Qdrant，Lyzr 获得了所需的基础设施，使其 Agent 即使在实际生产负载下也能保持快速、智能和可靠。
想了解 Lyzr Agent Studio 和 Qdrant 如何在您的技术栈中工作吗？
探索 Lyzr Agent Studio 或了解更多关于 Qdrant 的信息。
