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

先分类再抽取确实稳很多，长文本切段后字段丢失率能降一半，可以试试。

我之前也踩过这坑，后来改成两轮调用，第一轮先判断类型，第二轮再抽字段，基本就稳了。

这问题太真实了，Prompt优化到后期边际效应真的很低。我的经验是别死磕提示词，直接上两层校验：第一层用正则或者规则把明显格式错乱的输出拦下来，第二层对空字段做二次追问，比如把缺失的字段单独丢给模型问一遍。切分长文本也挺管用的，对话太长注意力确实会飘，我一般按轮次切成小块再合并结果。另外强烈建议输出JSON之外再加一个自然语言摘要兜底，至少能人工补救。

说实话温度调到0只是减少随机性，不代表每次都稳定，模型对边界的理解还是会漂。我遇到这种情况会先跑个错误分析，看看空字段是不是集中在特定对话模式上，比如客户说了两个诉求但只提取了一个。工程上比较实用的是做两遍抽取，第一遍先判断这段对话里到底有没有诉求和结果，第二遍再做细粒度抽取，这样能减少无效调用。还有就是output_format别太复杂，字段越少越不容易乱。

这种任务我后来基本放弃纯靠Prompt了，都是直接上function calling或者JSON mode，让模型输出前强制走一遍schema校验。要是还在用普通文本格式，那就在代码里加个重试机制，检测到解析失败就自动换一种表述重新问一次，别让用户看到脏数据。另外few-shot别贪多，选3-5个跟真实分布最像的例子比堆

这问题太真实了，我拿客服数据做抽取时也踩过这坑。建议别死磕单次Prompt，先做一轮粗抽判断“有没有诉求/结果”，再针对有值的字段单独调一次精抽，分步走容错率高很多。另外输出格式乱这事，可以试试让模型先输出Markdown表格再转JSON，比直接约束JSON稳。长文本确实得切，按说话人轮次或标点拆开分别抽，最后合并，字段缺失率能降不少。

我之前做类似任务也踩过这坑，纯调prompt真不是万能的，输出格式乱套太常见了。建议先加个JSON Schema校验+重试机制，抽不齐的样本直接丢回给模型补一次，比反复改措辞省事。长文本确实得切，我按对话轮次分段抽，最后再合并，漏字段少很多。两步走也靠谱，先让模型判断有没有诉求，再抽具体内容，能明显减少空值。另外强烈建议试试函数调用功能，比纯文本输出稳太多了，基本不会乱格式。

试试拆成两轮，先判断有没有诉求再抽字段，空值率能降不少。另外加个正则校验兜底，格式乱了就重试一次。

分句拆着抽吧，我试过先抽诉求再抽结果，成功率明显高不少。

你这情况八成是长文本信息密度太高，切成小段再配合schema校验重试会稳很多。

这问题太真实了，我最近也在搞类似的，纯靠prompt确实会有漏网之鱼。建议你试试把长对话按轮次切块，每块只抽当前片段，最后再用一次调用合并结果，能少很多字段丢失。另外输出格式乱的话，可以加个简单的JSON schema校验，失败就自动重试一次，比反复调措辞管用。

其实对几百条样本这种量级，与其死磕GPT-4，不如考虑用个小模型做初筛，比如先分类成“有诉求”和“无诉求”，再让大模型只抽有诉求的那部分，成本低还稳。我试过温度0不是万能的，偶尔换一下顶层p值反而能纠正格式问题，你可以跑个对比看看。

还有个土办法，你few-shot里的示例尽量挑那些字段全、边界清晰的真实样本，别用自己编的，模型对真实语序的模仿力会强很多。另外如果字段老空，可能是“处理结果”这种隐性信息在对话里根本没出现，建议你在prompt里明确写上“若对话未提及则填null”，至少能让输出结构稳定，后面再靠规则补。

切分加两段式调用确实稳很多，先分类再抽取能少一半漏字段的情况。

我之前也踩过这坑，建议你抽完用正则校验下JSON格式，乱了自己重试一遍。

建议先切分对话轮次再按轮抽取，漏字段的用正则或规则补一遍，比死磕prompt靠谱多了。

实测两次调用真有用，先粗分类再细抽，能救回不少乱格式的样本。

这问题太真实了，我做过类似的活儿，最后发现prompt再调也就那样，纯靠它兜底不现实。你可以试试把长对话先按轮次切块，每块只抽当前片段，最后再合并去重，空字段率能降不少。还有一招是让模型先输出“抽不出来”的原因，再决定要不要二次追问，比硬逼着它给结果稳。至于格式乱，我后来都加一层JSON校验，失败了就自动重试一次，成本能接受。

这题我刚好踩过类似的坑，纯靠调prompt真容易到瓶颈。我的经验是分成两步走：先让模型判断这段对话里到底有没有“诉求”和“结果”，没有就直接返回一个固定标记，别硬抽；然后再对有内容的做细抽取，顺便加个JSON Schema校验，格式乱了就重试一次。长文本切分确实有效，但要注意按语义断句，切碎了反而会丢上下文。另外，如果数据里空值比例高，建议抽完用规则扫一遍，比如正则匹配“已处理”这类词，能兜回不少漏掉的。你用的GPT-4还是API版吗？温度0理论上稳定，但偶尔还是会抽风，可能跟系统prompt里隐含的随机性有关。

我之前做类似抽取也踩过这坑，纯靠prompt真的很难稳定。工程上建议加一层JSON校验加字段缺失检测，抽不出来就自动重试或者标记成待人工处理，别让坏数据直接流下去。另外长对话确实得先按轮次或意图切分，不然信息挤在一起模型容易漏。两次调用这思路我觉得靠谱，先粗分类再细抽，比一次硬啃要稳不少。你试过用函数调用或者response_format的json模式吗？那个对格式乱的帮助挺大。

我一般先切短再抽，长对话一锅端容易漏字段，两次调用反而稳。

先切分再抽取确实稳很多，长对话直接塞容易漏，我之前也踩过这坑。

这种抽取任务我踩过差不多的坑，后来发现纯靠调prompt确实有天花板。你可以试试把长对话先按轮次切块，每块单独抽再合并，空字段率会明显降下来。另外两次调用挺靠谱的，第一遍只让模型判断这段对话里有没有明确诉求，第二遍再针对性抽，比一次性搞定稳很多。还有个土办法，输出后加个校验层，字段缺失就触发重试并带上具体缺失项，实测能兜住不少漏网的。

我之前也踩过这个坑，光靠调Prompt确实有天花板。后来改成两步走：先让模型判断这段对话有没有明确诉求和结果，没有就直接跳过，有的话再单独抽字段，稳定了不少。另外长对话建议按轮次切一下，别一股脑塞进去，模型注意力会散。兜底的话可以加个校验层，JSON解析失败就重试一次，重试还不行就丢进人工队列。

我之前也踩过这个坑，后来发现光靠prompt确实很难做到100%稳定。你可以试试先让模型做一次意图分类，把明显没有诉求或结果缺失的对话过滤掉，再对剩下的做抽取。另外长对话最好按轮次切分，每段单独抽完再合并，比一次性塞进去靠谱得多。如果字段还是空，可以用二次调用专门追问“这段里有没有提到处理结果”，让模型只回答有或没有，比让它一次性输出JSON要稳。

我最近也踩过这个坑，后来发现光靠调Prompt确实有天花板。我的做法是改成两步：先让模型只判断这段对话里有没有诉求和结果，有就输出原文片段，没有就返回空，然后再单独调一次做字段归一化，稳定不少。另外长对话一定要切，超过一定token就按轮次拆开抽，最后再合并，不然模型注意力会散。还有个兜底是加个JSON schema校验，格式不对就重试一两次，比死磕提示词管用。

试试先让模型把对话里的关键句标出来再抽取，别指望一步到位，长文本确实该切。

这种半结构化抽取翻车太常见了，我也踩过类似的坑。有个思路你可以试试：先别指望一次调用把分类和抽取都搞定，改成两阶段，第一遍让模型判断这段对话到底涉不涉及可抽取的诉求，第二遍再专门做字段填充，这样能过滤掉不少本来就没什么可抽的样本。还有个问题容易被忽略，就是长对话里关键信息可能散在好几轮里，模型注意力会被稀释，按说话人或话题切一下再分别抽，最后合并，召回率通常能上来一截。格式乱的话，别硬靠prompt约束，直接上function calling或者JSON mode，让API层帮你兜住结构。空字段也可以让它显式输出“未提及”而不是留空，这样你能区分是真没有还是模型漏了。另外建议你抽一批bad case人工看一眼，很多时候不是prompt的问题，是任务定义本身有歧义，比如“处理结果”到底指客服说的还是最终实际解决的，模型自己都拿不准。