用Prompt让大模型抽取结构化数据，怎么调都抽不全怎么办？

这问题太真实了，我上次做类似发票抽取也卡在输出格式不稳上。工程兜底的话，建议先试强制JSON模式（如果API支持），再不行就上正则+二次校验，字段缺失就重试那一条。切分长文本确实管用，但更关键的是把任务拆成两步——先判断对话里有没有诉求，再单独抽字段，比一个prompt硬刚稳定得多。另外我后来发现，few-shot示例里故意放几个“无结果”的负样本，模型会更愿意输出空对象而不是瞎编，你可以试试。

说实话这个场景我踩过不少坑，光靠调prompt真不是长久之计。我的做法是先用一次调用做粗分类（判断这段对话是否包含有效诉求），再针对分类结果做二次抽取，能明显减少空字段。另外长文本建议按轮次切块，每块单独抽再合并，不然上下文一长注意力就分散了。你还可以试试加个强制json schema校验，输出乱了就自动重试一次，比纯靠prompt稳定。

遇到过一模一样的坑，最后发现纯靠prompt确实治标不治本。我的做法是先做一轮文本分类，判断这段对话里到底有没有诉求或结果，没有就直接跳过，别硬抽。然后再对抽取结果做一次schema校验，缺字段就触发二次调用，只补缺失部分，成功率能提不少。长文本切分也建议试试，按对话轮次切成几段分别抽，最后再合并，比一口气全塞进去稳得多。另外输出格式乱的话，别用JSON了，改成让模型先输出yaml或者带标记的纯文本，自己解析，容错率高很多。

先分类再抽取确实稳很多，把长对话切成小段再抽，漏字段概率能降不少。

分步走加个JSON校验重试机制，格式乱了就让它自己重抽一遍，比光调prompt省心多了。

试试两次调用吧，先让它抽字段再用JSON schema校验，漏了的单独补抽，比死磕prompt稳多了。

说实话你这个情况太典型了，我上个月做类似项目也踩过一模一样的坑，光靠prompt真的很难根治。我的经验是，与其跟模型死磕输出格式，不如把任务拆成两步：第一次调用只让模型判断这段对话里有没有客户诉求和处理结果，有的话再走第二次抽取，这样能大幅减少空字段的概率。另外长文本切分确实有效，但要注意切的时候别把上下文切断，我是按对话轮次来切，每轮保留说话人标签，效果比按字数硬切稳定很多。还有个小技巧，输出格式乱的时候，可以试试让模型先输出一个自然语言的中间结果，再单独用一个函数或者正则去解析那个中间结果，而不是直接要求它给JSON。温度调到0我觉得反而会让模型在某些边界case上更固执，可以试到0.3左右跟few-shot示例配合一下。对了，你几百条样本里有没有统计过空字段主要集中在哪类对话？如果是特定场景比如用户发牢骚没需求，那可能得考虑加规则兜底，比如关键词匹配来补漏。

试试先让模型做意图分类，再按类型分小段抽，字段空的问题能少一半。

遇到过同样坑，切分加两次调用比死磕prompt靠谱，输出乱就加个json校验重试逻辑。

这种问题太常见了，我建议别死磕prompt，直接上两层校验。先让模型输出宽松的JSON，再用代码做字段存在性检查，缺了什么就触发二次抽取，只补缺失部分，成功率能提不少。

长文本确实该切，但别按固定长度硬切，最好按对话轮次或语义边界分块，不然上下文断了反而更乱。温度调0只是减少随机性，不解决模型本身的理解偏差。

还有个土办法，你拿抽失败的样本反推规律，看是哪种句式容易漏，针对性加几条few-shot。另外，输出格式乱的话，可以试试让模型先输出一个中间标记，比如“以下是JSON:”，再解析，能挡掉不少杂讯。

试试两次调用吧，先让模型判断字段存不存在再抽，空值率能降不少，格式乱就加个JSON校验重试。

试试先跑一层分类再分桶抽取，每个桶单独写prompt，错误率能降不少。

我上次也遇到这坑，加个JSON Schema校验加自动重试，比死磕prompt管用多了。

这问题太典型了，光靠调prompt确实有天花板。我建议你直接上function calling或者JSON mode，把输出schema锁死，比在文本里规定格式稳得多。另外切分长文本挺关键的，客服对话一长，模型注意力一散就容易漏字段，按轮次或按意图先切块再抽会好很多。还有个小技巧，对空字段做二次校验，专门写个prompt让模型判断“这个对话里到底有没有这个信息”，能过滤掉不少幻觉。

试试先把长对话按轮次切块再抽，或者搞两步走，先分类再提取，我上次这么干稳多了。

这问题太典型了，模型对格式的“记忆力”其实没我们想的那么稳。我建议你先试试把长对话按角色或语义切成小段，每段只抽一个字段，最后再合并，能明显减少漏抽。另外可以加一道校验逻辑，用正则或者函数调用强制输出合法JSON，格式乱了就自动重试一次，比单纯调prompt省心得多。当然也可以试试两步走，先让模型判断这段对话里有没有诉求，没有就直接跳过，别硬抽。

说实话你这情况我太熟了，之前做类似项目的时候也是被这种“漏字段”折磨得够呛。我的经验是，Prompt再优化也有天花板，尤其客服对话里那种省略主语、指代不清的情况，模型经常自己脑补。你提到的两次调用我觉得挺靠谱，我自己是先用一个轻量Prompt把对话粗分为“有诉求/无诉求”或“结果明确/模糊”，再对需要细抽的片段做第二轮，这样至少能减少无效输出。另外长文本切分确实很关键，我一般按轮次切，每轮不超过300字，保留上下文关联，不然模型容易丢失信息。还有个土办法，就是做个简单的规则校验，比如检查JSON里必填字段是否为空，为空就自动触发一次重试，把缺失字段单独拎出来问一遍模型，成功率能提不少。最后想说，别指望100%全自动，留个人工复核的队列，把置信度低的样本捞出来，比反复调Prompt性价比高多了。

咱也踩过这坑，光调prompt真不是长久之计。建议你试下两段式，先让模型判断这段对话里有没有诉求和结果，有再抽，没有就返回空对象，能少一半乱格式。另外长文本确实要切，按对话轮次或2000字左右切，抽完再合并，不然中间信息容易丢。最后记得加个schema校验，抽出来先过一遍JSON格式，不对就重试一次，比温度调0管用。

说到这个我太有同感了，之前做类似项目时也卡在“抽不全”上，后来发现Prompt再精准也扛不住真实对话里的噪声。我的经验是，别指望一次调用搞定所有事，你提到的“先分类再抽取”其实特别有效——比如先用一个二分类判断这条对话里到底有没有“诉求”和“处理结果”，没有就直接跳过，有再进抽取环节，这样能省掉大量无意义的空字段。另外切分长文本真的很有必要，客服对话经常来回拉扯，模型在长上下文里注意力会涣散，按说话轮次或者语义段落切开，每段单独抽，最后再合并，准确率能提不少。还有个偏工程点的兜底方案，就是做两层校验：第一层用正则或者规则把模型输出里明显格式不对的抓出来，第二层对缺失字段做一次“追问式”重抽，比如把已抽到的部分和原文一起丢回去，让模型只补缺的那几个key。温度调0其实不一定最优，有时候稍微给点随机性反而能跳出重复模式。最后想说，如果数据量允许，微调一个小的专用模型可能才是终局解法，GPT-4做这种细活性价比真的不高。

我建议先切分再抽，输出格式用函数调用，比纯prompt稳很多。

试试分两步走，先分类再抽字段，加个JSON校验重试机制兜底。

我之前做类似任务也踩过这坑，光调prompt真的容易到瓶颈。你试试把长对话按轮次切成小块，每块单独抽，最后再合并，空字段会少很多。另外两步走确实管用，先让模型判断这段对话有没有诉求，有再抽，能过滤掉不少噪音。还有就是输出校验，抽完用正则或JSON schema检查，不合规就让模型重新生成，比单纯靠它自觉靠谱多了。

这事我踩过类似的坑，光靠调prompt确实容易到天花板。建议试试先让模型做分类（比如判断对话里有没有诉求/结果），再针对有内容的片段做抽取，能少很多空字段。另外输出格式乱的话，可以加一层JSON schema校验，抽完用代码修一下，比纯靠模型稳。长文本切分也值得搞，按对话轮次切，上下文丢失不严重，但召回率会明显上来。

说实话你这个情况太典型了，我试过用类似方法抽合同条款，也是咋调都不稳。后来发现与其死磕prompt，不如先做个规则兜底，比如用正则把明显缺失的字段标出来，再让模型只补那部分。切分长文本确实有用，但我觉得先按对话轮次切成小块再抽，比一次性喂整个对话好使。另外两次调用这思路我觉得靠谱，第一次先判断有没有诉求/结果，第二次再抽细节，能少很多空字段。