长期关注战略增长记

按标题切再按语义分段确实比硬切强，我一般再加个重叠窗口，召回就稳多了。

loss降不代表模型变强，你这就是典型的灾难性遗忘，法律数据太单一把通用能力冲掉了。建议混10%到20%的通用指令数据进去，r=16其实不算大，问题更多在数据分布上。eval千万别只看loss，必须跑生成看实际输出，不然loss再低也可能是废话。

这个坑我踩过，问题多半出在编排上而不是 MCP 本身。工具调用和检索是两套决策路径，模型很容易二选一，你得在 prompt 里明确写死“必须先检索再调工具”，或者干脆用代码把流程串起来，别指望模型自己规划。另外工具 schema 里最好加个字段接收检索结果，不然模型确实容易忘。我现在是检索完直接把上下文塞进工具参数模板里，稳很多。

我也有同感，最近写Pydantic模型时字段老猜错，感觉上下文一多它就犯迷糊。

polars和duckdb其实不算小众，性能确实比pandas猛，尤其数据量大的时候。但你这脚本就清洗个CSV，真没必要引入这些，依赖多了以后别人接手确实头大。我一般会在提示词里直接写“只用pandas和标准库，不要引入其他第三方依赖”，基本就老实了。

角色设定有用但得配具体例子，光给风格词模型容易自由发挥，加点真实对话模板会稳很多。

同感，我现在都先列个输出框架再让模型填，比反复改措辞管用多了。

MCP的Prompt模板跟系统提示词是两套东西，别指望模板能压过系统提示。模板更像是给客户端用的“快捷指令”，用户或工具主动调才会生效，模型不会自动优先走它。想让工具强制输出JSON，得在工具本身的描述和返回结构里下功夫，或者用response_format这类硬约束，光靠模板容易翻车。变量占位符建议用清晰的命名比如{{input_text}}，别搞太复杂，调试时先把模板单独跑通再接进server

8张A10跑7B还卡并发，先查下是不是max_model_len开太大了，那玩意吃显存比batch狠。

分块和模型可能都不是根因，你描述的这个场景我踩过类似的坑。合同类文本有个特点，条款之间靠编号和交叉引用关联，按500字硬切很容易把一条完整条款拦腰截断，检索出来的片段语义不完整，bge再强也救不回来。我建议先别急着换模型，把chunk做一次可视化检查，看看top-5命中的片段是不是本身就缺上下文。另外bge-large-zh在中文检索上其实够用，但如果你没加instruction前缀，效果会打折扣

loss降不代表检索就好，对比学习很容易把模型训得“过拟合”到你的标注偏好上，反而丢了通用语义空间。你那个熔断器和断路器的例子，如果正负样本里把近义词硬拆成负例，模型就会学歪。另外微调完embedding必须全量重建索引，不然新旧向量空间对不上，排序肯定乱套。建议先别动模型，拿原始bge跑一遍看基线，再对比微调后同一批query的topk变化，定位是样本还是索引的问题。

复杂业务逻辑确实别太指望它，我现在的做法是让它只写函数签名和docstring，具体实现自己填，反而省了想接口的时间。多线程和生成器这种它特别容易翻车，之前给我整出过一个在finally里await的骚操作，排查了半天。当高级补全用就挺好，别让它碰核心链路，CRUD和单元测试生成倒是真香。

bge-large换small确实能快不少，但检索质量会掉一点，建议先试试预加载索引到内存里，别每次查询都重新加载。

这个问题我太有共鸣了，之前做信息抽取也经历过一模一样的阶段。后来发现关键在于把“调prompt”变成“设计评测”，先别急着改措辞，而是花时间搞清楚模型到底在哪些样本上错、错的原因是什么。比如合同模板换了就崩，很可能是模型依赖了固定位置或格式线索，而不是真正理解条款语义。这时候可以做一个错误分类表，把失败案例按“漏抽、错抽、格式错”分个类，针对性补few-shot或者加后处理校验。至于CoT和角色设

我之前也踩过这个坑，loss各跑各的基本就是DDP没真正生效。你检查下是不是在model = DDP(model)之前就跑了forward，或者optimizer在DDP包装前就创建了？还有种可能是find_unused_parameters没设对，BERT这种有pooler层容易漏参数，加上这个参数试试。另外确认下每张卡的batch size是不是被均分了，不然loss对不上也正常。

动态路由这块我也挺好奇的，演示里基本都是线性流程，真到生产环境里分支和异常才是大头。之前用AutoGen做多智能体协作，光是一个工具调用超时后的重试逻辑就调了半天，状态一致性太难保证了。Navos要是能把这块做成开箱即用，那确实比裸写LangChain省心不少，但估计还是得自己填不少配置。

我最近也在折腾类似的东西，感觉分块这事真没有银弹，得看你文档本身的“信息密度”和用户问题的粒度。固定长度切确实太粗暴了，尤其技术文档里参数表、代码块被拦腰截断，检索出来就是一堆残片。我现在的做法是先用语义分割跑一遍，比如LlamaIndex里的SemanticSplitterNodeParser，让embedding自己找断点，然后再对表格和代码块做特殊保护，不参与切分。不过语义分割也有坑，计算开

Chroma起步最省心，本地跑几行代码就完事，等真不够用了再换Milvus也不迟。

几百条数据跑3个epoch确实容易过拟合，LoRA在小数据集上很容易把固定句式背下来。学习率1e-4对7B模型来说偏高了，试试降到1e-5或2e-5，同时把epoch减到1-2看看效果。另外检查下数据里有没有重复或格式太单一的样本，客服问答如果全是同一种模板，模型学到的就是套话而不是泛化能力。可以先把LoRA权重和基座做个对比推理，确认是不是微调本身造成的退化。

我现在的做法是让AI先写测试再写实现，prompt里直接要求它输出pytest用例覆盖边界条件，跑一遍再把报错贴回去让它改。这样迭代几轮比一次生成靠谱多了，上下文依赖的问题也少很多。不过类之间调用来回调的那种，还是得自己先理清接口，AI搞不定隐式的业务约束。