当 LLM 返回一段“看起来很认真、读起来全是废话”的文本时真正麻烦的不是“它不够聪明”而是我们很难用一条明确标准说清楚它到底哪里不对。这种感觉有一个越来越常用的词slop。它指的是生成内容里那些冗余、空洞、自我重复、充满模板套话的部分。“I fought the slop and I won”这个标题描述的就是一件事把 LLM 输出中的 slop 找出来、去掉并且用工程手段保证下次不再出现。这篇文章从一个实际场景出发你调用大模型拿到了一段 800 字的回答里面有大量“首先让我们来探讨”“综上所述”“值得注意的是”这类句子。你需要输出给用户、写入文档或进入下游系统但又不能直接删掉太多内容导致信息丢失。我会围绕“检测 slop - 分类 slop - 清理 slop - 验证效果 - 生产落地”这条主线给出可运行的规则库、Python 清洗管道、LLM 二次重写提示词和一套评估与排查方法。读完以后你可以用同样的思路处理内容生成、客服回复、代码注释和 agent 工具调用结果里的低质量输出。1. 先理解 slop 是什么以及它为什么随处可见1.1 从标题中的“I fought the slop”说起“I fought the slop and I won”是一种带调侃意味的说法。slop 最早在 AI 生成内容讨论中用来描述那种“看起来自然、实际上没有任何信息量”的文本。它区别于明显的语法错误或逻辑错误因为 slop 往往语法通顺、结构完整甚至读起来很正式但内容密度极低。举例来说原文“在当今快节奏的数字时代人工智能正在以多种多样的方式对我们的生活产生深远的影响。首先我们需要认识到人工智能已经无处不在。其次我们需要思考它带来的挑战和机遇。综上所述人工智能的未来值得期待。”这段文本没有数据、没有机制解释、没有具体案例也没有可执行结论。它只是把几个常见观点用连接词串起来。它就是典型的 slop。对开发者而言slop 的麻烦在于它不触发异常也不产生错误信息却能污染下游数据质量。如果 LLM 输出进入知识库、报表、在线文档或客服系统用户看到的是一大段徒增阅读成本的内容。因此“去 slop”不是口味偏好而是一个数据质量问题。1.2 slop 的成因训练目标和采样策略的副作用要理解 slop 为什么存在需要回到 LLM 生成文本的基本逻辑。模型在每一步生成下一个 token 时会根据当前上下文计算所有可能 token 的概率分布再按照采样策略挑选一个 token。训练目标鼓励模型输出“在人类语料中概率较高的文本”但人类语料本身就包含大量套话、过渡句和低信息密度段落。更麻烦的是强化学习对齐阶段通常会将“回答流畅、格式完整、态度礼貌”作为奖励目标的一部分。于是模型学会了生成“好的我们来分析一下”“首先从定义上看”“其次从实践角度看”“最后未来还需要关注”这类安全又顺滑的填充内容。在温度较高、top-p 较大时这种填充更容易被采样出来。理解这一点很重要因为去 slop 不能靠简单的“再完善一下提示词”。提示词确实能改善一部分现象但只要模型的采样空间里仍然存在大量模板化表达它就会在长文本、复杂指令和低约束任务中反复滑向 slop。工程上需要一层后处理来兜底。1.3 为什么“去掉啰嗦”不只是换一套提示词这么简单如果只是让输出更简洁确实可以在系统提示词里加上“不要使用套话保持简洁”。但实际项目里会遇到三个问题第一提示词只能约束生成倾向不能保证绝对满足。模型在长文本生成时仍然可能在中段滑回模板化表达。第二不同场景对 slop 的容忍度不同。面向 C 端用户的客服回复需要保留礼貌和温度写入数据库的摘要数据则希望越干净越好。一套提示词无法兼顾。第三提示词的效果很难回归验证。你改了一次提示词这一批输出变好了下一批不同主题的输出可能又出现新的套话。因此正规做法是把“去 slop”当成一条独立数据处理管道来看待先识别再分类再清理最后验证和回归。这样每一次规则变更都能用固定测试集评估不会出现“这次看着不错但不知道改了什么就变差了”的情况。2. 把 slop 分类才能用代码去检测和清理2.1 六类高频 slop 模式编写检测规则之前先要对 slop 做分类。分类的目的是让代码可以针对每一种模式做不同处理有些句子需要删除有些词需要替换有些段落需要与上下文合并。我整理了六类最常见模式类别特征典型示例建议处理方式开场问候与套话出现在开头不承载信息“好的首先让我们了解一下这个问题。”删除总结性废话出现在结尾重复前文观点“总而言之这个话题非常重要。”删除空洞修饰词高密度但无实际含义“非常”“极其”“在很大程度上”“值得注意的是”删除或替换为空自我指涉表达把模型自身行为当作内容“作为一个人工智能模型我不能提供具体建议。”删除或改写模板化过渡句用于衔接两个无关段落“接下来让我们深入探讨另一个方面。”合并段落或删除冗余解释对同一概念重复解释上一段已给出定义下一段又重新解释一遍保留第一次删除后续重复这六类并不是完全穷尽对大多数通用文本已经足够。实际项目里最好把分类扩展成自己的规则表每一条规则都对应一个正则或关键词集合。2.2 用关键词和正则建立第一版检测规则第一版规则不需要追求完美重点是能覆盖高频模式。下面是一个用于演示的 Python 规则库结构里面包含了规则名称、匹配模式、处理动作和优先级。# slop_rules.py SLOP_RULES [ { name: opening_platitude, patterns: [ r^好的?, r^首先?让我们(来)?(一起)?(深入)?(探讨|分析|看看|了解一下), r^在当今[^\n。]*?(时代|背景|环境)?下, ], action: remove_sentence, priority: 10, }, { name: closing_summary, patterns: [ r^(总而言之|综上所述|总的来说|总之|综上)?, r^(最后|最终),[^\n。]{0,30}(值得|重要|关键|期待), ], action: remove_sentence, priority: 10, }, { name: hollow_modifier, patterns: [ r非常(重要|关键|必要|有用|复杂), r极其(重要|关键), r在很大程度上, r值得注意的是, r毫无疑问, ], action: remove_phrase, priority: 20, }, { name: self_reference, patterns: [ r作为(一个)?(人工智能|AI|语言模型), r我是一个大语言模型, r作为(您的)?(助手|智能助手), ], action: remove_phrase, priority: 30, }, { name: transition_filler, patterns: [ r接下来?让我们, r然后?我们(可以)?(继续)?(来看|来分析), r下一步?我们将, ], action: remove_phrase, priority: 30, }, { name: redundant_explanation, patterns: [ r简单来说?, r换句话说?, r也就是说?, ], action: remove_phrase, priority: 40, }, ]这套规则库有几个设计点需要注意action区分删除整句和删除短语。删除整句风险更高需要更严格的匹配条件。priority用于决定处理顺序。高优先级规则先执行避免一个句子被重复处理多次。正则匹配要尽量避免匹配到正文中的真实内容。比如“总的来说”在某些技术结论里可能是有意义的一部分但开头位置出现时绝大多数是冗余表达。2.3 规则库的设计宁可错杀也要先控制误杀规则库开发里面最大的矛盾是“漏杀”和“误杀”之间的平衡。漏杀的意思是 slop 没被清理掉输出仍然冗长误杀的意思是正常的、有信息量的内容被删掉了造成信息丢失。实际经验是第一版规则宁可漏杀也要先控制误杀。原因很简单漏杀最多让文本长一点误杀会让内容出现事实缺失或逻辑断裂这种错误在文档和数据库中比冗长更严重。为了控制误杀每条规则最好满足两个条件匹配位置要限定。比如开场套话只匹配段落开头或句子开头不匹配句中。匹配范围要具体。不要写r重要这种一竿子打翻一船人的正则要写r非常重要或r具有重要意义。此外规则必须支持开关。在项目里我会把规则库定义成 JSON 或 YAML 配置文件而不是硬编码在代码里这样运营和测试人员也能按需调整。# slop_rules.yaml - name: opening_platitude enabled: true action: remove_sentence patterns: - ^好的 - ^首先?让我们 - name: hollow_modifier enabled: true action: remove_phrase patterns: - 非常(重要|关键) - 值得注意的是3. 搭建一条可运行的去 slop 管道3.1 清洗器的整体流程有了规则库之后就可以实现清洗管道。管道处理的输入是 LLM 返回的原始文本输出是清理后的文本以及一份处理报告。报告里记录哪些规则命中了多少次、删除了哪些句子这样后续排查时可以定位问题。整体流程按顺序完成把原始文本按段落拆开。每个段落按句号、问号、感叹号拆分成句子。对每一条句子执行规则检测。根据命中的动作删除句子或删除短语。合并过短的残留片段避免出现大量碎片。去掉连续空行返回清理结果和处理统计。这个流程的最大好处是每一层都可观测。规则命中的记录可以打印到日志也可以存到数据库方便后续分析哪一类 slop 在某个业务场景里出现最多。3.2 规则过滤与修复的 Python 实现下面给出一个最小可运行示例。这里使用re模块处理规则匹配使用dataclass保存清理结果。# slop_cleaner.py import re from dataclasses import dataclass, field try: import yaml except ImportError: yaml None from slop_rules import SLOP_RULES dataclass class CleanResult: clean_text: str removed_sentences: list field(default_factorylist) removed_phrases: list field(default_factorylist) rule_hits: dict field(default_factorydict) class SlopCleaner: def __init__(self, rulesNone): self.rules rules or SLOP_RULES def _load_rules_from_yaml(self, path): if yaml is None: raise RuntimeError(需要安装 PyYAML 才能加载 YAML 规则) with open(path, r, encodingutf-8) as f: data yaml.safe_load(f) return [r for r in data if r.get(enabled, True)] def _split_sentences(self, text): parts re.split(r(?[。!?])\s*, text) return [p.strip() for p in parts if p.strip()] def _match_rule(self, sentence): for rule in self.rules: patterns rule.get(patterns, []) for pattern in patterns: if re.search(pattern, sentence): return rule return None def clean(self, text): result CleanResult() if not text: return result paragraphs re.split(r\n{2,}, text) cleaned_paragraphs [] for para in paragraphs: sentences self._split_sentences(para) kept [] for sentence in sentences: rule self._match_rule(sentence) if rule is None: kept.append(sentence) continue action rule.get(action) rule_name rule.get(name) result.rule_hits[rule_name] result.rule_hits.get(rule_name, 0) 1 if action remove_sentence: result.removed_sentences.append(sentence) continue if action remove_phrase: new_sentence sentence for pattern in rule.get(patterns, []): new_sentence re.sub(pattern, , new_sentence) new_sentence re.sub(r\s, , new_sentence).strip() if new_sentence: result.removed_phrases.append( sentence[:50] ... ) kept.append(new_sentence) else: result.removed_sentences.append(sentence) cleaned_para .join(kept) cleaned_para re.sub(r\s{2,}, , cleaned_para).strip() if cleaned_para: cleaned_paragraphs.append(cleaned_para) result.clean_text \n\n.join(cleaned_paragraphs) return result if __name__ __main__: sample ( 首先让我们来分析一下人工智能在客服系统中的应用。\n\n 在当今快速发展的时代人工智能已经在很多领域发挥了重要作用。 值得注意的是客服机器人可以降低人工成本。 总而言之这种技术值得持续关注。 ) cleaner SlopCleaner() res cleaner.clean(sample) print(清理前) print(sample) print(\n清理后) print(res.clean_text) print(\n规则命中, res.rule_hits) print(删除句子, res.removed_sentences)这个实现中有几个关键点句子拆分采用中文标点。和英文标点!?实际项目还需要考虑和换行等边界。短语移除后需要重新拼接句子并压缩多余空格。中文文本中还要注意逗号可能残留下一版规则可以继续处理。删除句子后段内可能出现空段落所以需要在段落层面做一次空值检查。3.3 如何判断“这一段是否要彻底删除”规则库能处理句子级和短语级的 slop但有些段落整段都没有信息量。比如模型在回答中间插入“作为 AI我无法访问实时数据但根据我的训练数据我可以提供一个一般性的回答”。这种段落在某些场景下必须整段删除。判断逻辑不复杂核心是看段落中是否有实体词或动词性信息。可以统计段落中的中文字符数量、数字数量、英文字母数量、专业术语数量。如果实体词密度极低且句子全部是通用套话就判为可删除段落。# 一个简单可用的段落信息量判断函数 import re def score_paragraph_information(paragraph): chinese_chars len(re.findall(r[\u4e00-\u9fff], paragraph)) alpha_chars len(re.findall(r[A-Za-z], paragraph)) numbers len(re.findall(r\d, paragraph)) total max(len(paragraph), 1) info_score (chinese_chars alpha_chars * 2 numbers * 2) / total return info_score def should_remove_paragraph(paragraph, threshold0.3): score score_paragraph_information(paragraph) has_specific_term bool(re.search(rAPI|SDK|配置|函数|接口|错误|日志|版本, paragraph)) return score threshold and not has_specific_term这只是一个示例阈值。不同行业的文本密度差异很大实际项目需要先抽样一批真实输出统计段落得分分布再确定阈值。不要直接把示例里的0.3当作生产标准。3.4 用一段最小样本跑通验证运行上面slop_cleaner.py的示例会得到类似下面的输出清理前 首先让我们来分析一下人工智能在客服系统中的应用。 在当今快速发展的时代人工智能已经在很多领域发挥了重要作用。值得注意的是客服机器人可以降低人工成本。总而言之这种技术值得持续关注。 清理后 人工智能在客服系统中的应用。 人工智能已经在很多领域发挥了重要作用。客服机器人可以降低人工成本。可以看到开场套话、空洞修饰词和总结性废话都已经被处理。此时如果需要一个统一逻辑删除“人工智能已经在很多领域发挥了重要作用”这个仍然空洞的句子就需要引入语义判断而不是单纯的关键词规则。这正好是下一章模型层要做的事。4. 从规则到模型用 LLM 做二次重写与打分4.1 为什么要保留模型层而不是只靠正则正则规则擅长处理“出现频率高、表达相对固定”的套话。比如“综上所述”“首先让我们”这类表达即使表达有细微变化也可以通过多个正则变体覆盖。但模型生成的内容变化非常多同样一个空泛观点它可以有很多种伪装“这个话题引发了许多思考。”“这提醒我们要重视背后的价值。”“整体来看相关实践具有现实意义。”这些句子没有固定关键词正则几乎不可能全部覆盖。此时需要用 LLM 做语义级判断和重写。更合理的架构是两层配合规则层负责高频、低成本、确定性清理模型层负责低频、高语义、需要理解的清理。这样设计的好处是控制成本。如果每条输出都交给 LLM 重写成本和延迟都会明显上升。先用规则层去掉 80% 的明显 slop再让模型层处理剩余 20% 的语义级冗余整体开销是可以接受的。4.2 设计一个“去 slop 重写”的系统提示词模型层的核心是重写提示词。提示词必须给出明确的定义、目标、约束和示例。下面是一个可以用于中文内容的示例提示词模板。UNSLOP_SYSTEM_PROMPT 你是一名文本编辑。你的任务是把用户输入的内容改写成“高信息密度、低冗余表达”的版本。 你需要遵守以下规则 1. 删除开场问候语、总结套话、空洞修饰词、自我指涉表达。 2. 保留原文中的所有事实、数据、代码、专有名词、结论和逻辑关系。 3. 不要新增原文没有的观点、案例和数据。 4. 合并重复表达同一意思只保留一次优先保留更具体、更准确的句子。 5. 保持原文语气和结构除非原文中出现套话。 6. 如果原文本身就是简洁的直接输出原文不要改写。 输出要求 - 只输出改写后的文本不要输出解释、开头语或结束语。 - 不要使用“好的”“以下是为您改写的内容”这类表达。 在实际项目里我会在提示词中加入业务术语白名单和禁用词列表。比如客服场景要保留“抱歉”“很高兴为您服务”这类有服务价值的表达不能在去 slop 时把必要的礼貌用语也删掉。少样本示例也很重要。下面是一个三组示例的格式可以放入请求中{ messages: [ {role: system, content: 你是一名文本编辑。删除套话保留事实和数据。}, {role: user, content: 首先让我们来讨论一下数据库索引的重要性。在大数据背景下索引毫无疑问是提升查询性能的关键手段。总而言之我们需要认真设计索引。}, {role: assistant, content: 数据库索引是提升查询性能的关键手段需要认真设计。}, {role: user, content: 作为人工智能语言模型我可以告诉您Python 的 GIL 确实会影响多线程程序的并行执行能力。值得注意的是CPU 密集型任务受影响最大。}, {role: assistant, content: Python 的 GIL 会影响多线程程序的并行执行能力CPU 密集型任务受影响最大。}, {role: user, content: 接下来我们来分析 Spring 的 Bean 生命周期。简单来说一个 Bean 会经历实例化、属性填充、初始化和销毁这几个阶段。需要特别强调的是初始化阶段最容易出现配置错误。}, {role: assistant, content: Spring Bean 生命周期包括实例化、属性填充、初始化和销毁。初始化阶段最容易出现配置错误。} ] }设计的核心目标是让模型明确两点哪些东西必须删哪些东西不能删。如果不给约束模型往往会自作主张扩写或润色反而增加 slop。4.3 用评分提示词量化整段文本的 slop 程度清理之前最好先给文本打一个“slop 程度分”。这个分数有两个用途一是判断当前文本是否需要进入模型重写层二是作为回归集的量化指标用来对比清理前后的差异。评分提示词要输出 JSON避免每次让模型自由发挥。示例SLOP_SCORE_PROMPT 请对下面的文本进行冗余度评分评分范围 0 到 10。 0 表示完全没有套话信息密度高10 表示几乎全是空话和模板表达。 评分依据 - 是否存在开场问候语和总结套话。 - 是否存在空洞修饰词。 - 是否存在自我指涉表达。 - 是否存在重复解释和模板化过渡。 - 有效信息在全文中所占比例。 只输出 JSON {score: 0.0, reason: 一句话说明原因} 文本 {text} 可以设置一个阈值比如分数大于 4 才进入重写层。这样能避免把已经很干净的文本反复重写减少延迟和成本。阈值需要根据业务对输出质量的要求来调整面向外部文档时阈值可以调低内部处理时阈值可以调高。4.4 重写环节必须做的防信息丢失检查LLM 重写有一个隐蔽风险它可能把有用的细节一并删掉因为模型觉得“这句太细节了”。例如原文是“接口在 QPS 达到 2000 时P99 延迟从 50ms 上升到 320ms主要原因是线程池繁忙”模型可能重写成“高并发时接口延迟会升高”数据全丢了。为了避免这个问题重写前后需要做信息比对。比对可以从三个维度进行数字是否一致提取文本中的所有数字和单位比较重写前后是否一致。专有名词是否一致提取大小写混合词、品牌名、技术栈名、组件名比较前后是否一致。句子数量压缩比重写后句子数量不应比原文少到一个不可接受的程度。# info_preservation_check.py import re def extract_numbers(text): return set(re.findall(r\d(?:\.\d)?(?:%|ms|MB|GB|QPS|RPS)?, text)) def extract_terms(text): return set(re.findall(r\b[A-Za-z][A-Za-z0-9]*(?:-[A-Za-z0-9])*\b, text)) def check_preservation(original, rewritten): missing_numbers extract_numbers(original) - extract_numbers(rewritten) missing_terms extract_terms(original) - extract_terms(rewritten) return { missing_numbers: sorted(missing_numbers), missing_terms: sorted(missing_terms), passed: len(missing_numbers) 0 and len(missing_terms) 0, }如果检查没通过可以自动回退到原始版本或者把原始版本和重写版本一起交给人工确认。生产环境里这一层往往比“重写得好不好”更重要。5. 验证效果指标、回归集与人工抽检5.1 先定义可量化的指标没有指标就无法回答“去 slop 到底有没有效果”。建议从以下四个维度建立指标指标计算方式说明文本压缩率清理后字符数 / 清理前字符数反映冗余减少程度但需要结合信息保留情况slop 分值LLM 对文本的冗余评分0 到 10 分分数越低越好信息保留率重写前后数字、专有名词重合比例防止删除有效信息人工采纳率人工判断清理后文本是否可用最终业务效果指标压缩率不能单独使用。如果一段文本被压缩到原来的 10%看起来很好但关键参数全丢了这就不是高质量清理。所以压缩率必须与信息保留率一起看。5.2 构造一个迷你回归集回归集是固定的一组输入文本用来在每次修改规则或调整提示词后跑一遍效果测试。建议使用 JSONL 格式每条数据包含原始文本、期望清理结果、允许保留的实体词等字段。下面是一个 JSONL 示例{id: case001, category: opening, raw: 首先让我们来分析一下接口超时的原因。, expected: 接口超时的原因。, keep_entities: [接口, 超时]} {id: case002, category: data, raw: 当 QPS 达到 2000 时P99 延迟从 50ms 上升到 320ms线程池出现繁忙。, expected: 当 QPS 达到 2000 时P99 延迟从 50ms 上升到 320ms线程池出现繁忙。, keep_entities: [QPS, 2000, P99, 50ms, 320ms, 线程池]} {id: case003, category: closing, raw: 综上所述这项技术非常重要值得持续关注。, expected: , keep_entities: []}回归集不需要很大20 到 50 条足够覆盖主要 slop 类型。关键是要覆盖每一类规则和边界场景。每次修改规则后把回归集全部跑一遍对比指标和期望输出的差异就能发现新规则是否破坏了已有能力。5.3 对比清洗前后的输出效果下面是一段用于评估的脚本逻辑它读取 JSONL 回归集循环调用清洗管道并统计平均压缩率和 slop 分值变化。# evaluate.py import json from slop_cleaner import SlopCleaner from unslop_prompt import unslop_with_llm cleaner SlopCleaner() with open(regression_set.jsonl, r, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] total_before 0 total_after 0 score_before_sum 0.0 score_after_sum 0.0 for case in cases: raw case[raw] # 阶段一规则清理 rule_result cleaner.clean(raw) cleaned rule_result.clean_text # 阶段二LLM 重写生产环境中应该根据阈值触发 rewritten unslop_with_llm(cleaned) before_len len(raw) after_len len(rewritten) total_before before_len total_after after_len print(f{case[id]}: {before_len} - {after_len}, ratio{after_len / max(before_len, 1):.2f}) print(f\n平均压缩率: {total_after / max(total_before, 1):.2f})这里unslop_with_llm需要你用实际的模型 API 或本地模型推理封装。评估脚本的重点不是某个具体 API而是跑同一批固定样本输出可对比的结果。5.4 人工抽检评分卡自动化指标不能完全替代人工判断。建议在每次修改规则后抽取 20 条真实项目输出让两名编辑或开发人员填写评分卡。评分卡字段可以这样设计样本 ID是否保留关键信息是否存在语义断裂是否仍然有 slop是否可直接使用sample_001是否少量是sample_002否缺少 QPS 数据是无否人工抽检的价值在于发现自动化指标没有覆盖的问题比如语气过于生硬、上下文被切断、表格格式被破坏等。这类问题一旦发现应该回写成对应的检查规则或提示词约束逐步沉淀到管道中。6. 常见坑与排查链路6.1 高频坑位列表去 slop 管道开发过程里最容易踩到这几个坑。问题现象常见原因检查方式处理建议清理后句子读起来断裂删除短语后没有做标点修复和分词重排查看清理前后的相邻句子增加标点修复规则删除短语后补上逗号或句号关键数字被删掉正则规则匹配范围过大把包含数值的句子整句删除查看 rule_hits 日志和 removed_sentences删除整句之前检查句子中是否包含数字或专有名词LLM 重写后新增了原文没有的内容提示词未约束“不要新增内容”对比原文和重写后的实体词、数字在提示词中加强约束并运行信息保留检查同样的套话隔几天又出现规则库没有覆盖新的表达查看高频出现但未被命中的句子每天或每周分析一次未命中但被人工标记的样本补充规则清理管道把代码块里的英文注释误删规则没有区分代码块和正文检查带代码块样本在管道中先剥离代码块只处理后文清理后再拼回代码块评分分值波动大采用不同模型或温度参数不一致固定模型和采样参数为评分和重写任务固定 temperature0 或低随机参数6.2 从现象到根因的排查顺序当清理结果不符合预期时不要直接改规则先按顺序排查。第一确认输入是否正常。检查模型输出是否本身就包含 Markdown 代码块、表格、JSON 结构。如果管道把代码块当成普通文本处理后面的清理结果必然混乱。解决方式是先把代码块、表格和 JSON 片段提取出来不在其内部执行规则。第二确认规则命中情况。打开清洗器的rule_hits日志看清楚哪些规则被触发。如果输出变化不符合预期多半是某条规则匹配过宽。可以把removed_sentences打出来逐条确认删除是否合理。第三确认模型层是否介入。查看评分的输出分值和重写后的文本。如果评分低于阈值说明模型层没有处理那么文本里还残留语义级套话是正常的。此时调整提示词或降低阈值即可。第四确认信息保留检查结果。如果check_preservation没有通过很可能重写环节删掉了关键信息。这时候应该回退到原始文本并优化提示词示例让模型知道哪些内容必须保留。第五确认评估指标。把清理前后的文本放到回归集里跑一次查看压缩率、slop 分值和人工采纳率的变化。如果压缩率很低但人工采纳率也低说明规则过于激进需要放宽条件。7. 生产环境落地延迟、缓存与成本控制7.1 用缓存避免重复清洗在内容生成、客服问答、文档总结等场景中同一个问题可能被反复提问同一种文档模板也会反复生成类似内容。如果每次都走完整的“正则 LLM 重写”管道成本会非常高。一个简单策略是以模型输出的哈希值作为缓存 key。第一次生成后把清理结果保存后续相同输出直接读取缓存。import hashlib import redis r redis.Redis(hostlocalhost, port6379, db0) def generate_clean_output(raw_text, cleaner): digest hashlib.sha256(raw_text.encode(utf-8)).hexdigest() cache_key funslop:{digest} cached r.get(cache_key) if cached: return cached.decode(utf-8) clean_text cleaner.clean(raw_text).clean_text r.set(cache_key, clean_text, ex3600 * 24) return clean_text生产环境里还需要考虑缓存失效策略。如果规则库或提示词变化了旧缓存结果可能不再适用。这时可以在缓存 key 中加入规则版本号或提示词版本号例如unslop:v3:{digest}。7.2 流式输出场景如何处理很多 LLM 应用使用流式输出用户逐字看到内容生成过程。如果去 slop 管道是后置处理流式场景下没办法先输出完整文本再清理。这时有两种选择一种是在流式结束后对完整结果做清理但用户已经先看到原始内容体验不一致。另一种是在服务端先缓存流式响应到一定长度再分段处理。分段处理会遇到边界问题比如一个套话句子可能跨越两个缓冲区块单独清理每一段无法识别整句。实际项目中常见的折中方式是流式输出时只做正则规则的轻量过滤不调用 LLM 重写完整结果生成后再异步执行深度清洗并刷新数据库或文档中的最终版本。这样用户能第一时间看到内容生成过程后续内容又保持整洁。7.3 测试环境与生产环境的配置差异去 slop 管道在测试环境和生产环境需要考虑的指标并不相同。配置项测试环境生产环境是否启用 LLM 重写可以每句都重写方便看效果通过阈值触发只处理高分 slop 文本采样参数可调高温度观察更多表达方式temperature0 或低随机保证稳定性缓存可关闭避免影响调试必须开启并带版本号日志打印所有规则命中详情只记录抽样命中详情避免日志过大人工审核全量检查按比例抽检或仅检查异常样本回滚策略直接改代码重启使用规则版本号灰度发布并支持一键回退生产环境还有一个容易被忽略的点LLM 重写请求的失败处理。如果大模型 API 超时或返回格式错误不能让调用方直接收到失败的清理结果。建议对每次 LLM 重写设置超时和重试重试仍失败时回退到规则清理结果并记录告警。8. 最佳实践把去 slop 变成工程能力8.1 可以直接复用的检查清单每次修改规则或提示词之前照着下面这份清单检查一遍可以在很大程度上减少线上问题。[ ] 规则变更是否配套更新了回归集样例新增样例是否覆盖了新规则对应的 slop 类型[ ] 删除整句的规则是否检查了句子中的数字和专有名词是否有信息保留检查[ ] 代码块、表格、JSON 片段是否在清理前被剥离[ ] 短语删除后是否修复了标点和空格[ ] LLM 重写提示词是否明确“不要新增原文没有的内容”[ ] 重写后的信息保留检查是否通过[ ] 缓存 key 是否包含规则版本号[ ] 生产环境是否有 LLM 重写失败时的降级策略[ ] 评分阈值是否在真实输出样本上做过分布分析[ ] 清理管道的日志是否足够定位到“哪条规则删除了哪句话”这些不是一次性工作。规则库、提示词、回归集都需要持续维护。模型版本升级、业务领域切换、提示词改动都可能导致 slop 模式变化所以这套清单也要定期重新过一遍。8.2 扩展方向从内容生成到 agent 输出去 slop 不只是用于“把文章改短”。在 LLM agent 应用中这个问题会放大。Agent 调用工具后模型生成的总结通常会把结构化工具输出翻译成冗长自然语言反而损失了准确性。例如工具返回{status: 500, error: timeout}模型可能输出“服务端似乎遇到了一些问题看起来是请求处理超时导致的这种情况通常需要关注后端服务的负载情况”。这对程序消费方是灾难。针对 agent 场景更好的做法是让模型直接以结构化格式返回工具结果摘要而不是先去生成自然语言再清洗。如果确实需要自然语言摘要也要用严格的 schema 约束输出字段让每条输出都包含明确的字段名和值。去 slop 管道可以作为最后一道防线用来清理长文本回复、总结报告和记忆写入前的文本。另外可以考虑把去 slop 规则沉淀为团队内部可共享的资源。每个项目遇到的套话模式其实高度相似完全可以维护一套共享规则库和回归集让不同业务线在新项目时直接复用。这就是把一次性的“我打败了 slop”变成可复制、可持续的工程能力。回到文章开头说的那句话和 slop 的对抗不是一次性代码提交而是一套持续优化的数据处理流程。先建立分类体系再写规则和清洗管道然后用模型处理语义级冗余最后用指标和回归集守住质量边界。做到这一步面对 LLM 输出你就可以更有底气地说我已经赢了而且知道是怎么赢的。 
长河君 · 2026/8/29 2:20:07 · 阅读 1.2k 从规则到模型：构建LLM输出Slop清理管道
当 LLM 返回一段“看起来很认真、读起来全是废话”的文本时真正麻烦的不是“它不够聪明”而是我们很难用一条明确标准说清楚它到底哪里不对。这种感觉有一个越来越常用的词slop。它指的是生成内容里那些冗余、空洞、自我重复、充满模板套话的部分。“I fought the slop and I won”这个标题描述的就是一件事把 LLM 输出中的 slop 找出来、去掉并且用工程手段保证下次不再出现。这篇文章从一个实际场景出发你调用大模型拿到了一段 800 字的回答里面有大量“首先让我们来探讨”“综上所述”“值得注意的是”这类句子。你需要输出给用户、写入文档或进入下游系统但又不能直接删掉太多内容导致信息丢失。我会围绕“检测 slop - 分类 slop - 清理 slop - 验证效果 - 生产落地”这条主线给出可运行的规则库、Python 清洗管道、LLM 二次重写提示词和一套评估与排查方法。读完以后你可以用同样的思路处理内容生成、客服回复、代码注释和 agent 工具调用结果里的低质量输出。1. 先理解 slop 是什么以及它为什么随处可见1.1 从标题中的“I fought the slop”说起“I fought the slop and I won”是一种带调侃意味的说法。slop 最早在 AI 生成内容讨论中用来描述那种“看起来自然、实际上没有任何信息量”的文本。它区别于明显的语法错误或逻辑错误因为 slop 往往语法通顺、结构完整甚至读起来很正式但内容密度极低。举例来说原文“在当今快节奏的数字时代人工智能正在以多种多样的方式对我们的生活产生深远的影响。首先我们需要认识到人工智能已经无处不在。其次我们需要思考它带来的挑战和机遇。综上所述人工智能的未来值得期待。”这段文本没有数据、没有机制解释、没有具体案例也没有可执行结论。它只是把几个常见观点用连接词串起来。它就是典型的 slop。对开发者而言slop 的麻烦在于它不触发异常也不产生错误信息却能污染下游数据质量。如果 LLM 输出进入知识库、报表、在线文档或客服系统用户看到的是一大段徒增阅读成本的内容。因此“去 slop”不是口味偏好而是一个数据质量问题。1.2 slop 的成因训练目标和采样策略的副作用要理解 slop 为什么存在需要回到 LLM 生成文本的基本逻辑。模型在每一步生成下一个 token 时会根据当前上下文计算所有可能 token 的概率分布再按照采样策略挑选一个 token。训练目标鼓励模型输出“在人类语料中概率较高的文本”但人类语料本身就包含大量套话、过渡句和低信息密度段落。更麻烦的是强化学习对齐阶段通常会将“回答流畅、格式完整、态度礼貌”作为奖励目标的一部分。于是模型学会了生成“好的我们来分析一下”“首先从定义上看”“其次从实践角度看”“最后未来还需要关注”这类安全又顺滑的填充内容。在温度较高、top-p 较大时这种填充更容易被采样出来。理解这一点很重要因为去 slop 不能靠简单的“再完善一下提示词”。提示词确实能改善一部分现象但只要模型的采样空间里仍然存在大量模板化表达它就会在长文本、复杂指令和低约束任务中反复滑向 slop。工程上需要一层后处理来兜底。1.3 为什么“去掉啰嗦”不只是换一套提示词这么简单如果只是让输出更简洁确实可以在系统提示词里加上“不要使用套话保持简洁”。但实际项目里会遇到三个问题第一提示词只能约束生成倾向不能保证绝对满足。模型在长文本生成时仍然可能在中段滑回模板化表达。第二不同场景对 slop 的容忍度不同。面向 C 端用户的客服回复需要保留礼貌和温度写入数据库的摘要数据则希望越干净越好。一套提示词无法兼顾。第三提示词的效果很难回归验证。你改了一次提示词这一批输出变好了下一批不同主题的输出可能又出现新的套话。因此正规做法是把“去 slop”当成一条独立数据处理管道来看待先识别再分类再清理最后验证和回归。这样每一次规则变更都能用固定测试集评估不会出现“这次看着不错但不知道改了什么就变差了”的情况。2. 把 slop 分类才能用代码去检测和清理2.1 六类高频 slop 模式编写检测规则之前先要对 slop 做分类。分类的目的是让代码可以针对每一种模式做不同处理有些句子需要删除有些词需要替换有些段落需要与上下文合并。我整理了六类最常见模式类别特征典型示例建议处理方式开场问候与套话出现在开头不承载信息“好的首先让我们了解一下这个问题。”删除总结性废话出现在结尾重复前文观点“总而言之这个话题非常重要。”删除空洞修饰词高密度但无实际含义“非常”“极其”“在很大程度上”“值得注意的是”删除或替换为空自我指涉表达把模型自身行为当作内容“作为一个人工智能模型我不能提供具体建议。”删除或改写模板化过渡句用于衔接两个无关段落“接下来让我们深入探讨另一个方面。”合并段落或删除冗余解释对同一概念重复解释上一段已给出定义下一段又重新解释一遍保留第一次删除后续重复这六类并不是完全穷尽对大多数通用文本已经足够。实际项目里最好把分类扩展成自己的规则表每一条规则都对应一个正则或关键词集合。2.2 用关键词和正则建立第一版检测规则第一版规则不需要追求完美重点是能覆盖高频模式。下面是一个用于演示的 Python 规则库结构里面包含了规则名称、匹配模式、处理动作和优先级。# slop_rules.py SLOP_RULES [ { name: opening_platitude, patterns: [ r^好的?, r^首先?让我们(来)?(一起)?(深入)?(探讨|分析|看看|了解一下), r^在当今[^\n。]*?(时代|背景|环境)?下, ], action: remove_sentence, priority: 10, }, { name: closing_summary, patterns: [ r^(总而言之|综上所述|总的来说|总之|综上)?, r^(最后|最终),[^\n。]{0,30}(值得|重要|关键|期待), ], action: remove_sentence, priority: 10, }, { name: hollow_modifier, patterns: [ r非常(重要|关键|必要|有用|复杂), r极其(重要|关键), r在很大程度上, r值得注意的是, r毫无疑问, ], action: remove_phrase, priority: 20, }, { name: self_reference, patterns: [ r作为(一个)?(人工智能|AI|语言模型), r我是一个大语言模型, r作为(您的)?(助手|智能助手), ], action: remove_phrase, priority: 30, }, { name: transition_filler, patterns: [ r接下来?让我们, r然后?我们(可以)?(继续)?(来看|来分析), r下一步?我们将, ], action: remove_phrase, priority: 30, }, { name: redundant_explanation, patterns: [ r简单来说?, r换句话说?, r也就是说?, ], action: remove_phrase, priority: 40, }, ]这套规则库有几个设计点需要注意action区分删除整句和删除短语。删除整句风险更高需要更严格的匹配条件。priority用于决定处理顺序。高优先级规则先执行避免一个句子被重复处理多次。正则匹配要尽量避免匹配到正文中的真实内容。比如“总的来说”在某些技术结论里可能是有意义的一部分但开头位置出现时绝大多数是冗余表达。2.3 规则库的设计宁可错杀也要先控制误杀规则库开发里面最大的矛盾是“漏杀”和“误杀”之间的平衡。漏杀的意思是 slop 没被清理掉输出仍然冗长误杀的意思是正常的、有信息量的内容被删掉了造成信息丢失。实际经验是第一版规则宁可漏杀也要先控制误杀。原因很简单漏杀最多让文本长一点误杀会让内容出现事实缺失或逻辑断裂这种错误在文档和数据库中比冗长更严重。为了控制误杀每条规则最好满足两个条件匹配位置要限定。比如开场套话只匹配段落开头或句子开头不匹配句中。匹配范围要具体。不要写r重要这种一竿子打翻一船人的正则要写r非常重要或r具有重要意义。此外规则必须支持开关。在项目里我会把规则库定义成 JSON 或 YAML 配置文件而不是硬编码在代码里这样运营和测试人员也能按需调整。# slop_rules.yaml - name: opening_platitude enabled: true action: remove_sentence patterns: - ^好的 - ^首先?让我们 - name: hollow_modifier enabled: true action: remove_phrase patterns: - 非常(重要|关键) - 值得注意的是3. 搭建一条可运行的去 slop 管道3.1 清洗器的整体流程有了规则库之后就可以实现清洗管道。管道处理的输入是 LLM 返回的原始文本输出是清理后的文本以及一份处理报告。报告里记录哪些规则命中了多少次、删除了哪些句子这样后续排查时可以定位问题。整体流程按顺序完成把原始文本按段落拆开。每个段落按句号、问号、感叹号拆分成句子。对每一条句子执行规则检测。根据命中的动作删除句子或删除短语。合并过短的残留片段避免出现大量碎片。去掉连续空行返回清理结果和处理统计。这个流程的最大好处是每一层都可观测。规则命中的记录可以打印到日志也可以存到数据库方便后续分析哪一类 slop 在某个业务场景里出现最多。3.2 规则过滤与修复的 Python 实现下面给出一个最小可运行示例。这里使用re模块处理规则匹配使用dataclass保存清理结果。# slop_cleaner.py import re from dataclasses import dataclass, field try: import yaml except ImportError: yaml None from slop_rules import SLOP_RULES dataclass class CleanResult: clean_text: str removed_sentences: list field(default_factorylist) removed_phrases: list field(default_factorylist) rule_hits: dict field(default_factorydict) class SlopCleaner: def __init__(self, rulesNone): self.rules rules or SLOP_RULES def _load_rules_from_yaml(self, path): if yaml is None: raise RuntimeError(需要安装 PyYAML 才能加载 YAML 规则) with open(path, r, encodingutf-8) as f: data yaml.safe_load(f) return [r for r in data if r.get(enabled, True)] def _split_sentences(self, text): parts re.split(r(?[。!?])\s*, text) return [p.strip() for p in parts if p.strip()] def _match_rule(self, sentence): for rule in self.rules: patterns rule.get(patterns, []) for pattern in patterns: if re.search(pattern, sentence): return rule return None def clean(self, text): result CleanResult() if not text: return result paragraphs re.split(r\n{2,}, text) cleaned_paragraphs [] for para in paragraphs: sentences self._split_sentences(para) kept [] for sentence in sentences: rule self._match_rule(sentence) if rule is None: kept.append(sentence) continue action rule.get(action) rule_name rule.get(name) result.rule_hits[rule_name] result.rule_hits.get(rule_name, 0) 1 if action remove_sentence: result.removed_sentences.append(sentence) continue if action remove_phrase: new_sentence sentence for pattern in rule.get(patterns, []): new_sentence re.sub(pattern, , new_sentence) new_sentence re.sub(r\s, , new_sentence).strip() if new_sentence: result.removed_phrases.append( sentence[:50] ... ) kept.append(new_sentence) else: result.removed_sentences.append(sentence) cleaned_para .join(kept) cleaned_para re.sub(r\s{2,}, , cleaned_para).strip() if cleaned_para: cleaned_paragraphs.append(cleaned_para) result.clean_text \n\n.join(cleaned_paragraphs) return result if __name__ __main__: sample ( 首先让我们来分析一下人工智能在客服系统中的应用。\n\n 在当今快速发展的时代人工智能已经在很多领域发挥了重要作用。 值得注意的是客服机器人可以降低人工成本。 总而言之这种技术值得持续关注。 ) cleaner SlopCleaner() res cleaner.clean(sample) print(清理前) print(sample) print(\n清理后) print(res.clean_text) print(\n规则命中, res.rule_hits) print(删除句子, res.removed_sentences)这个实现中有几个关键点句子拆分采用中文标点。和英文标点!?实际项目还需要考虑和换行等边界。短语移除后需要重新拼接句子并压缩多余空格。中文文本中还要注意逗号可能残留下一版规则可以继续处理。删除句子后段内可能出现空段落所以需要在段落层面做一次空值检查。3.3 如何判断“这一段是否要彻底删除”规则库能处理句子级和短语级的 slop但有些段落整段都没有信息量。比如模型在回答中间插入“作为 AI我无法访问实时数据但根据我的训练数据我可以提供一个一般性的回答”。这种段落在某些场景下必须整段删除。判断逻辑不复杂核心是看段落中是否有实体词或动词性信息。可以统计段落中的中文字符数量、数字数量、英文字母数量、专业术语数量。如果实体词密度极低且句子全部是通用套话就判为可删除段落。# 一个简单可用的段落信息量判断函数 import re def score_paragraph_information(paragraph): chinese_chars len(re.findall(r[\u4e00-\u9fff], paragraph)) alpha_chars len(re.findall(r[A-Za-z], paragraph)) numbers len(re.findall(r\d, paragraph)) total max(len(paragraph), 1) info_score (chinese_chars alpha_chars * 2 numbers * 2) / total return info_score def should_remove_paragraph(paragraph, threshold0.3): score score_paragraph_information(paragraph) has_specific_term bool(re.search(rAPI|SDK|配置|函数|接口|错误|日志|版本, paragraph)) return score threshold and not has_specific_term这只是一个示例阈值。不同行业的文本密度差异很大实际项目需要先抽样一批真实输出统计段落得分分布再确定阈值。不要直接把示例里的0.3当作生产标准。3.4 用一段最小样本跑通验证运行上面slop_cleaner.py的示例会得到类似下面的输出清理前 首先让我们来分析一下人工智能在客服系统中的应用。 在当今快速发展的时代人工智能已经在很多领域发挥了重要作用。值得注意的是客服机器人可以降低人工成本。总而言之这种技术值得持续关注。 清理后 人工智能在客服系统中的应用。 人工智能已经在很多领域发挥了重要作用。客服机器人可以降低人工成本。可以看到开场套话、空洞修饰词和总结性废话都已经被处理。此时如果需要一个统一逻辑删除“人工智能已经在很多领域发挥了重要作用”这个仍然空洞的句子就需要引入语义判断而不是单纯的关键词规则。这正好是下一章模型层要做的事。4. 从规则到模型用 LLM 做二次重写与打分4.1 为什么要保留模型层而不是只靠正则正则规则擅长处理“出现频率高、表达相对固定”的套话。比如“综上所述”“首先让我们”这类表达即使表达有细微变化也可以通过多个正则变体覆盖。但模型生成的内容变化非常多同样一个空泛观点它可以有很多种伪装“这个话题引发了许多思考。”“这提醒我们要重视背后的价值。”“整体来看相关实践具有现实意义。”这些句子没有固定关键词正则几乎不可能全部覆盖。此时需要用 LLM 做语义级判断和重写。更合理的架构是两层配合规则层负责高频、低成本、确定性清理模型层负责低频、高语义、需要理解的清理。这样设计的好处是控制成本。如果每条输出都交给 LLM 重写成本和延迟都会明显上升。先用规则层去掉 80% 的明显 slop再让模型层处理剩余 20% 的语义级冗余整体开销是可以接受的。4.2 设计一个“去 slop 重写”的系统提示词模型层的核心是重写提示词。提示词必须给出明确的定义、目标、约束和示例。下面是一个可以用于中文内容的示例提示词模板。UNSLOP_SYSTEM_PROMPT 你是一名文本编辑。你的任务是把用户输入的内容改写成“高信息密度、低冗余表达”的版本。 你需要遵守以下规则 1. 删除开场问候语、总结套话、空洞修饰词、自我指涉表达。 2. 保留原文中的所有事实、数据、代码、专有名词、结论和逻辑关系。 3. 不要新增原文没有的观点、案例和数据。 4. 合并重复表达同一意思只保留一次优先保留更具体、更准确的句子。 5. 保持原文语气和结构除非原文中出现套话。 6. 如果原文本身就是简洁的直接输出原文不要改写。 输出要求 - 只输出改写后的文本不要输出解释、开头语或结束语。 - 不要使用“好的”“以下是为您改写的内容”这类表达。 在实际项目里我会在提示词中加入业务术语白名单和禁用词列表。比如客服场景要保留“抱歉”“很高兴为您服务”这类有服务价值的表达不能在去 slop 时把必要的礼貌用语也删掉。少样本示例也很重要。下面是一个三组示例的格式可以放入请求中{ messages: [ {role: system, content: 你是一名文本编辑。删除套话保留事实和数据。}, {role: user, content: 首先让我们来讨论一下数据库索引的重要性。在大数据背景下索引毫无疑问是提升查询性能的关键手段。总而言之我们需要认真设计索引。}, {role: assistant, content: 数据库索引是提升查询性能的关键手段需要认真设计。}, {role: user, content: 作为人工智能语言模型我可以告诉您Python 的 GIL 确实会影响多线程程序的并行执行能力。值得注意的是CPU 密集型任务受影响最大。}, {role: assistant, content: Python 的 GIL 会影响多线程程序的并行执行能力CPU 密集型任务受影响最大。}, {role: user, content: 接下来我们来分析 Spring 的 Bean 生命周期。简单来说一个 Bean 会经历实例化、属性填充、初始化和销毁这几个阶段。需要特别强调的是初始化阶段最容易出现配置错误。}, {role: assistant, content: Spring Bean 生命周期包括实例化、属性填充、初始化和销毁。初始化阶段最容易出现配置错误。} ] }设计的核心目标是让模型明确两点哪些东西必须删哪些东西不能删。如果不给约束模型往往会自作主张扩写或润色反而增加 slop。4.3 用评分提示词量化整段文本的 slop 程度清理之前最好先给文本打一个“slop 程度分”。这个分数有两个用途一是判断当前文本是否需要进入模型重写层二是作为回归集的量化指标用来对比清理前后的差异。评分提示词要输出 JSON避免每次让模型自由发挥。示例SLOP_SCORE_PROMPT 请对下面的文本进行冗余度评分评分范围 0 到 10。 0 表示完全没有套话信息密度高10 表示几乎全是空话和模板表达。 评分依据 - 是否存在开场问候语和总结套话。 - 是否存在空洞修饰词。 - 是否存在自我指涉表达。 - 是否存在重复解释和模板化过渡。 - 有效信息在全文中所占比例。 只输出 JSON {score: 0.0, reason: 一句话说明原因} 文本 {text} 可以设置一个阈值比如分数大于 4 才进入重写层。这样能避免把已经很干净的文本反复重写减少延迟和成本。阈值需要根据业务对输出质量的要求来调整面向外部文档时阈值可以调低内部处理时阈值可以调高。4.4 重写环节必须做的防信息丢失检查LLM 重写有一个隐蔽风险它可能把有用的细节一并删掉因为模型觉得“这句太细节了”。例如原文是“接口在 QPS 达到 2000 时P99 延迟从 50ms 上升到 320ms主要原因是线程池繁忙”模型可能重写成“高并发时接口延迟会升高”数据全丢了。为了避免这个问题重写前后需要做信息比对。比对可以从三个维度进行数字是否一致提取文本中的所有数字和单位比较重写前后是否一致。专有名词是否一致提取大小写混合词、品牌名、技术栈名、组件名比较前后是否一致。句子数量压缩比重写后句子数量不应比原文少到一个不可接受的程度。# info_preservation_check.py import re def extract_numbers(text): return set(re.findall(r\d(?:\.\d)?(?:%|ms|MB|GB|QPS|RPS)?, text)) def extract_terms(text): return set(re.findall(r\b[A-Za-z][A-Za-z0-9]*(?:-[A-Za-z0-9])*\b, text)) def check_preservation(original, rewritten): missing_numbers extract_numbers(original) - extract_numbers(rewritten) missing_terms extract_terms(original) - extract_terms(rewritten) return { missing_numbers: sorted(missing_numbers), missing_terms: sorted(missing_terms), passed: len(missing_numbers) 0 and len(missing_terms) 0, }如果检查没通过可以自动回退到原始版本或者把原始版本和重写版本一起交给人工确认。生产环境里这一层往往比“重写得好不好”更重要。5. 验证效果指标、回归集与人工抽检5.1 先定义可量化的指标没有指标就无法回答“去 slop 到底有没有效果”。建议从以下四个维度建立指标指标计算方式说明文本压缩率清理后字符数 / 清理前字符数反映冗余减少程度但需要结合信息保留情况slop 分值LLM 对文本的冗余评分0 到 10 分分数越低越好信息保留率重写前后数字、专有名词重合比例防止删除有效信息人工采纳率人工判断清理后文本是否可用最终业务效果指标压缩率不能单独使用。如果一段文本被压缩到原来的 10%看起来很好但关键参数全丢了这就不是高质量清理。所以压缩率必须与信息保留率一起看。5.2 构造一个迷你回归集回归集是固定的一组输入文本用来在每次修改规则或调整提示词后跑一遍效果测试。建议使用 JSONL 格式每条数据包含原始文本、期望清理结果、允许保留的实体词等字段。下面是一个 JSONL 示例{id: case001, category: opening, raw: 首先让我们来分析一下接口超时的原因。, expected: 接口超时的原因。, keep_entities: [接口, 超时]} {id: case002, category: data, raw: 当 QPS 达到 2000 时P99 延迟从 50ms 上升到 320ms线程池出现繁忙。, expected: 当 QPS 达到 2000 时P99 延迟从 50ms 上升到 320ms线程池出现繁忙。, keep_entities: [QPS, 2000, P99, 50ms, 320ms, 线程池]} {id: case003, category: closing, raw: 综上所述这项技术非常重要值得持续关注。, expected: , keep_entities: []}回归集不需要很大20 到 50 条足够覆盖主要 slop 类型。关键是要覆盖每一类规则和边界场景。每次修改规则后把回归集全部跑一遍对比指标和期望输出的差异就能发现新规则是否破坏了已有能力。5.3 对比清洗前后的输出效果下面是一段用于评估的脚本逻辑它读取 JSONL 回归集循环调用清洗管道并统计平均压缩率和 slop 分值变化。# evaluate.py import json from slop_cleaner import SlopCleaner from unslop_prompt import unslop_with_llm cleaner SlopCleaner() with open(regression_set.jsonl, r, encodingutf-8) as f: cases [json.loads(line) for line in f if line.strip()] total_before 0 total_after 0 score_before_sum 0.0 score_after_sum 0.0 for case in cases: raw case[raw] # 阶段一规则清理 rule_result cleaner.clean(raw) cleaned rule_result.clean_text # 阶段二LLM 重写生产环境中应该根据阈值触发 rewritten unslop_with_llm(cleaned) before_len len(raw) after_len len(rewritten) total_before before_len total_after after_len print(f{case[id]}: {before_len} - {after_len}, ratio{after_len / max(before_len, 1):.2f}) print(f\n平均压缩率: {total_after / max(total_before, 1):.2f})这里unslop_with_llm需要你用实际的模型 API 或本地模型推理封装。评估脚本的重点不是某个具体 API而是跑同一批固定样本输出可对比的结果。5.4 人工抽检评分卡自动化指标不能完全替代人工判断。建议在每次修改规则后抽取 20 条真实项目输出让两名编辑或开发人员填写评分卡。评分卡字段可以这样设计样本 ID是否保留关键信息是否存在语义断裂是否仍然有 slop是否可直接使用sample_001是否少量是sample_002否缺少 QPS 数据是无否人工抽检的价值在于发现自动化指标没有覆盖的问题比如语气过于生硬、上下文被切断、表格格式被破坏等。这类问题一旦发现应该回写成对应的检查规则或提示词约束逐步沉淀到管道中。6. 常见坑与排查链路6.1 高频坑位列表去 slop 管道开发过程里最容易踩到这几个坑。问题现象常见原因检查方式处理建议清理后句子读起来断裂删除短语后没有做标点修复和分词重排查看清理前后的相邻句子增加标点修复规则删除短语后补上逗号或句号关键数字被删掉正则规则匹配范围过大把包含数值的句子整句删除查看 rule_hits 日志和 removed_sentences删除整句之前检查句子中是否包含数字或专有名词LLM 重写后新增了原文没有的内容提示词未约束“不要新增内容”对比原文和重写后的实体词、数字在提示词中加强约束并运行信息保留检查同样的套话隔几天又出现规则库没有覆盖新的表达查看高频出现但未被命中的句子每天或每周分析一次未命中但被人工标记的样本补充规则清理管道把代码块里的英文注释误删规则没有区分代码块和正文检查带代码块样本在管道中先剥离代码块只处理后文清理后再拼回代码块评分分值波动大采用不同模型或温度参数不一致固定模型和采样参数为评分和重写任务固定 temperature0 或低随机参数6.2 从现象到根因的排查顺序当清理结果不符合预期时不要直接改规则先按顺序排查。第一确认输入是否正常。检查模型输出是否本身就包含 Markdown 代码块、表格、JSON 结构。如果管道把代码块当成普通文本处理后面的清理结果必然混乱。解决方式是先把代码块、表格和 JSON 片段提取出来不在其内部执行规则。第二确认规则命中情况。打开清洗器的rule_hits日志看清楚哪些规则被触发。如果输出变化不符合预期多半是某条规则匹配过宽。可以把removed_sentences打出来逐条确认删除是否合理。第三确认模型层是否介入。查看评分的输出分值和重写后的文本。如果评分低于阈值说明模型层没有处理那么文本里还残留语义级套话是正常的。此时调整提示词或降低阈值即可。第四确认信息保留检查结果。如果check_preservation没有通过很可能重写环节删掉了关键信息。这时候应该回退到原始文本并优化提示词示例让模型知道哪些内容必须保留。第五确认评估指标。把清理前后的文本放到回归集里跑一次查看压缩率、slop 分值和人工采纳率的变化。如果压缩率很低但人工采纳率也低说明规则过于激进需要放宽条件。7. 生产环境落地延迟、缓存与成本控制7.1 用缓存避免重复清洗在内容生成、客服问答、文档总结等场景中同一个问题可能被反复提问同一种文档模板也会反复生成类似内容。如果每次都走完整的“正则 LLM 重写”管道成本会非常高。一个简单策略是以模型输出的哈希值作为缓存 key。第一次生成后把清理结果保存后续相同输出直接读取缓存。import hashlib import redis r redis.Redis(hostlocalhost, port6379, db0) def generate_clean_output(raw_text, cleaner): digest hashlib.sha256(raw_text.encode(utf-8)).hexdigest() cache_key funslop:{digest} cached r.get(cache_key) if cached: return cached.decode(utf-8) clean_text cleaner.clean(raw_text).clean_text r.set(cache_key, clean_text, ex3600 * 24) return clean_text生产环境里还需要考虑缓存失效策略。如果规则库或提示词变化了旧缓存结果可能不再适用。这时可以在缓存 key 中加入规则版本号或提示词版本号例如unslop:v3:{digest}。7.2 流式输出场景如何处理很多 LLM 应用使用流式输出用户逐字看到内容生成过程。如果去 slop 管道是后置处理流式场景下没办法先输出完整文本再清理。这时有两种选择一种是在流式结束后对完整结果做清理但用户已经先看到原始内容体验不一致。另一种是在服务端先缓存流式响应到一定长度再分段处理。分段处理会遇到边界问题比如一个套话句子可能跨越两个缓冲区块单独清理每一段无法识别整句。实际项目中常见的折中方式是流式输出时只做正则规则的轻量过滤不调用 LLM 重写完整结果生成后再异步执行深度清洗并刷新数据库或文档中的最终版本。这样用户能第一时间看到内容生成过程后续内容又保持整洁。7.3 测试环境与生产环境的配置差异去 slop 管道在测试环境和生产环境需要考虑的指标并不相同。配置项测试环境生产环境是否启用 LLM 重写可以每句都重写方便看效果通过阈值触发只处理高分 slop 文本采样参数可调高温度观察更多表达方式temperature0 或低随机保证稳定性缓存可关闭避免影响调试必须开启并带版本号日志打印所有规则命中详情只记录抽样命中详情避免日志过大人工审核全量检查按比例抽检或仅检查异常样本回滚策略直接改代码重启使用规则版本号灰度发布并支持一键回退生产环境还有一个容易被忽略的点LLM 重写请求的失败处理。如果大模型 API 超时或返回格式错误不能让调用方直接收到失败的清理结果。建议对每次 LLM 重写设置超时和重试重试仍失败时回退到规则清理结果并记录告警。8. 最佳实践把去 slop 变成工程能力8.1 可以直接复用的检查清单每次修改规则或提示词之前照着下面这份清单检查一遍可以在很大程度上减少线上问题。[ ] 规则变更是否配套更新了回归集样例新增样例是否覆盖了新规则对应的 slop 类型[ ] 删除整句的规则是否检查了句子中的数字和专有名词是否有信息保留检查[ ] 代码块、表格、JSON 片段是否在清理前被剥离[ ] 短语删除后是否修复了标点和空格[ ] LLM 重写提示词是否明确“不要新增原文没有的内容”[ ] 重写后的信息保留检查是否通过[ ] 缓存 key 是否包含规则版本号[ ] 生产环境是否有 LLM 重写失败时的降级策略[ ] 评分阈值是否在真实输出样本上做过分布分析[ ] 清理管道的日志是否足够定位到“哪条规则删除了哪句话”这些不是一次性工作。规则库、提示词、回归集都需要持续维护。模型版本升级、业务领域切换、提示词改动都可能导致 slop 模式变化所以这套清单也要定期重新过一遍。8.2 扩展方向从内容生成到 agent 输出去 slop 不只是用于“把文章改短”。在 LLM agent 应用中这个问题会放大。Agent 调用工具后模型生成的总结通常会把结构化工具输出翻译成冗长自然语言反而损失了准确性。例如工具返回{status: 500, error: timeout}模型可能输出“服务端似乎遇到了一些问题看起来是请求处理超时导致的这种情况通常需要关注后端服务的负载情况”。这对程序消费方是灾难。针对 agent 场景更好的做法是让模型直接以结构化格式返回工具结果摘要而不是先去生成自然语言再清洗。如果确实需要自然语言摘要也要用严格的 schema 约束输出字段让每条输出都包含明确的字段名和值。去 slop 管道可以作为最后一道防线用来清理长文本回复、总结报告和记忆写入前的文本。另外可以考虑把去 slop 规则沉淀为团队内部可共享的资源。每个项目遇到的套话模式其实高度相似完全可以维护一套共享规则库和回归集让不同业务线在新项目时直接复用。这就是把一次性的“我打败了 slop”变成可复制、可持续的工程能力。回到文章开头说的那句话和 slop 的对抗不是一次性代码提交而是一套持续优化的数据处理流程。先建立分类体系再写规则和清洗管道然后用模型处理语义级冗余最后用指标和回归集守住质量边界。做到这一步面对 LLM 输出你就可以更有底气地说我已经赢了而且知道是怎么赢的。