河狸会做产品日记

试下把格式要求直接写进工具返回值的schema里，让模型把JSON当参数生成而不是自由文本，我这边改了之后基本没再翻车过。另外别指望一句system prompt能镇住它，可以在每个user消息尾巴上加个固定后缀，比如“直接给JSON，别废话”，效果立竿见影。还有个思路是让模型先输出一个fenced code block，你再在后处理里剥掉外壳，容错率高很多。

我之前微调合同审查模型的时候也纠结过这个，最后选了ShareGPT格式，因为多轮对话能保留上下文关联，对长文本抽取确实友好些。不过单轮指令和对话混训确实会飘，我是按比例混合然后加特殊分隔符区分的，收敛速度慢一点但泛化好不少。你要是主要做条款提取，建议还是统一成多轮格式，把单轮指令包装成一轮对话，省得模型学乱。

这个坑我也踩过，bge系对长文本的语义压缩其实挺敏感的，我后来固定用300左右加30%重叠，效果比512和50%稳很多。不过技术手册这种结构化强的，我会先按标题粗切再二次细分，聊天记录就得靠小chunk硬扛。你可以试试用验证集跑一下召回率曲线，手动调几轮后基本能摸到规律，自动化工具目前感觉都不如自己看几个badcase来得快。

这问题我太有感触了，之前用MCP调一个流式翻译接口也踩过同样的坑。LangChain的BaseTool默认确实把输出当完整字符串处理，但MCP那种逐chunk返回的设计，本质上是把协议层的数据流和框架层的工具返回值给搞混了。我当时试过自己写个缓冲队列去拼，结果丢包重传时顺序一乱，JSON直接parse失败，最后干脆在工具内部用SSE的event-loop逻辑，每个chunk带个递增序号，组装完再校

说实话两个半斤八两，PyTorch那个MCP我试过，类型问题确实烦人，后来直接绕过去用ONNX中转反而省心。TensorFlow配置复杂但好歹稳定点，不过社区案例太少，遇到坑基本只能自己啃。你要是卡在数据转换，不如看看HuggingFace那个多模态pipeline，或者直接用gRPC自己封装一层，别在MCP一棵树上吊死。

试试把项目里的Table组件路径直接写进prompt，再附一段现有调用代码当范例，比单纯说“复用”管用得多。

这个问题我最近也踩过类似的坑，切片策略其实得结合文档结构来定，比如PDF里标题层级明显的话，按层次节点切比纯按字数切好很多。另外检索后重排序确实是关键，我试过用bge-reranker把向量召回的前30个结果再排一下，准确率能提一截，不过要控制好计算开销。混合检索的话，建议加上BM25做关键词匹配，跟向量相似度加权融合，对长尾术语特别管用。你用的Milvus是单机还是集群？如果数据量大，切块时注意

8G显存跑1B模型确实有点极限，我4060试过类似情况。batch size降到1试试，或者把序列长度砍到256，很多时候长序列对微调效果提升并不明显。另外可以检查下是不是中间激活值占太多，用torch.cuda.memory_summary()看下具体哪块爆的。

这个情况我也遇到过，尤其是7B这种规模的模型，对prompt的敏感度其实比大参数模型高不少。固定seed确实能保证单次推理的一致性，但并不能解决模型本身对输入格式的波动——比如同样的意思换了个标点或换行，输出就可能不一样。我自己的经验是，在prompt里加一些结构化的约束会有效，比如用明确的“指令-输入-输出”三段式，或者在关键部分加上“请严格按以下步骤回答”这种引导。另外vLLM的batch推理