讲LLM的应用开发绕不开文本概括。我做了几年内容处理类项目无论是新闻聚合、报告精简还是知识库整理文本概括几乎是最先被业务方点名要的功能。因为它的输入输出都是自然语言价值直观可见做成Demo的反馈周期也最短。而且一旦把概括这件事真正吃透你基本也就掌握了提示词工程里最核心的信息控制能力——怎么让模型抓重点、怎么掐长度、怎么保事实这一整套在后续做问答、做抽取、做写作辅助时全都用得上。这篇就把我在做文本概括任务时积累的提示词设计、参数配置、长文本处理方案以及调试过程中踩过的坑一并梳理出来当作一份可直接抄作业的实践笔记。1. 概括任务从设计到落地先想清楚的三件事很多开发者拿到概括任务第一反应是赶紧写提示词。我的建议是反过来先花几分钟想清楚下面三个问题再做。这能帮你省掉后面大量的返工和上线后的各种边界问题。1.1 提取式还是生成式这个选择题会影响整个方案文本概括的传统做法分两派提取式和生成式。提取式就是从原文里挑一些现成的句子拼起来本质是个排序问题生成式则是让模型读完原文后用自己的话重新组织出一段更短的文字。到了大模型时代提取式的短板很明显——摘出来的句子缺少衔接读起来像断线木偶而且关键信息如果散布在段落里而不是集中在某几个句子上提取式就很难覆盖。我见过不少同行一开始写概括提示词时下意识还是会走提取式的老路比如要求必须使用原文中的原句不许改写。这种强约束在某些场景是对的比如合同审查摘要或法律文书逐字引用能规避风险。但在大多数内容型业务里生成式明显更优因为它能在一个自然段里把分散的信息点揉成一个连贯结论信息密度更高可读性也更好。实操建议是把是否忠实原文做成软约束。提示词里写保持原意不变用自己的话概括同时补一条不要添加原文中没有的事实。这样既能拿到生成式的表达质量又用软约束把幻觉风险压住。只有合规审计、法务校验这类硬性场景才需要切回提取式思路。1.2 为谁概括目标读者直接决定摘要的详略和角度概括没有绝对的正确版本只有在特定读者眼中好用的版本。同样是某平台月度经营情况的一段长文给管理层看的摘要要突出风险、趋势和结论给一线运营看的摘要要保留数据明细和操作要点给外部客户看的摘要则要避开内部术语。这个差异模型是能感知到的前提是你明确告诉它读者是谁。所以我的提示词模板里永远留一个目标读者占位符。写法很简单就是一句请站在面向{{目标读者}}的角度进行概括。这句话加与不加输出的信息侧重差异非常明显。实测下来的效果是面向技术团队的摘要会自动保留接口名、数据口径这类词面向C端用户的摘要会自动把专业名词替换成大白话。不要觉得这是玄学。底层逻辑是模型在训练阶段见过大量针对不同人群的摘要样本它会根据你给定的读者标识自动匹配相似的表达习惯。读者人群这个信息对模型来说是一种非常强的风格与信息选择信号。1.3 长度控制不要只写50字以内要设计双重约束长度控制是概括任务里最容易被低估的环节。新手喜欢在提示词里写50字以内实际返回往往是45到70字飘忽不定中文场景尤其明显限得越死反而溢出越狠。我后来把长度约束改成双重规则。第一重是绝对范围控制在30到60个汉字之间给模型一个区间而不是单点数第二重是相对密度摘要长度约为原文的20%最低不低于15%最高不超过25%。双重约束的好处是给了模型两个锚点绝对范围管住极端溢出相对密度管住信息取舍时的比例感。还有一个细节不要每句都限制字数否则模型为了逐句压字数会把句子拆得支离破碎服务端感知到的就是摘要质量变差了。正确的做法是只限制总长度句子内部结构交给模型自己处理。2. 核心实操三种最常用的文本概括提示词模式想清楚上面的决策接下来就是动手写提示词了。下面三套是我在日常开发中反复在用、几乎没怎么改过的模式。它们各管一个场景可以单独用也可以组合。2.1 基础结构式概括适合短文本和高频调用短文本概括比如几百字的产品说明、一条新闻、一段会议纪实的压缩我用的是一个固定四段式结构你是一名资深编辑擅长信息提取与文字压缩。 请对下面这段文本进行概括保留核心事实、关键数据、因果关系。 输出要求 - 概括结果控制在80个汉字以内。 - 不要遗漏数字、专有名词、时间点。 - 不要添加原文不存在的任何信息。 文本如下 {{INPUT_TEXT}}这个结构里角色设定、任务描述、输出规则、输入内容四层分得很清楚。最难写的其实不是任务描述而是输出要求里那些具体指令。只说保留核心事实模型会在自由发挥和逐字搬运之间摇摆一旦补上不要遗漏数字、专有名词、时间模型对信息保留的优先级就有明确的标尺了。这个模式的优点是稳定缺点是不够灵活。遇到那种信息高度浓缩的文本比如一段包含十几个并列数据的通报保留核心事实会显得原则有余、颗粒度不足。所以我又在输出要求里加了一条如果语义密度过高允许使用分号和小标题来组织信息效果好了不少。2.2 面向长文本的分块概括Map-Reduce思路在文本上的落地长文本概括比如几万字的研究报告、一整个章节的文档直接整段丢给模型是不现实的。一方面超出上下文窗口会被截断另一方面就算勉强塞进去注意力也会偏向开头和结尾中段信息大面积丢失。我现在的做法是三步走。第一步切块按标题、章节或者自然段边界每块控制在1500到2500字左右。切块时别按字节硬砍要保留段落标题和列表符号这样模型对每一块的上下文结构理解会好很多。第二步对每块单独做一次详细摘要这次压缩比不要太高先压到原文本的50%左右目的是尽可能保留细节线索。第三步把所有小块摘要拼接起来再喂给模型做一次全局概括这次再压到目标长度。有人觉得这个流程太繁琐我问过一个更省事的替代方案直接把长文丢进去然后指定总结全文如果模型窗口够大是不是也行。实测下来的结论是窗口够、不报错但效果明显差于分块再合并。原因在于模型窗口虽大注意力分配却不均匀。分块后每块都是独立文本模型对每一段都是从头读到尾的完整关注覆盖率远高于一次读完长文。这个模式本质就是Map-Reduce把大任务拆成可处理的小块逐块处理后再归并。2.3 带信息抽取的泛化摘要让概括结果直接进下游系统很多时候概括的目的不只是给人读而是为了喂给下游的数据库、告警系统或者运营后台。这种场景我强烈建议把概括和结构化抽取合并到一次调用里完成。你是一个信息整理助手。请从下面的文本中提取以下内容 1. 核心事件用一句话概括主要事件。 2. 关键时间出现的时间点列表用顿号分隔。 3. 涉及对象人名/机构名列表用顿号分隔。 4. 量化数据所有数字及其含义用数字含义的格式列出。 5. 摘要全文不超过60个汉字的全文概要。 文本如下 {{INPUT_TEXT}}这种模式的价值在于一次调用既拿到了可读摘要又拿到了结构化字段。返回结果可以直接解析成JSON写入存储不需要再写一堆正则去做实体抽取。实测中这个模式还带来一个副产品因为模型必须完成字段提取它对全文的理解深度会明显强于单纯写摘要。字段越多模型的全局理解越扎实摘要质量也会跟着提升。我猜测这可能和多任务学习互相增强有关提示词层面的多任务设计确实能改善单任务的输出质量。3. 参数调优与可靠性增强光有提示词还不够提示词写好了调用参数设置不对输出照样翻车。概括任务对参数比较敏感下面把几个关键参数在这个场景下的表现掰开讲清楚。3.1 低温还是高温概括任务里Temperature怎么设概括从语义上讲是个信息压缩任务理论上每次都应该产出稳定一致的结果。所以我一般把Temperature压到0到0.3之间。温度一高模型每次给同一段文本生成的摘要会在信息取舍上出现随机波动有时保留了这个数字有时丢了那个时间这对线上稳定复现是非常致命的问题。很多人以为Temperature只影响创造性不影响事实性。实际影响更大的是它对信息选择策略的扰动。同一个文本温度0.8时两次输出的摘要甚至可能在观点倾向上出现偏差。如果你的概括结果还要进入报表或审计链路直接把Temperature设为0是最省心的选择。Frequency penalty我一般设0.3左右防止模型为了凑字数不断重复某种句式。Top-p通常不动保持默认。这类设定不是死规矩但概括任务确实属于低随机性任务整体策略就是让模型尽最大可能确定地工作。3.2 JSON结构化输出省掉解析头痛但要注意转义坑如果结果要进数据库建议让模型直接输出JSON。请以JSON格式输出字段如下 {summary: 摘要文本, operator: 主要对象, period: 时间范围}支持JSON模式的模型对这类指令的遵从度很高基本能保证被标准解析器读取。但JSON模式有个副作用为了满足结构约束模型在生成摘要文本时如果摘要里含有引号、反斜杠、特殊符号容易出现转义错误轻则丢字符重则整个字段解析失败。我的处理办法是在解析JSON之后对summary字段统一做一次清洗把常见转义异常替换掉再去使用。还有一种做法是要求模型在summary内部不使用任何引号用书名号代替某种程度能减少转义出错。3.3 让模型先思考再写轻量级Chain-of-Thought在概括里的应用即使只需要一小段摘要也值得让模型先分析再输出。请先分析文本的要点结构确定最有信息量的3-5个核心信息点再基于这些信息点进行概括。加了这句之后概括结果的信息密度会有明显提升隐含观点保留得更好。原因也好理解直接压缩时模型走的是直觉生成路径容易把高频词、开头句当成重要信息先指定分析要点时模型切换成分析生成路径相当于先做了一次信息筛选再组织语言。这个技巧值得放进所有概括类提示词里。代价仅仅是响应时间略微增加换来的是更高的信息覆盖率性价比非常高。如果你的场景对延迟极其敏感可以把分析过程放在缓存里比如对同一文本只做一次分析并缓存要点后续再基于要点反复生成不同长度的摘要。4. 常见问题与实战排查这些坑我替你们踩过了做文本概括功能落地早晚会遇到下面几类问题。每一个我都实际碰到过这里把排查思路和解决方法整理出来。4.1 摘要里出现了原文没有的内容这是概括任务最典型的幻觉表现模型在摘要中加入了原文完全没有的数据或事件。排查这件事第一步不是改提示词而是检查输入本身。我遇到过一次很隐蔽的问题长文本切块时按字节硬切把一句话从中间断开模型看到的是残缺语义于是脑补了后半句。这个源头不解决提示词怎么加约束都没用因为模型确实在帮它眼里看到的完整文本补充内容。排除输入问题之后再去提示词里加强约束。我现在会用一条硬性规则如果你在原文中找不到对应依据不要补全输出未提及。不过要提醒一句这条规则会牺牲摘要的流畅度只适用于对事实准确率要求极高的场景比如事故事件报告、医疗信息摘要。日常内容型场景还是推荐用软约束来控制幻觉。4.2 输入太长模型静默截断后半段被无视某些模型在输入超限时不会报错而是默默把超出的部分截掉。这种静默截断防不胜防你以为模型在总结全文实际上它只看了前半段输出结果看上去还挺合理很难第一时间发现问题。我的排查习惯是在上游传入模型前主动打印输入长度和实际截取位置把日志留出来。一旦发现输入接近窗口上限就按段落边界做平滑切分。切分时不要硬按字节数砍按标题、段落标记分保证每块语义完整。分块后可以让模型对每块先做一个一句话概要然后再合并这些概要能有效降低截断带来的信息损失。4.3 摘要风格上线一段时间后逐渐变了系统跑了一阵子有人反馈摘要风格好像从偏正式变成了偏口语。先别急着怀疑提示词被误改更常见的原因是底模版本悄悄更新了或者调用代码里漏传了temperature参数导致默认值变化。为了应对这类隐性回归最好的办法是建立固定的基准测试集。我自己的做法是留80条文本作为基准集每周跑一次自动对比看长度偏差、关键词覆盖率以及原文有而摘要无的反向检查。概括任务的好处是结果相对可量化不像问答任务那样难评价。有这个测试集在改版之前先跑一遍基准心里有底再上线。4.4 单轮调用还是多轮调用性能和准确率的取舍如果你的场景是先抽取再概括这种多步骤任务需要考虑是放在一轮里完成还是拆成两轮。单轮调用延迟低、成本省但模型要同时兼顾两个目标各步骤的执行力会被稀释。多轮调用让模型每轮只做一件事准确率有保障比如第一轮做结构化抽取第二轮基于抽取结果做概括。代价是响应时间翻倍、Token消耗变多不过中间结果可以缓存比如同一文本的抽取结果可以被复用。我现在的一般原则是追求实时性的场景用单轮综合提示词追求准确率、且文本内容相对固定的场景用多轮。实际项目中两者结合的情况很多——先单轮跑过滤遇到高频或重要文本再触发多轮精算成本能控住质量也达标。5. 文本概括的边界与可扩展方向入门的终点是另一个起点课时7虽然顶着入门两个字但文本概括的能力边界不止于压缩文字这一件事。我自己在项目里已经把这套能力扩展到了好几个方向简单说说。第一个方向是业务定制化概括。同样是概括舆情监控要的是立场中性、事件要素齐全财报分析要的是趋势判断、风险提示客服工单要的是问题分类和紧急程度判断。提示词结构可以复用但信息选择策略完全不同。这说明概括能力的核心本质不是压缩而是按照预设的目标对信息做取舍。第二个方向是摘要的摘要。长文档经过多轮概括后信息衰减是必然的。如果业务上需要极高准确率可以设计分层质控机制先分块摘再做楼层摘要最后让模型自查一次摘要是否覆盖了全文所有关键结论。这个办法在知识库场景里解决了很多摘要漏点的问题。第三个方向是评估体系。概括质量看起来主观但接到业务里之后长度、延迟、成本都是硬指标。我会记录每条摘要的输出长度、首Token延迟和每次调用的Token消耗按月画趋势。数据能很快定位问题是出在提示词、模型版本还是输入源这也是文本概括这种看似简单的任务真正走向工程化的必经之路。我个人在实际操作中的体会是文本概括是LLM应用里少有的成本低、见效快、但上限很高的任务。把提示词的四段式结构、双重长度约束、分块合并机制、结构化输出这四板斧吃透你已经能解决绝大多数业务里的概括需求。这也是我从这个课时里拿到的最有价值的收获——不是某个神奇提示词而是那套面对任意文本都能有章法的处理框架。