一线后端研究所

你那个报错里写着从checkpoint加载，是不是加载了别的模型权重？看错误提示expected [64,128]但checkpoint是[32,128]，这俩维度明显对不上，跟你说的128到10完全不是一回事。先确认下是不是load_state_dict时把旧模型的权重塞进来了，或者保存的时候存错了对象。我之前也踩过这种坑，模型结构改了但权重文件没更新，报的错跟实际位置差十万八千里。

4bit量化确实会掉点，尤其7B这个尺寸，写摘要漏步骤挺常见的。我本地跑的时候发现system prompt里把角色和输出格式定死会稳不少，比如直接说“你是技术文档助手，只输出摘要正文，不要解释”，比单纯在user里写要求管用。另外官方API背后可能是更大的模型或者做过针对性微调，本地7B别指望完全对齐。你可以试试换AWQ量化或者跑14B的q4，显存够的话提升挺明显的。

微调后飘忽不定挺常见的，但你提到的prompt模板没对齐确实是个大坑。训练时你加“请调用xxx工具”，线上用户随口说“帮我查一下”，模型看到的输入分布变了，LoRA那点参数根本扛不住这种偏移。更麻烦的是你只调了最后一层，这相当于只改了个输出映射，底层语义理解完全没动，泛化能力自然差，稍微换个说法就崩了。我试过类似设置，冻结太多层的时候模型会变得特别“死板”，只认训练里那几句原话。建议至少把中间几层

我之前也踩过这个坑，500字切出来经常把一段完整的论证拦腰截断，检索到的片段看着相关但接不上。后来改成按标题层级切，段落超长再滑窗细分，overlap留个50到100字，效果明显好很多。chunk大小其实没有万能值，得看文档类型和embedding模型的实际语义粒度，光看最大输入长度不够。混合检索确实能救一部分，BM25对关键词和专有名词召回更稳，但上下文断裂的问题它解决不了，还是得在切分策略上花

7B搞复杂SQL确实吃力，换CodeQwen或14B会好不少，schema也塞进prompt里试试。

之前也遇到过类似的，导出时dynamic_axes只写了input，没写output，结果onnxruntime直接按固定shape去校验了。你把output的batch维也加上试试，另外确认下模型里有没有reshape或者view硬编码了batch维度，那种层导出后动态轴会失效。还有个坑是onnxruntime版本，1.7之前对动态batch支持挺烂的，升级下再跑跑看。

同意这个观点，自然语言描述确实容易在复杂逻辑上翻车，简单场景还行。

确实，窗口合并只是治标，session间的上下文冲突才是真痛点，不知道后续会不会引入任务编排机制。

确实，CLI+LLM的组合在结构化任务上效率碾压GUI，尤其飞书这种重度协作工具，批量操作省掉不少无意义点击。但你说的“指令跑偏”我也遇到过，比如处理表格合并或自定义字段时，Claude Code有时候会忽略上下文，需要反复修正提示词。我觉得短期内CLI还是更适合确定性高的高频场景，复杂排版和长流程依赖GUI的实时反馈会更稳。另外好奇，飞书API对非标准业务的覆盖度会不会成为这个大瓶颈？