蜗牛认真测试日记

几十万条这个量级Qdrant单机完全够用，过滤检索性能也挺能打，内存占用比Milvus友好不少。Milvus那套etcd加MinIO的依赖，小团队维护起来真挺折腾，除非你后面数据量要上千万再考虑。不过Qdrant的payload过滤字段记得建索引，不然带条件的查询会慢得让你怀疑人生。

之前也纠结过这个问题，后来发现入门其实没啥硬性标准，能稳定让模型输出你要的格式和大致内容就算摸到门了。但真正的分水岭是你会不会拆任务，把一个模糊需求切成几步，每步给清晰的约束和示例。我自己踩的最大的坑就是老想用一段prompt解决所有问题，结果调半天不如拆成三轮对话来得稳。进阶的话建议去啃一下function calling和结构化输出那块，比单纯调措辞有用得多。另外多看看别人开源的复杂promp

我理解你的困惑，但MCP的价值不在单机场景。比如你把推理服务部署在远程GPU集群上，LLM本身跑在本地或另一个环境，这时候MCP就是个标准化接口，省得每次手写胶水代码。至于显存和并发，实际落地一般是MCP服务器后面挂推理服务（像Triton或vLLM），模型常驻由推理框架管，MCP只负责协议转换和路由，不是每个请求都加载一遍模型。

nlist 1024 对10万数据太大了，nprobe 16 也偏低，难怪召回不准，先降到 nlist 128 试试。

我一般不会死磕固定k值，而是先拿一批真实问题跑检索召回率，看正确答案在第几名，再决定截断点。k=3漏信息、k=8进噪声，说明问题可能不在k，而在chunk切得太碎或query和文档语义没对齐。可以试试先召回20条再用bge-reranker重排取前3到5条，效果通常比硬调k稳。另外人社领域术语多，embedding模型最好拿领域数据微调一下，不然相似度分布确实会很飘。

微调后反而丢格式，大概率是数据格式和你的prompt模板没对齐。alpaca格式训练时模型学的是“指令-输出”的简单映射，但你推理时塞了角色设定和few-shot示例，分布直接对不上了。一个epoch加2e-4的学习率也偏激进，容易把基座本身的指令跟随能力冲掉一些。建议先拿微调前的模型和微调后的模型在同一批样本上跑个对比，看是全面退化还是只在你那套模板下退化，再决定是重训还是把训练数据改成和你模板

PyTorch和TF在loss缩放、梯度裁剪的默认行为上确实不太一样，TF的Keras里很多优化器自带梯度裁剪或者对极端值更宽容。你可以先试试在PyTorch里加torch.nn.utils.clip_grad_norm_，再把优化器的eps从默认1e-8调到1e-6左右看看。另外检查下有没有在loss里用了log或除法，动态图下这些操作对数值很敏感，TF静态图可能帮你兜住了。

分块喂，每块先让它抽数字再汇总，直接整篇塞中间肯定丢。

这问题太真实了，我前段时间做售后意图分类也踩过一模一样的坑，同一个prompt今天跑得飞起，明天换批数据就胡言乱语。后来我强迫自己把prompt挪进Git管理，每次改动都写清楚改了什么、为什么改，虽然土但真的能救命，至少不会出现“上周那版挺好的但找不到了”这种崩溃时刻。评估这块我现在会先攒一个几十条的小测试集，覆盖各种边界情况，每次改完都跑一遍看通过率，而不是只盯着手里那几条用例调。但说实话，光看

你是不是 Ollama 那边没设 keep_alive，模型每次被调用都重新加载？

工资这种口语query和制度文档的表述差太远了，光换embedding模型治标不治本。我建议先搞个几十条真实query的golden set，把召回率量化出来再动手调，不然你都不知道改完到底有没有变好。chunk按200字硬切确实容易把条文拦腰砍断，试试按标题层级或者语义边界切，再叠个rerank基本能救回来一大半。

512 tokens 固定切法在这种“参数怎么配”类问题上确实容易翻车，因为答案往往就藏在某个小节的代码块或表格里，切完正好被劈成两半。我建议先别急着上 GraphRAG，那个搭建和维护成本挺高的，几十份文档不一定撑得起它的收益。你可以先试试按标题层级做语义切分，再给每个 chunk 加上所属章节路径当元数据，检索时把相邻 chunk 一起召回，很多漏细节的问题能缓解不少。另外512对小节密集的技

双3090跑13B还爆显存，感觉你batch size或者max_model_len设太大了，Agent场景其实不需要那么长的上下文窗口。量化的话建议直接上AWQ，比GPTQ在多轮对话里稳不少，8bit确实容易让逻辑断片。框架可以看看SGLang，它对动态函数调用和并发请求的处理比vLLM顺手，不用频繁重启worker。CPU offload就算了，延迟直接翻倍，Agent等不起。

我也踩过这个坑，后来干脆把检索和生成揉成一个工具，内部先召回再压缩chunks，只把最相关的片段吐给主模型，上下文立马清爽很多。拆开靠prompt约束太看模型脸色了，尤其多MCP并行时顺序根本控不住。MCP本身不背锅，它只是传话的，问题在于你没在工具层做结果裁剪和缓存。可以试试给检索工具加个token预算参数，超了就摘要或截断，比事后抢救管用。

合同条款这种场景，光靠调chunk_size真的治标不治本，金额这种精确信息一旦被切碎或者和上下文分离，embedding再强也难救回来。你可以试试按条款结构切，比如一条合同条款作为一个chunk，别硬按字符数切。另外bge-small对中文长文本确实吃力，换个bge-m3或者加个reranker，召回精度提升会很明显，bge-m3也不算大模型，成本可控。

我一般只写三句话：只依据上下文、找不到就说不知道、别自己编。写多了模型反而更迷糊。

几百条数据确实太少了，模型容易过拟合跑偏。建议先别急着调参，加到几千条试试看效果。

固定500切块对这种技术手册确实容易把配置步骤切散，重叠50也补不回来。建议先按标题层级做语义切块，把“修改端口号”这类操作步骤完整保留在一个块里，再配合bge-large基本够用。评估的话可以自己攒几十条query和对应答案片段，算一下recall@k和mrr，比肉眼靠谱多了。另外top_k调大没用，往往是召回阶段就没进来，得先解决切块和embedding的匹配问题。

80条工具调用样本确实太少了，模型根本没学会怎么稳定映射参数，单轮指令准不代表多轮Agent里能扛住。我之前也踩过这个坑，后来把样本补到五六百条，专门覆盖多轮槽位继承和参数缺省的情况，效果才明显好转。另外r=8对7B做结构化输出可能偏小，可以试试r=16或32，同时检查下训练数据里工具调用的格式是不是跟推理时完全一致。

top_k设10确实容易这样，我一般先粗召回10到20条，然后加个cross-encoder rerank压到3到5条，效果比直接砍top_k好很多。另外你可以在prompt里明确说“只根据提供的上下文回答，上下文没有的直接说不知道”，再把每段chunk前面加上来源标题，模型会更容易挑。还有个坑是chunk重叠太大时，同一段信息会被重复召回，挤掉其他有用的内容，可以试试把重叠降到64。