北京
50个并发用户之后，吞吐量不再上升，延迟却开始指数级恶化。这是把 Hindsight 记忆系统接入一个日均处理 2K+ 对话的客服代理之前，必须先在压测里看清的一条线。
测试环境没有用玩具数据集。后端是本地 Ollama 跑的 llama3.2:3b，8K 上下文窗口；嵌入模型是 nomic-embed-text，输出 768 维向量；向量库用 ChromaDB 持久化模式，预置了 50K 条对话片段。压测工具是 Locust，50 个并发用户、10 分钟爬坡，硬件为 32GB 内存、Ryzen 9 5950X，不做 GPU 卸载。
工作负载模拟真实客服场景：用自然语言检索记忆（比如"客户上周投诉过账单错误"），取回最相关的 5 个对话片段，注入 LLM 提示词，然后测量从查询到首 token 的端到端延迟。
三个关键发现
- 吞吐在 50+ 用户处触顶。超过 50 个并发查询后，Ollama 单线程的嵌入生成成为瓶颈，吞吐收益走平，延迟却急剧劣化。
- 内存开销随向量数线性增长。ChromaDB 的内存索引大约每 1K 条嵌入占 10MB，50K 片段时基线内存为 520MB，这还没算查询负载。
- 压力下语义召回开始掉质量。到 75 个并发用户时，向量相似度搜索返回的匹配变差，召回率降到 0.79。原因是高写入吞吐下 ChromaDB 的 HNSW 索引重建出现争用。
生产集成与多提供商回退
生产侧用 FastAPI 做异步封装：查询记忆、拼接检索到的上下文、路由到 LLM 网关做 token 流式输出。压测客户端用 Locust 模拟用户，每次请求带一条真实风格的查询，例如"客户报告发票 #4721 支付失败"。
在多提供商路由的延迟对比中，直连 Ollama 的基线首 token 时间为 340ms；经 B-Lost 中继网关并启用回退路由后为 285ms，减少了 55ms。做法是在多个区域 Ollama 实例间做负载均衡，本地容量饱和时回退到云端提供商。10K 次请求中 token 截断事件为 0。
经济性阈值
Hindsight 在架构上划算，有三个前提：
- 对话量超过每天 500 次。低于这个量，简单的上下文窗口管理就够了；高于它，语义检索比反复发送完整对话历史更便宜。
- 代理生命周期跨多个会话。如果对话是无状态或单轮的，嵌入开销会超过收益。带周级上下文窗口的持久代理能看到 40% 的 token 成本下降。
- 本地推理可行。Hindsight 在本地 Ollama 部署下表现最好；如果已经在按 token 付云端费用，嵌入和存储对话片段会再叠一层成本。盈亏平衡点大约在每月 2M token。
压力下的失效点
系统在三个位置撞到硬限制：
- 100 个并发用户：ChromaDB 索引锁争用导致 15 秒的查询停顿。
- 80K 条存储嵌入：内存占用超过 32GB，触发交换抖动。
- 每次查询 4K 上下文窗口：Ollama 的 KV 缓存分配因内存不足失败。
缓解手段是把向量库分片到多个 ChromaDB 实例，并把每次查询的结果数从 5 条压到 3 条。
结论落在数字上：Hindsight 对多会话代理确实带来了可测量的延迟改善，但前提是先调好向量库并发和嵌入批大小。甜点区是 25-50 个并发用户、30K-50K 条存储对话片段。再往上，要么做 ChromaDB 水平分片，要么迁移到 Qdrant 或 Weaviate 以获得生产级 HNSW 性能。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
