北京
你在跑大规模检索增强生成系统时，真正的瓶颈往往不是嵌入模型，也不是向量索引，而是检索和生成之间那层token开销。这个教训来自一次生产环境的实测：常规查询开始撞上200K上下文窗口，其中60%的token来自冗余的JSON元数据和未压缩的工具输出。
架构本身很标准：pgvector做语义搜索，Python做编排层，Claude Sonnet通过多提供商网关路由以保留故障切换能力。问题在高并发运行时暴露——每请求的token中位数在生产负载上线两周内从45K跳到180K，纯粹是累积的检索片段和智能体步骤日志造成的。
把压缩放在检索之后、提示组装之前
做法不是把原始检索结果和JSON数据块直接塞进模型上下文，而是在向量搜索之后、提示组装之前插入一个压缩阶段。这个环节处理三类削减模式：
- 检索片段之间的语义去重，用余弦相似度阈值丢掉近乎相同的段落
- JSON结构扁平化，剥掉冗余键，在安全的前提下内联嵌套对象
- 智能体工具输出的日志摘要，用根因提炼替换冗长的堆栈信息
集成点在混合检索流程里：向量搜索走HNSW索引，关键词搜索做混合融合，两路结果用倒数排名融合合并，然后进入压缩环节，目标压缩比设为0.4，也就是瞄准60%的削减，同时保留代码块不被激进压缩。
HNSW索引锁的坑
一个生产陷阱：批量插入嵌入向量时（每分钟1万条以上），PostgreSQL的HNSW索引锁造成严重写入争用，插入延迟的P95飙到3.2秒。解法反直觉——批量写入期间先禁用索引，写完再重建。索引参数上，m=16、ef_construction=64是关键取值，更高的值能提升召回但会让索引构建时间翻倍；A/B测试显示m=16时recall@10在0.91趋于平台。
嵌入归一化的暗坑
另一个根因级故障：切换嵌入模型后召回率从0.89掉到0.62。元凶是未归一化的向量——pgvector的余弦距离算子期望单位向量，而新模型返回的是未归一化嵌入。加上归一化处理后，召回恢复到0.87，接近到足以支撑这次模型替换，换来的是推理速度提升40%。
上线后的数字
- token中位数：180K降到72K，削减60%
- LLM延迟P95：8.2秒降到3.1秒，上下文变短解码更快
- 每千次请求成本：34美元降到14美元，输入token变少
压缩命中率随数据类型浮动：JSON工具输出能压掉85%到95%，自然语言检索片段只能压40%到50%。代码块被豁免于激进压缩，以保住语法结构。
还没解开的取舍
一个悬而未决的问题：语义去重什么时候会伤到答案质量？实际遇到过这样的情况——两个几乎相同的片段存在细微差异，而差异对最终答案有影响：一个提到了已弃用的API参数，另一个没提。压缩层把两者合并，模型就漏掉了弃用警告。团队正在试验把相似度阈值从0.96下调到0.92，以保留更多边界片段，但这是精确率与召回率之间的权衡，没有干净的答案。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
