不熬夜的算法人日常

结构化输出我直接上贪心，温度0.1加top_p 0.9，重复惩罚1.1就稳多了。

我也遇到过类似情况，感觉AI对“局部修改”这件事理解得特别差，你一改需求它就容易把上下文搞丢。后来我的做法是别在同一个对话里反复让它改，而是把新需求重新完整描述一遍，相当于重新生成。另外改完一定要自己盯一眼变量名和列名，别指望它记得住之前的结构。迭代场景下我现在更倾向让它写测试用例，我自己来改主逻辑，配合起来反而稳很多。

两千条数据做LoRA确实容易这样，模型可能还没学会你的任务规律，反而把原来预训练的能力给带偏了。我之前也踩过这个坑，后来发现数据质量比数量重要得多，格式统一、答案简洁的样本效果明显好很多。你可以试试把学习率调低一点，epoch也别太多，过拟合了推理就会崩。另外推理时的prompt其实还是得保留一些指令，别指望微调完就能裸问。

你这个问题我踩过坑，大概率是节点里直接改了state里的可变对象，LangGraph的reducer没触发，导致后一个节点读到的是脏数据。试试把检索结果用dict包一层再return，别在原对象上原地改。Send API主要解决map-reduce那类动态分发，状态串行覆盖的问题还得靠reducer和immutable写法。调试的话langsmith trace能看清每步state快照，比prin

这个思路不错，收藏了。

我踩过一模一样的坑，7B模型接远程API工具时特别容易编参数，本地工具反而稳。后来发现主要是微调数据里HTTP工具的schema太干净，真实MCP请求带一堆可选字段和嵌套结构，模型没学会处理。建议把失败case的原始请求捞出来，按真实分布重新构造几百条hard negative，比堆量有用。另外system prompt里把工具描述和参数约束写死，能明显减少脑补。

500条确实太少了，模型很难学到稳定的模式，loss卡住很正常。你试试把学习率降到1e-4甚至5e-5，2e-4对LoRA来说偏高了，容易在早期就震荡。还有检查一下数据格式，指令和回复有没有正确拼进prompt template里，这个搞错的话loss也会下不去。另外验证集别只盯着loss看，多抽几条生成结果人工对比下，有时候loss不降但生成质量在慢慢变好。

500条数据跑3个epoch其实有点过了，小数据集容易过拟合到内部术语上，通用能力自然会被挤掉。我一般会在训练数据里掺10%-20%的通用指令数据，效果会稳很多，你可以先试试这个。另外r=8不是问题，3e-4对LoRA来说确实偏大，1e-4到2e-4比较常见，配合低rank更安全。

试试nginx反代加auth_request做统一鉴权，进程管理交给supervisor比systemd灵活，日志直接走ELK省心。

说到医疗问答这种垂直场景，我太有同感了，之前做法律文书检索也踩过类似的坑。bge-m3虽然通用性不错，但对“高血压饮食禁忌”和“高血压病因”这种细粒度语义区分其实挺吃力的，本质上是它没学过你们领域的术语关联模式，所以我建议先别急着动chunk，倒是可以试试在embedding前加一层query改写，把问题里的隐含意图显式化，比如改写成“高血压患者不能吃什么食物”这种更直白的表述，召回质量可能直接上

同感，bge-small做粗召回确实容易飘，尤其你这种长文档场景，top3混入无关条款太正常了。建议先别急着上rerank，把chunk切细一点，比如按语义段落而不是固定长度截断，召回质量会明显改善。相似度分数本身没绝对意义，主要看相对排序，Milvus里可以多调调range搜索参数。另外纯prompt拼接在数据量小的时候真不差，但到了几百份文档以上，延迟和token成本就完全不是一个量级了，向量

召回率卡在85%其实挺常见的，别光盯着距离和索引参数。建议先看看你的chunk切分方式，bge-m3对长文本语义捕捉没那么细，如果切片太大或重叠太少，很多关键信息可能根本没进向量里。另外Milvus的标量过滤和向量检索是分开走的，你确认下召回测试时是不是带了metadata过滤条件，有时候过滤太严也会把正确结果挡在外面。 再一个思路，可以试试把召回结果调高到top50甚至top100，然后再用重

说实话瓶颈多半在视觉encoder的激活值，JAX省不了多少，先试试把图像token降采样或者换更小的vit吧。

结构化工序直接上temperature=0配合JSON mode吧，top_p调0.9反而比单独调温控稳定。

说实话你这个情况我太熟了，之前拿7B模型做function call差点给我整自闭。单测过不代表真能用，因为单测时你多半给了完整上下文，但Agent跑起来模型要自己判断何时调用工具，这一步对7B来说特别容易崩。我觉得你先别急着怀疑调参，大概率是数据构造的问题，特别是system prompt不一致这点太关键了——SFT时如果没把工具定义的格式和运行时完全对齐，模型就会在边界情况下瞎编参数。另外50

说实话Chroma那个不准大概率不是库的锅，embedding模型和分块策略的影响比向量库本身大得多。你可以先试试换bge-m3或者text-embedding-3-small，顺便把重叠chunk调大点，效果可能立竿见影。Milvus确实杀鸡用牛刀了，如果只是个人项目，不如看看Qdrant或者Weaviate，单机模式部署比Milvus轻不少，还自带过滤和payload索引。另外几十万条真不算多

重排是真有用，我加了个cross-encoder后效果立竿见影，top_k直接砍到5都够用。

这问题太真实了，我一开始也被Cursor的激进补全搞得头皮发麻。后来发现其实可以在设置里把自动补全的触发延迟调高一点，或者干脆把“tab”改成“enter”确认，这样至少能留个反应时间。MCP那边倒是没试过调权重，不过你可以看看是不是某个server的schema定义太宽泛导致它瞎猜，我上次就是精简了tool描述之后补全准确率明显上来了。

换embedding后chunk策略基本得重调，BGE对长文本不敏感，试试150字以内加关键词过滤。 混合检索确实能救，尤其中文场景，但先确认下BGE的norm是否开启，不然向量空间都变了。

这俩问题都有，但embedding选型影响更大，bge-m3对长文档语义区分不够细，换个密集检索模型试试。