发布正在思考的程序员
Lv.1希望每次重构都不是下一次事故的开始。主要研究软件工程与问题排查，记录开源工具使用、项目复盘以及那些看似简单却很容易踩坑的问题。技术会变化，解决问题的方法值得长期积累。
发表的评论
我踩过这个坑，state里塞太多原始数据后面根本没法维护，建议只留必要字段和中间结果摘要。TypedDict够用但容易漏字段，Pydantic校验省心点，就是写起来啰嗦。并发冲突其实可以给每个节点独立的局部state，最后再merge回去，别所有节点都往一个大字典里怼。回滚的话我一般靠checkpoint，LangGraph自带的持久化配合条件边做补偿，比手动恢复靠谱多了。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
刚入门，这个对我帮助很大。
写得挺好，建议补充一些性能数据。
有没有更详细的教程推荐？
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
16G的MacBook跑本地模型确实吃力，我最后就留了Aider配DeepSeek的API，便宜又够用，本地那点算力真不够折腾。
之前跟过几次编队项目的测试，最直观的感受就是通信链路一断，整个队形立马就崩，所以冗余设计这块确实很关键。大漠大那个一控多机架构我没细研究过，但能把边缘计算塞进机载端做实时重规划，这个思路比单纯堆地面站算力要聪明。不过话说回来，复杂电磁环境下几千架同时跑，实际演出时翻车案例也不是没有，算法再强也怕现场干扰。好奇他们现在单场表演的失效率能压到多少？
我也踩过这个坑，后来发现大概率不是prompt的问题，而是训练数据里tool_call的格式没统一。你检查下微调样本里function call的JSON结构，参数名和类型必须跟推理时完全一致，差一个冒号模型就学歪。另外轻量模型对格式特别敏感，建议把工具定义直接塞进system prompt里，别指望它自己记住。你试试把temperature调低一点再跑，有时候参数乱套纯粹是采样太随机了。
温度调到0.2以下确实有用，另外可以试试让模型先复述原文再回答。
你这个问题我感觉不一定是embedding的锅，chunk切分方式可能更关键。“跨部门盖章要多久”这种问法跟原文表述差挺远的，纯向量检索确实容易翻车。可以试试混合检索，bge做向量召回的同时加一路BM25关键词匹配，再用rrf融合排序，对你这场景提升应该挺明显。另外chunk别只按固定长度切，按段落或标题语义切，保留上下文标题信息，召回会干净很多。
loss降到0.8不一定说明模型学到了东西，3k条数据如果格式没对齐，很容易过拟合到表面模式上。你检查过推理时的prompt模板跟训练时是不是完全一致吗？这个坑我踩过，模板差一个换行效果都能差很多。另外target_modules只调q_proj和v_proj有时确实不够，试试加上k_proj和o_proj，或者直接用all-linear。还有种可能是数据里问题和答案的边界没标清楚，模型压根没分清
A100 80G跑4bit QLoRA，batch 4就爆确实有点奇怪，大概率是序列长度2048加代码数据本身token密度高，activation占了大头。gradient checkpointing基本是必开的，能省不少显存，就是慢个20%左右。另外检查下有没有把optimizer设成paged_adamw_8bit，还有LoRA的target modules别只挂q v，代码任务一般q k
我们之前也踩过这个坑，后来把工具调用记录单独拎出来存成结构化状态，每轮只把当前任务相关的几条塞回去，效果好很多。摘要压缩确实容易丢细节，尤其是用户中途改的偏好，建议关键槽位单独维护，别全指望摘要。