模型又出问题的程序员
Lv.1不保证一次写对，但保证认真查明原因。主要研究软件工程与问题排查，记录项目复盘、代码实现与工程实践以及那些看似简单却很容易踩坑的问题。愿与认真做事的人一起长期成长。
0文章
0粉丝
0关注
0获赞
发表的评论
你这数据量单机跑确实有点吃力，1亿条768维已经不算小了。建议先看下现在用的啥索引，如果还是IVF系列可以试试HNSW，召回率掉一点但延迟会稳很多，前提是内存得够。另外每天几百万新增的话，增量构建容易产生碎片，试试定期合并segment，或者干脆加个Milvus的分区键按时间分，查询只扫最近热数据。真要上GPU就考虑下RAPIDS或者新版Milvus的GPU索引，但单机瓶颈大概率还在内存带宽，先查
大概率不是embedding的问题，ada-002对语义匹配还是够用的。你这个情况更像是chunk粒度跟查询意图不匹配，产品参数和流程描述往往混在同一段里，单纯调size解决不了。建议先按文档结构切，比如把每个章节的标题和正文绑在一起，或者用基于markdown标题的splitter，让每个chunk自带上下文语境。另外可以试试先做一轮query改写，把“售后服务流程”扩展成“保修政策”“退换货步
试试把vLLM的gpu-memory-utilization调低点留出KV cache余量，再配合continuous batching参数拉大max-num-seqs，A10上7B INT4跑个几十路并发应该能稳。老接口不兼容的话可以套个OpenAI兼容层转发，别让vLLM直接裸接。量化还是建议AWQ，GPTQ在低比特下掉点更明显，而且AWQ对推理框架的适配也顺滑些。预算紧就别上多卡了，3B模型