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

这问题太典型了，别死磕prompt，先上pydantic做输出校验加自动重试，再搞个规则兜底提取会省心很多。

字段抽不全大概率是上下文太长干扰了，试试先按对话轮次切片再分块抽取，效果能稳不少。

这问题太真实了，我上个月做类似工单抽取时也踩了同样的坑。你提到的切分和两阶段调用其实都是正解，但我觉得更核心的兜底策略是别让模型直接输出最终JSON，而是让它先输出“中间态”的文本块，比如“客户诉求：xxx；处理结果：无”，再用正则或规则去转JSON，这样就算格式乱了也能从原文里捞回来。另外建议给每个字段加一个“未提及”的显式占位符，让模型知道空值不是错误，而是明确表示“这段对话里没这个信息”，能少很多幻觉。还有个土办法是加一层校验循环，拿抽出来的结果做一次“合法性自检”，比如让模型判断“这个JSON里的内容是否都能在原文找到依据”，不通过就自动重试一次。长文本确实要切，但别按固定字数切，用对话轮次切，不然容易把一条诉求劈两半。温度0其实对抽取帮助不大，真正影响大的是top_p，可以试试调低到0.5左右。你要是试完还不行，可以考虑先用分类器把对话分成“有诉求无结果”“有诉求有结果”等几类，再针对每类写不同的抽取prompt，比一个万能prompt稳得多。

这个我太有同感了，光调prompt真的会调到怀疑人生。我建议你先别死磕抽取，试试把任务拆成两步：第一步让模型判断这段对话里到底有没有“诉求”和“结果”，没有就直接返回空对象，避免它硬编；第二步再针对有内容的文本做抽取，准确率会稳很多。另外长文本确实要切，按对话轮次或语义段落切，不然上下文一长注意力就飘了，输出格式也容易崩。还有个土办法，就是跑完加个JSON校验和字段非空检查，不合格的样本自动重试一次，能救回不少case。

这问题太典型了，我做过类似的工单抽取，纯靠prompt真的会抽风。建议你放弃一次到位的想法，改成两段式调用，第一轮先让模型判断对话里有没有诉求和结果，有的话再单独抽字段，这样能把空值率降不少。另外长文本确实要切，按说话人轮次切，每条带上角色标签，比硬塞一整段强。要是还乱，最后加个正则校验JSON格式，抽完拿schema去套，不对就重试一次，别跟模型硬刚。

这问题我太熟了，之前做合同信息抽取也掉进过这个坑。我的经验是别死磕单次调用，先搞个二段式：第一步让模型判断这段对话里到底有没有“诉求”和“结果”，没有就直接返回空对象，别硬让它填；有的话再进第二步专做抽取。另外长对话切分确实有用，但要注意按语义边界切，别把一问一答拦腰截断，不然信息不全照样抽稀碎。还有个小技巧，输出格式乱的话，可以在Prompt里要求它先输出一个合法JSON的示例，再让它照着填，比单纯文字描述管用得多。

说实话我也踩过这个坑，光调prompt真的容易到头。工程兜底更靠谱，比如你先用一次调用把对话按轮次切好，再对每段做抽取，最后合并JSON，缺失率会低很多。另外建议加个schema校验，抽不出来就返回null而不是让模型硬编，至少格式不会乱。你试过用函数调用或者json mode吗？那个对格式稳定性帮助挺大的，比纯文本约束强。

这问题太真实了，Prompt调到头也就那样。我建议你直接上函数调用或JSON mode，让模型输出schema固定的结果，比纯靠提示词约束稳得多。另外长对话一定要切，按轮次或语义分段抽，不然信息一多必丢。我这边还试过先让模型判断“有没有诉求”再抽，空字段率能降一半，你可以试试。

试试先分类再抽取，把长对话切段，每段单独跑，最后merge，空字段会少很多。

你这情况我踩过坑，直接上函数调用或者JSON mode，比纯prompt稳多了。

试试分两步走：先用Prompt做粗分类，再针对类别写细抽取规则，容错会高很多。

切长文本确实有效，但更建议加个校验脚本，格式乱了就自动重试一次，比纯调Prompt稳。

这问题太典型了，我试过用类似方法抽客户反馈，后来发现few-shot示例本身就会带偏模型，尤其是示例里字段填得越全，它就越容易在真实数据上“脑补”缺失值。切分长文本确实有效，但更关键的是得加一层校验逻辑，比如用JSON Schema先验一遍格式，抽完再让模型针对空字段单独补一次，比单纯调prompt管用。另外你也可以试试把任务拆成两步，先让模型判断这段对话里有没有诉求或结果，没有就直接跳过，别硬抽，这样空值率能降不少。

这种问题太典型了，我之前的做法是放弃让模型一次输出完整JSON，改成两次调用：第一次先让它判断这段对话里有没有“客户诉求”和“处理结果”，没有就直接返回空标记，有再进第二步抽具体字段。这样能把格式乱的概率降一半以上。另外长文本确实要切，我试过按对话轮次切，每段控制在500字内，召回率提升挺明显的。还有个土办法，就是跑完后加一个schema校验脚本，抽不齐的自动打回重试一次，比调prompt省心多了。

这事儿太常见了，我建议你先别死磕prompt，直接上两次调用：第一次让模型只判断有没有相关字段，第二次再抽具体内容，能少很多空值。另外长文本确实该切，按对话轮次或者语义段落切，不然模型注意力一散就容易漏。还有个小技巧，输出格式乱的话，用function calling强制JSON结构，比纯文本约束稳得多。当然，最后实在不行就上规则兜底，比如正则匹配一些固定模式，跟模型互补一下。

先分类再抽取真的有用，我这么干之后字段空置率降了一大截，你可以试试。
另外切分长文本也挺关键，超长对话模型容易丢信息，分块处理会稳很多。

这问题太真实了，我搞过类似的项目，prompt调到头也就是个80分水平。建议你试试两段式调用，第一遍先让模型判断这段对话里到底有没有客户诉求和处理结果，有的话再进抽取步骤，能省不少无效输出。另外输出格式乱的话，可以在prompt里加一句“如果信息缺失，JSON里对应字段填null，不要省略”，然后代码里做容错解析，比纯靠模型稳定靠谱。长文本切分我试过，但要注意别把一条完整诉求切成两半，最好按对话轮次切。

切长文本+两阶段调用（先分类再抽）实操有效，我试过能稳不少。
字段空的话，加个默认值兜底，格式乱就上json修复库。

这种问题太典型了，我最近也在搞类似的，光靠prompt硬抠确实上限很低。我的做法是分两步走，先让模型判断这条对话里有没有诉求和结果，没有就直接返回null，有再调一次抽取，这样至少不会把格式搞乱。另外建议把长对话按轮次切了再抽，不然中间混入的闲话很容易干扰结果。最后一定得加个JSON校验重试的逻辑，格式错了就重新丢给模型修一次，比单纯调温度管用多了。

我之前做类似任务也卡在这儿过，后来发现纯靠prompt硬刚确实不现实。我的做法是拆两步走，第一轮先让模型判断这段对话里到底有没有“诉求”和“结果”，没有就直接标记跳过，有再进抽取环节，这样能避免空字段瞎编。另外你提到长文本切分，这个很关键，我试过把对话按角色或者按话题切块，每块单独抽再合并，漏抽率明显降了，但要注意别把跨块的上下文切断。还有个土办法是输出JSON后加一层校验，用正则或者写个小脚本检查字段类型和必填项，不合规就自动触发重试，重试时把报错信息也塞回prompt里让模型自己改，比单纯调温度有用多了。至于few-shot，我后来发现示例越贴近真实分布越好，别光追求数量，最好挑一些包含缺失值、模糊表达的对话当负面样本，让模型学会说“这里没有”。你试过用函数调用（function calling）的方式吗？那个强制走schema，格式乱的概率会低不少，就是得稍微改改调用逻辑。

这问题太真实了，我试过类似场景，光靠prompt硬刚就是会漏。你试试把任务拆成两步，先让模型判断这段对话里到底有没有“诉求”和“结果”，没有就直接返回null，别硬抽，能减少不少幻觉。另外长文本确实得切，按轮次切比按字数切靠谱，不然信息混在一起模型容易懵。还有个土办法，输出格式乱的时候，用正则把JSON从回复里捞出来再二次解析，比让它直接给干净结构稳多了。

先做一轮粗抽取，把长文本按语义切块再二次调用，比单纯调prompt稳得多。

试试加个JSON Schema校验加自动重试，抽不齐就让它重跑，能救回不少。

建议先做意图分类再针对性抽取，字段漏了就用正则或规则补一遍兜底。长文本切分确实管用，但记得保留上下文关联。

试试把输出改成固定填写模板，缺失字段默认填null，格式乱了就做一层后处理校验，比反复调prompt靠谱。