岛屿点灯记

结构化抽取掉点大概率不是Prompt本身的问题，而是新数据里出现了测试集没覆盖的格式和边界case，建议先把badcase按类型聚类看看分布。我们这边是把Prompt当代码管，放git里每次改动配一版固定评测集跑分，分数波动超过阈值就不合入，另外temperature设0对格式稳定性帮助挺大。工具的话LangSmith或者Promptflow都能做trace和回归，比手工试靠谱多了。

法条编号都能改错，感觉不是prompt的事，你得在生成后加一步引用校验，把编号跟原文对一遍。

我上周刚踩过一模一样的坑，CoT加few-shot堆上去反而更飘，后来发现根本问题不在prompt长度，而是任务边界没拆干净。你让模型一步到位做信息提取加API调用，它其实在同时做决策和执行，稍微有点歧义就崩了。我的做法是把agent拆成两段：先让模型只输出结构化的“下一步动作”，比如JSON里明确写tool_name和参数，再用代码去校验参数合法性，不合法直接打回重试，这样死循环少了一大半。温度

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

实体和结论被切散就是切分粒度的问题，先试试按段落或小标题切，别硬卡512。

先试试按标题/段落切，固定256字确实容易把步骤拆散。

这个问题我也踩过，子Agent之间传参确实容易崩，尤其SQL这种带特殊字符的。建议试试langchain的PydanticOutputParser，把SQL字段定义成结构化输出，别让模型自由发挥。清洗逻辑最好放在Agent外面的工具函数里，别写进prompt，不然模型真会当成任务去执行。架构上也可以考虑让执行Agent自己接收自然语言描述再生成SQL，减少中间传递环节。

试试vLLM加AWQ，再把gpu_memory_utilization调到0.9，KV cache用fp8，基本能稳住。

prompts资源就是干这个的，模板和工具描述各管各的，别硬塞一起。

动态轴记得在ONNX里把输入输出的batch维度都标成-1，TRT profile再对齐，不然必炸。

说实话我测下来感觉也差不多，数学证明那块确实没比Claude 4 Sonnet强，有几道题还绕进去了。不过我觉得拿基准测试说事也有点片面，实际用起来在写代码补全这种短任务上体感还是有提升的，就是没那么神。可能现在大家对迭代速度的期待本身就不太现实，预训练数据快见底了，架构又没大改，能稳住就不错了。

我之前也踩过这个坑，4090跑8B FP16确实只能撑个4k上下文，再长必炸。AWQ 4bit掉点最明显的地方就是代码和长文归纳，因为量化误差在注意力权重和KV上会累积，尤其你RAG召回一堆碎片拼起来，模型本来就要做复杂推理，一量化直接崩。后来我改成8bit量化加flash-attention，显存大概16G左右，效果比4bit稳太多，上下文也能拉到8k。vLLM确实值得上，PagedAttent

我之前也卡在这个阶段，后来发现关键是别把prompt当咒语念，得当成信息路由设计。你那个合同抽取的例子，换模板就崩，大概率是few-shot里的例子太具体了，模型学到的是表面格式而不是抽取逻辑。可以试试把任务拆成两步：先让模型识别合同里有哪些条款类型，再按类型分别抽，这样泛化会好很多。另外稳定性验证别只看准确率，多跑几组不同来源的样本，看失败案例集中在哪，比盲目调措辞有用。

24G跑14B确实尴尬，要不试试双卡或者换7B？我这边7B的FP16补全质量比14B量化好不少。

工具调用这块我也头疼，后来加了重试和参数校验才稳一点，但复杂场景还是容易翻车。

8G跑1B确实够呛，试试batch size降到1、序列砍到256，再开梯度累积撑一下。

5000条函数级样本对7B模型来说确实有点少，而且你只训了3个epoch，loss降得快大概率是在背数据而不是学能力。我建议先把数据量补到2万条以上，同时混入10%左右的通用语料防止遗忘。至于定位问题，你可以拿微调前的模型在同样评测集上跑一遍，如果基座本身就不行那是数据锅，如果基座OK但微调后崩了，那多半是过拟合加灾难性遗忘一起犯了。

大块召回小块喂给模型试试，父块给上下文、子块精确定位，重排也值得加。

我现在基本不纠结固定切多少了，纯按 token 切确实很容易把一段完整逻辑拦腰砍断，尤其技术手册里一个参数说明跨了好几段，切完就只剩半句话。我后来改成先按标题层级和段落做自然切分，再对超长段落做二次拆分，短段落就合并到相邻块里，overlap 只留一点点防止边界丢信息就够了。效果不稳很多时候不是切片尺寸的问题，而是召回阶段就没把对的块捞出来，你可以先单独看下 top-k 召回的片段里到底有没有答案