运维频道

1亿条768维单机扛不住很正常，先换HNSW把召回稳住，但每天几百万增量迟早得考虑分片。

先检查下是不是export时没加do_constant_folding或者opset12对SiLU支持有问题，我当初换opset11反而对齐了。

跨章节问题召回不全，感觉不一定是embedding的锅，text-embedding-3-small中文其实还行，切块太细反而容易把上下文拆散。你可以试试按标题层级切而不是固定字数，或者对PDF先做结构还原再切。BM25混合检索值得加，尤其你们是企业文档，专有名词多，关键词召回能兜住语义模型漏掉的。另外可以拿几个badcase单独看下是召回阶段就没进来还是排序被挤掉了，这个定位清楚再调参数会省很多

3080记得加`-ngl 99`把层全放显存，Q4_K_M跑7B不该这么慢，你这速度像是CPU在硬扛。

转换踩坑这事我太有共鸣了，之前用ONNX转自定义算子也是折腾到怀疑人生。说实话现在Agent方向新东西基本都PyTorch优先，TF生态追得挺吃力，你线上服务如果不是重度依赖TFServing那套，早点统一到PyTorch省心得多。转换工具可以看看tf2onnx配合onnx-tf双向跑，但别指望完全无痛，能重写就重写。

50万条128维跑到200QPS就CPU 90%确实有点反常，先看看是不是每次查询都走了全量nprobe扫描，IVF_FLAT在nprobe偏高时基本等于暴力检索。你换HNSW没效果的话，检查下建索引时的M和efConstruction，还有查询时的ef参数，默认值往往偏保守。PQ量化肯定能降内存和加速，128维用SQ8或PQ分段量化精度损失可控，配合refine重排能找回来不少。另外200QPS

这个思路不错，收藏了。

有没有更详细的教程推荐？

我也是Copilot写样板+ChatGPT理思路，但后来发现把ChatGPT给的代码直接贴回IDE反而更慢，因为风格差异太大。现在我干脆让ChatGPT按我项目里的现有风格重写一遍，比如指定用构造器注入、统一异常处理类，然后再让它输出diff，这样贴回去基本不用大改。Copilot那边我关掉了事务相关的自动补全，太容易带偏。

我之前也踩过这个坑，法律RAG最怕的就是把不同效力层级的条文平铺在一起。你可以在检索后加一层重排序，按法律位阶或者发布时间给个优先级，比如劳动合同法优先于地方性行业规定。另外生成阶段最好让模型先判断冲突，明确告诉用户“一般规定是6个月，但某些特殊行业可能另有要求”，而不是简单拼接。实在不行就加个规则层，同主题法条只保留效力最高的那条再喂给LLM。

7B跑多步工具调用确实容易崩，换14B加vLLM会稳不少，Ollama那套调度撑不住Agent的。

切块512确实偏长了，试试256加重叠50，还有可能是Chroma默认的相似度算法不太行，换cosine距离看看。

每轮搜完先让它复述一遍目标再继续，能拦住不少跑偏。

量化确实会掉点智商，但7B本身指令跟随就一般，试试把system写短点，分步问效果可能更好。

按512切分太粗了，试试按对话轮次切再叠个时间衰减，检索时加个最近窗口兜底。

我一般直接上asyncio队列，token和工具事件都往里丢，前端从队列消费，省得两边对不齐。

你这个情况我去年做合同审查的时候几乎一模一样，本地几十篇文档跑得飞起，一上全量就拉胯。我后来发现根子不在embedding，而是索引分片和检索参数的问题——全量之后向量索引默认的nprobe或者ef_search没调，导致近似最近邻搜出来的候选集本身就偏了，top5里塞了一堆语义相近但不相关的片段，真正该排第一的被挤到后面去了。你可以先拿一批标注好的query做个recall@k的离线评估，固定e

写死流程反而稳，让Agent自己规划容易跑偏，试试LangGraph把节点拆细点。

单机扛1亿向量确实吃力，分片或换HNSW试试，内存够大才能稳住召回。

500的chunk配bge-large其实不算粗，问题更可能出在“违约金怎么算”这种问法和合同原文的措辞差太远，向量匹配不到点上。先别急着上rerank，建议你把召回top10的片段打出来看一眼，如果里面压根没有正确条款，那就是召回阶段的事，加rerank也白搭。真要救的话，可以试试query改写或者加关键词检索做混合召回，纯靠embedding对法律这种措辞严谨的文本确实容易翻车。