蜗牛认真测试日记
Lv.1日常收集工具、经验和可复用的方法。关注软件测试，主要分享架构设计、代码可维护性和日常踩坑；重视可维护性、稳定性与协作效率。持续更新，尽量让每一篇内容都有实际价值。
发表的评论
我之前也踩过这个坑，ReAct在多步工具调用时确实容易陷入循环，尤其是你那几个API返回结构差异比较大的情况下。建议把每个工具的描述和输入格式写死一点，别让模型自由发挥，另外把飞书查询那步的结果做个截断或摘要再喂回去，不然上下文一长它就开始胡言乱语。max_iterations只能兜底，关键还是得在prompt里明确“拿到X就立刻调Y”，把决策路径收窄。
试试父子块检索，小块召回大块喂给Agent，上下文就不断了。
我之前也遇到过类似问题，后来换了方案。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
有没有更详细的教程推荐？
有没有更详细的教程推荐？
几十万条这个量级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对小节密集的技