云端金鱼喜欢开源日记

LLaMA-3用4bit记得把bnb_4bit_compute_dtype设成bfloat16，架构报错八成是transformers版本太老，升到最新再试。

gpu_memory_utilization设太高反而挤掉调度空间，试试降到0.85再压测看看。

我是先按文档结构切，再拿几个典型问题跑召回看命中率，overlap给10%到15%就够，别纯靠数字试。

多步任务断掉太常见了，我后来把整个流程改成用LangGraph做状态机，每个节点只负责一件事，中间结果显式存到一个state里，Agent就不会“忘”了。DataFrame那块建议单独抽成一个tool，别让模型直接操作df，它很容易在类型推断上卡死。还有你那个发邮件步骤，最好放在最后用确定性代码跑，别交给Agent判断。Prompt再细也救不了长链路，框架和拆解方式比措辞重要得多。

单轮80多轮就崩，典型的数据分布问题——你训练集里基本都是单轮调用，模型根本没学过“上一轮结果怎么影响下一轮决策”，loss降得再低也没用。建议补一批多轮轨迹数据，尤其是那种“调用失败后重试”和“不需要调用但容易误触发”的负样本，这两类最能治该调不调和选错工具的毛病。另外评估别只看单轮准确率，把工具选择、参数正确、调用时机拆开算，才知道到底是哪块拖后腿。

刚入门，这个对我帮助很大。

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

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

学到了，感谢分享！

几百条数据微调7B做rerank，这个量级其实很容易过拟合，loss降了不代表排序能力学到了。你可以先别急着上LLM，拿bge的cross-encoder或者bge-reranker-base跑一下同样的top20，如果它都比bm25差，那问题可能出在标注数据本身或者评测方式上。另外LLM做rerank输出的分数尺度很关键，直接拿生成概率当排序分经常不稳定，最好固定成二分类的yes/no概率来比。

我之前也踩过这个坑，光靠prompt确实很难稳定约束住多步流程，模型偷懒跳步太常见了。后来我改成在每步之间加一个轻量的校验节点，比如提取完信息先让它输出JSON，脚本验证字段齐全再往下走，效果好了很多。LangGraph这种外部编排确实更靠谱，把步骤拆成独立节点，每个节点只干一件事，比在prompt里反复强调顺序管用。你要是demo阶段不想上框架，也可以先用函数调用强制分步，模型就没法一次性糊弄过

先看看prompt里有没有明确要求保留预算细节，7B模型对多段信息的指令遵循确实容易掉链子。

我们线上也是FAISS打底，专业术语确实容易翻车，后来加了BM25做召回融合，排序用RRF先粗排再上小模型精排。BGE-rerank-v2-m3确实有点重，可以试试bge-reranker-base或者Cohere的rerank接口，延迟能压不少。混合检索不一定非要全量走rerank，先top50融合再截断到top10精排，响应时间基本能接受。

分块没毛病，问题在embedding分不清步骤和背景，试试先用小模型把query改成“操作步骤”再检索。

我一般把prompt存文件里用git管，再写个脚本跑固定case对比输出，玄学也得有数据撑着。

试试在提示里直接给个带try-except的代码模板让它照着改，比单纯说“加异常处理”管用多了。

试试在prompt里加个“得到答案就输出FINAL ANSWER”，再配个状态判断提前结束循环。