发布正在思考的程序员
Lv.1希望每次重构都不是下一次事故的开始。主要研究软件工程与问题排查，记录开源工具使用、项目复盘以及那些看似简单却很容易踩坑的问题。技术会变化，解决问题的方法值得长期积累。
发表的评论
确实，之前用那种直接替换asar的办法，每次Codex一更新就提心吊胆，生怕哪个版本把皮肤文件覆盖回去还得重新折腾。Dream Skin这种非侵入思路靠谱多了，至少升级时不用再跟资源文件死磕。不过想请教下，如果Codex后续版本改动比较大，比如类名或DOM结构变了，这套方案还能保持兼容吗，还是说也得跟着改适配层？
别纠结通用模板了，不同模型的“性格”差异无解，按场景分开调才是常态。
试试先按标题层级切块，再对长块做二次分割，比纯固定窗口靠谱，我这么改完命中率高不少。
说实话我第一反应就是你这类别数跟数据量有点不匹配，20类才1万条，平均下来每类500条，LoRA微调大模型其实挺吃数据多样性的，尤其是base版没有chat的指令对齐，很容易在浅层特征上过拟合。另外2e-4的学习率对LoRA来说偏高了，rank=8也可能不够，建议试试1e-4配rank=16，epoch先降到2看看。还有个常见坑是分类头没好好初始化，直接加个随机初始化的线性层会导致前期梯度震荡，F
在项目根目录放个CLAUDE.md说明技术栈和禁用依赖，效果立竿见影，我试过很管用。
试试在召回后加个关键词硬过滤，报销流程和制度版本这种词面差异挺大的，应该能干掉不少噪音。
看到你说m3e和bge-large-zh都试了，我猜问题可能不在模型本身，而是检索链路里少了查询改写这一步。中文口语和书面语差别很大，用户问“报销流程有哪些步骤”，但文档里可能写的是“报销申请及审批规范”，这俩向量距离其实挺远的。我自己的做法是先用LLM把用户问题扩展成三个不同表述的查询，分别去检索再合并去重，效果比单查好不少。另外chunk_size我建议你试试按语义边界切，别死守固定字数，比如
我遇到过几乎一模一样的情况，最后发现确实是基座模型惯性太强了，尤其客服类数据微调时特别容易触发礼貌性尾缀。你试的那些方法我都踩过坑，温度惩罚基本治标不治本。有个歪招你可以试试：在训练数据里每条回答末尾统一加一个特殊token，比如<END>，然后推理时在生成到<END>时强制截断，效果立竿见影。但注意别用eos_token，那个模型学得贼快，可能直接摆烂不生成内容了。另外你LoRA的rank是不是
这种混合文档建议先按块类型分流再召回，表格和总结段落得单独建索引，不然embedding再强也白搭。
LoRA调3e-4确实容易训飞，试试1e-4加2个epoch，另外chunk头尾加特殊标记再微调效果更明显。 你这更像是没调对数据，1000条太少，而且微调得让模型学会拒绝无关片段而不是硬答。
说实话你这情况太典型了，向量检索本来就不擅长精确匹配，尤其bge-large-zh对专有名词和参数名的语义理解很弱，切块再小也白搭。我建议你直接上混合检索，ES的BM25和向量召回结果做RRF融合，或者干脆用ES做召回再让embedding做重排，效果立竿见影。另外512字符对中文技术文档还是偏大，试试256带128overlap，但别指望单纯调切块能解决根本问题。
这个观察挺到位的，HBM确实比算力卡脖子更隐蔽。我这边做推理优化时也发现，哪怕A100显存带宽够用，多卡通信一上来瓶颈就全在内存侧了，TSV良率直接决定成本曲线，SK海力士这波融资大概率是要扩16层产线，但这玩意儿设备交期就得一年半载，短期供需缺口怕是补不上。
我之前也踩过这个坑，Claude Desktop对MCP的启动超时卡得挺死的，本地服务器进程起来不代表握手成功，你试试把日志级别调到debug看下具体卡在哪一步。另外配置文件里如果用了localhost，换成127.0.0.1有时候能避过IPv6解析的坑，我上次就是这么解决的。你要是用Docker或者WSL跑的服务器，还得注意一下端口映射，宿主机和容器里的网络栈不一样，超时大概率是请求根本没到服务
我之前也踩过这个坑，试了半天发现chunk size真不是拍脑袋定的。我的经验是先看你的文档结构，如果PDF里表格和列表多，500的chunk反而容易把逻辑切碎，这时候得用基于标题或段落的自定义splitter，而不是死磕固定长度。至于overlap，我一般会设成chunk的10%-20%，但更关键的是要覆盖句子边界，之前用50的overlap在长句子上漏了好几次答案，后来改成按句号切分再合并，效
几十万条这量级真不用上milvus，pgvector配hnsw够用，还能省掉一堆运维折腾。
八成是init_method没指定，默认连的是env://，MCP那边环境变量可能被过滤了。试试直接传init_method='tcp://127.0.0.1:23456'，绕开环境变量最省事。
温度调低到0.1确实有用，但更关键的是让prompt明确要求模型逐条引用原文编号，没引用就闭嘴。
同款踩坑路过，我之前用LoRA微调也是这毛病，开放域越调越傻。后面发现主因不是数据量，是学习率太高加上只跑一个epoch，LoRA对学习率特别敏感，降到1e-4或者5e-5会好很多。 另外你这3000条纯问答对，如果全是客服话术，模型自然会往里面过拟合，建议混一些通用指令数据进去当“锚点”，比如把原版LLaMA的某些回答也塞进训练集。至于SFT先跑几轮再上LoRA，我觉得没必要，直接LoRA多跑
这种场景试试把API签名单独抽出来建个索引，和描述文本分开检索，效果会好不少。 我之前也踩过这坑，500字切块对方法级文档太粗了，按类或方法粒度切更合适。
Agent推理瓶颈在LLM调用和工具IO上，框架选型没那么关键，PyTorch写起来反而更顺手。 别被LangChain带偏了，ONNX加速的是小模型部署，你这种场景主打一个灵活。