年初DeepSeek大模型火爆以后，各行各业都在加速建设AI相关的场景，媒体行业无疑是大模型场景适配较好的一个行业。大模型凭借强大的内容生成能力，可以深度渗透内容生产的全链路环节，从热点事件的智能抓取、新闻稿件的快速生成，文章智能校对、个性化润色，大模型几乎可以重构传统内容生产流程。
而实际在支持媒体客户落地大模型场景时发现，传统媒体不仅缺专业大模型工程团队，更缺对大模型的认知，主要表现在：
面对媒体行业在大模型落地过程中的挑战，有效的解法是选择一个切入点，推动客户完成一个大模型应用场景的落地。不仅有利于高层建立对大模型的理性认知，也能让一线编辑团队感受到大模型带来的便利性，而非直接的革命性。本人有幸深度参与某媒体客户的大模型建设，在项目初期与客户选定“文章校对”这一内容生产中的关键环节作为突破口，成功验证价值后，逐步拓展更多场景。接下来将结合该实践案例，总结媒体行业文章校对智能体建设方案，希望为媒体客户建设大模型者提供一些实践参考与思路启发。
文章校对是媒体行业内容生产过程中必备的环节，通俗来讲主要是检查并修正文章中存在的错误，确保文章符合准出标准。按照实际内容生产校对经验，一般校对规则大致分为四种类型。基础规范类，涉及内容准确性、标点符号、格式结构和逻辑问题，错误率最高且普遍存在，主要依赖编辑人员经验判断；合规风险类，聚焦政治安全合规，容忍度极低，需实时跟进政策变动（如官员职称、敏感表述等），对时效性和敏感性要求严苛；内容差异类，针对特定关键词和专业名词替换，因媒体属性或语境不同需差异化处理，通过维护专属关键词词典确保表述一致性；语言特色类，涉及中文特色的“的得地”用法、英文时态等语法特性，需领域专业的编辑人员才能快速修正。常见的文章校对项如下：
在客户的实际业务中，文章校对采用分团队、分维度模式，例如内容准确性、格式规范、特定内容替换等均由独立团队专项负责，需人工多轮逐条核对，存在流程冗长、效率滞后及人力成本高的痛点。
文章校对智能体方案采用三层架构设计，涵盖业务层、智能体层和模型层。业务层聚焦规则定义，按照业务逻辑将校对规则划分为四大类：基础规则类、合规风险类、内容差异类和语言特色类；智能体层作为核心处理层，针对不同业务规则精准施策：通过Prompt工程实现通用规则校对，借助RAG知识库融合领域知识解决专业术语和复杂逻辑问题，最后利用MCP服务完成实时规则的动态校对；模型层则依托公共云百炼平台，根据业务场景选择适配的模型作为基座，同时通过领域知识的模型微调技术，进一步深化特定场景下的校对能力，确保模型输出的专业性与准确性：
文章校对中的基础规则、合规风险规则、内容差异规则和语言特色规则校对各具特点，会采用不同技术路径实现校验：基础规则聚焦基础语言规范，如语法结构、拼写错误、标点符号等，具有广泛适用性，其特点在于规则普适性强、错误类型标准明确，可直接通过大模型强大的自然语言识别能力进行校对；内容差异规则针对特定行业（如法律、医学、金融等）的术语准确性，依赖领域知识体系，需要给大模型提供私有知识库（如法律条文、医学词典、行业标准等）来实现校对；合规风险规则强调实时性，要么是实时发生的新闻事件，要么是一些动态变化的规则，需借助MCP服务完成；语言特色规则依赖大模型对语言的支持能力，普通话基本都没问题，但对于常见的粤语和英语，很多时候需要通过模型微调来实现规则校对。
智能体搭建
媒体行业文章校对智能体主要由prompt + RAG + 实时MCP三大块组建完成，其中大部分校对规则通过有效的prompt工程都可以实现，部分规则需配合RAG知识增强和实时MCP服务，最终通过自动化评测能力来不断优化模型效果：
Prompt工程
文章校对智能体的 Prompt 工程，不仅需遵循常规 Prompt 设计的基本原则——如明确任务目标、结构化输出框架、提供清晰指令与示例，还需特别关注校对场景下的两大常见问题：规则遗忘和规则冲突。
规则遗忘
从智能体建设方案来看，文章校对场景涉及规则较多，叠加RAG文档后，输入大模型的知识量很容易达到万字符以上。这种长本文输很容易导致模型对部分规则产生“遗忘”。为确保核心高优先级规则的稳定性，需针对性优化输入策略，常见方案如下：
关键规则重复强调：在Prompt开头、中段、结尾多次强调核心规则（如“数据脱敏”“合规性”），用特殊标记（<!CRITICAL>）强化优先级。
注意力引导与结构化约束：在规则前添加权重指令（如[重要性: 5/5]），或用思维链（Chain-of-Thought）引导模型显式检查规则："先回顾规则列表 → 分析输入内容 → 输出前逐条验证是否违反规则X、Y、Z"。
分层注意力机制：即将多个校验规则拆解为独立的智能体，每个智能体负责执行单一规则，多个智能体并行处理，完成后统一汇总结果。在实际应用中，需重点关注规则拆分的独立性，避免因规则耦合导致结果汇总会出现重复修改或冲突。
规则冲突
多个校对规则在文章校对过程中可能产生冲突，导致同一语句被多次修改，甚至出现“先改对、后改错”的情况。例如，内容准确性规则与敏感词规则之间可能存在矛盾：敏感词规则要求将包含“死亡”的表述替换为“去世”或“离世”，以规避情绪敏感风险；而内容准确性规则则强调，在医学语境中必须使用规范、客观的术语，不得随意替换专业表达。例如句子：“新研发的抗癌药物在临床试验中显著降低了晚期癌症患者的死亡率，为患者提供了更多生存机会”，“死亡率”是标准医学术语，若被强制替换为“去世率”或“离世率”，不仅不符合专业习惯，反而会造成语义偏差。因此，该处不应执行敏感词替换，应优先保障内容准确性。那针对这类规则冲突，常见方案为：
RAG知识库建设
在文章校对场景中，RAG检索增强技术主要识别文本中的特定关键词或敏感词并进行替换，这类知识库通常为纯文本，例如一些常见的术语表、禁用词库、同义词映射或行业规范等，一般不会存在图片或视频等。因此，在RAG知识库建设时，需重点关注两个环节：首先是知识库的导入形式，需根据原始数据特征选择结构化（如数据库、表格）或非结构化（如文档、段落文本）的组织方式；其次是知识库参数配置，例如embedding模型、ReRank模型、相似度阈值配置和召回数量配置等。
结构化知识库
关于结构化和非结构化知识库的差异和使用场景如下表格，文章校对场景中，如需针对已经特定明确的关键词替换，例如将“an apartment” 替换称为“a flat”，无需语义理解，推荐结构化知识库，如需分析原文中是否包含特定说法一类的词替换，且这类说法无法穷举，推荐使用非结构化数据。大多数情况下，推荐结构化知识库。
知识库参数配置
以下介绍文章校对场景过程中需要注意的几个参数配置，未介绍的配置可参考百炼的默认值，如ReRank模型、最大分段长度和最大召回片段等参数：
向量模型：当前百炼默认选中的是DashScope text-embedding-v4新版本，支持多语言语义切片，精度更高（MTEB-R 得分 63.39），适用于语义理解的场景。而对于文章校对关键字检索的场景时，推荐使用DashScope text-embedding-v2，下文项目实践过程中有具体案例说明。
相似度阈值：百炼默认0.2，文章校对场景很多时候是基于关键字精确字段匹配，建议配置为0.4～0.5。
参与检索索引配置：结构化数据导入后，百炼平台默认将所有字段配置为参与检索状态。该配置主要用于RAG关键词匹配召回环节——RAG采用双路召回机制，结合关键词匹配与语义匹配两种检索路径，以提升召回的全面性与准确性。当字段的“参与检索”开关开启时，该字段内容将在检索中被纳入关键词匹配范围。但需特别注意的是，如果该字段不包含需替换的关键术语，建议关闭其检索开关，否则干扰关键词精准匹配，影响RAG召回率。
模型效果评测
评测标准
模型效果评测实际上就是看文章中总共有多少处错误，模型找出来了多少处错误，类似于“大家来找茬儿”的游戏。这类效果评估可参考信息检索评估方式。信息检索最常见的评测方式一般分为无序结果集指标和有序结果集指标两类，文章校对场景属于那种无序结果集，常见的测评指标主要是精确率（Precision）与召回率（Recall）以及F值（F-Measure）：
精确率：返回结果中相关文档的比例，计算公式为：
例如一篇需要校对的文章中需要校对的总数有10处，其中8处是正常校对，那精确率为80%。
召回率：检索到的相关文档占所有相关文档的比例，计算公式为：
例如一篇需要校对的文章中，通过大模型完成校对的总数有10处，而实际正确校对的有8处，那么召回率为80%。
F1值：精确率与召回率的等权重调和平均值，公式为：
在文章校对大模型的应用场景中，F1值的合理范围需结合任务类型、数据复杂度及行业标准综合评估。根据不同场景，建议采用差异化标准：
测评方法
下面介绍一种简易的自动化测评方式，通过Excel文件和Python脚本来实现。整个过程分为三步：
Excel准备：准备好一个用来记录原始文本和结果的Excel，共四列。包括Original Text（原始本文）、Input Text（错误注入后的本文）、Output Text（大模型校对后的文本）和Notes（记录大模型执行结果情况）；
大模型执行：在Excel中准备好需要校对的原始数据，原始文本通过大模型校对以后，将校对结果补充到上述Excel中。如果用百炼来完成大模型调用则需手动补充excel，如通过代码工程调用模型API则可以实现Excel自动化填充；
结果评测：通过python脚本读取 Excel中的字段进行F1计算，核心代码如下：
def process(data, checklist, out_file): """ 处理文本校对评估数据，计算召回率、精确率和F1分数 Args: data: 包含样本数据的列表 checklist: 每个样本中错误词及其正确形式的映射 out_file: 输出文件路径 """ mistake_all = 0 detect_all = 0 correct_all = 0 output = []
for i in range(len(data)): print(f"\n===== Test Sample {i} =====") response = extract_response(data[i]["response"]) mistake_cnt = len(checklist[i]) mistake_all += mistake_cnt detect_cnt = 0 correct_cnt = 0
for key in checklist[i]: correct_word_count = sum(data[i]["correct"].count(word) for word in checklist[i][key]) sample_mistake_count = data[i]["sample"].count(key) correct_mistake_count = data[i]["correct"].count(key) sample_correct_count = sum(data[i]["sample"].count(word) for word in checklist[i][key]) conditions_met = ( correct_word_count == 1and sample_mistake_count == 1and correct_mistake_count == 0and sample_correct_count == 0 ) ifnot conditions_met: error_info = ( f'{i}, {key}, {checklist[i][key]}, {correct_word_count}, ' f'{sample_mistake_count}, {correct_mistake_count}, {sample_correct_count}' ) print(error_info) assert False, error_info
for mistake in checklist[i]: correct_words = checklist[i][mistake] if response.count(mistake) == 0: detect_cnt += 1 else: print(f"Mistake not detected for: {mistake}.") correct_occurrences = sum(response.count(word) for word in correct_words) if correct_occurrences == 1: correct_cnt += 1 else: print(f"{mistake} should be corrected to: {correct_words}.")
detect_all += detect_cnt correct_all += correct_cnt recall = correct_cnt / mistake_cnt if mistake_cnt > 0else0 precision = correct_cnt / detect_cnt if detect_cnt != 0else0 f1 = 2 * (precision * recall) / (precision + recall) if (precision + recall) != 0else0 print(f"{mistake_cnt} mistakes, detect {detect_cnt}, correct {correct_cnt}, f1_score: {f1}") output.append([ data[i]["correct"], data[i]["sample"], data[i]["response"], recall, precision, f1 ])
recall_micro = correct_all / mistake_all if mistake_all > 0else0 precision_micro = correct_all / detect_all if detect_all != 0else0 f1_micro = 2 * (precision_micro * recall_micro) / (precision_micro + recall_micro) if (precision_micro + recall_micro) != 0else0 output.append([None, None, None, recall_micro, precision_micro, f1_micro]) save_output_to_excel(output, out_file) print(f"\nTotally, {mistake_all} mistakes, detect {detect_all}, correct {correct_all}, f1_score: {f1_micro}")
return
模型选型
文章校对场景中，针对长文档优先推荐Qwen-Long模型，Qwen-Long擅长超长上下文处理，能高效支持复杂文档的分析、总结与信息提取需求。（PS：截止到2025年10月1日，Qwen-Long尚未上架到国际站，海外用户模型选型时关注下）
模型微调
媒体行业中涉及到模型微调的场景很多，因为不同媒体均有自己的文章风格或语言风格，而在文章校对场景中，模型微调技术主要应用在检测文章风格规则和语言特色规则。当前基于百炼进行模型微调的门槛相对较低，重点需要准备高质量数据集，模型微调一般会经历这几个步骤：数据准备与上传—>模型选择与配置—>微调任务配置—>训练监控与优化—>模型评估与部署。限于篇幅，后续再专门编写媒体行业模型微调最佳实践。
某媒体客户是一家拥有100多年历史的英文媒体企业，一直期望通过大模型重塑业务，提高文章生产效率。但在推进过程中，除了客户内部大模型建设人力不足外，还遇到编辑部同事对大模型的普遍抵触。为此，客户高层联合阿里云政企公共云专家团队，选定“文章校对”场景为突破口，通过该场景的落地来获取编辑部的信任并推动其他大模型场景的建设。文章校对是内容生产过程中必备的一个环节，客户当前的流程非常依赖人工操作，需经过多轮逐字审查、交叉核对与专家复核，编辑人员校对周期长。同时，由于缺乏统一、智能的辅助工具，校对工作易受主观判断和疲劳因素影响，容易导致术语不一致、敏感词遗漏、事实性错误难以发现等问题，因此只能投入更多资源加大审核力度，确保万无一失。
校对规则分析
客户产出内容为英文，校对规则遵循英式英语规范，结合本地语言使用习惯，共涵盖五大类规则：Tense（时态一致性）、Punctuation（标点符号规范）、Spelling & British English（拼写准确性和英式英语用法）、Sentence Construction（句子结构合理性）以及 Style guide（from Tansa）（关键词替换知识库），如下图：
智能体方案
为降低客户后期维护成本，智能体基于百炼平台构建，选用 Qwen-Long 作为基础模型。通过 Prompt 工程来覆盖多种校验规则，再通过RAG 检索增强技术来实现关键词的识别和替换。另外，为进一步提升处理效率，同时避免上述方案中提到的“规则遗忘”和“规则冲突”问题，智能体将校对规则拆分并行执行，并行过程中仅记录待修改项，最终统一汇总并一次性完成修改操作，在保障准确性的同时提升整体处理速度，最终版本的智能体方案如下图：
智能体自第一版本到最终交付，中间共经历五轮左右迭代与优化。其中，RAG召回率提升与Prompt工程调优是投入资源最多的环节，这两项工作完成后，F1评测值超过客户一开始定义的标准值80分。然而，进入编辑部内侧阶段后，仍可以发现很多关键词无法替换的badcase（根因百炼上RAG对query字符的限制，下文会展开）。在最后一轮优化中，直接放弃了RAG方案，采用工程化规则匹配机制实现关键词替换，顺利解决了badcase，以下记录一些关键的优化项。
Prompt优化
文章校对的Prompt优化过程，除了任务指令的精细化拆解、关键词强化、上下文示例补充以及迭代式调试等常规优化方式外，主要是引入了Few-shot学习方式，增强模型对校对规则的理解。同时，为降低复杂文本和长文本的干扰，Prompt工程测试都是对单一规则和短语句开始，验证OK以后再扩展到复杂长文本。这其中较大的挑战主要是英文语法相关的校对，包括英式英语和英文时态规则。
英文时态优化
英文一共有16种时态，4种时间（现在、过去、将来、过去将来）和4种状态（一般、进行、完成、完成进行）组合而成。上下文的时态需要保持时态统一，但有一些特殊情况，例如文章标题或副标题得用现在时态，已经过去的事情一定得用过去时态，直接引语内可以使用任何时态（即保持原始时态）。这个过程难点在于时态的判断和规则的梳理，往往一句话中的时态很难判断，除非有明确的时间信息，所以基本都需要结合上下文语境来判定，同时特殊规则非常依赖业务同学输入，经过多轮调整后的prompt如下：
- **Global tense pass** - Correct every inaccurate verb tense based on context, but ensure NO TENSE CHANGE within all quotes.*Example*: *The minister **stepping** down yesterday.* → *The minister **stepped** down yesterday.*- **Present tense in headlines / sub-heads** - Ensure immediacy.*Example*: *China **moved … vowed** …* → *China **moves … vows** …*- **Proper tense in body text** - Narrative prose must be in the past tense for events that have already completed(any tense allowed inside direct quotes).
英式英语优化
根据本地化习惯，对外内容需要转化英式英语，英式英语和美式英语存在显著的差异。首先是可以直接替换的词语，如拼写差异：后缀规则替换-or—>-our（color—>colour）,-ize—>-ise（organize → organise），-er—>-re（meter—>metre）等等，以及词汇差异：elevator—>lift，apartment—>flat，sidewalk—>pavement等。对于客户日常容易写错的词，可以直接通过RAG来实现即可，如发现词汇量巨大，也可以通过调用 DeepL API来实现精准替换。其次是语法差异，如一些英文时态偏好、介词与冠词用法以及集体名词单复数用法等，这类通过提示词可以覆盖大部分场景，后续如追求更高准确率，则需要更换翻译模型（如qwen-mt）或通过模型微调来实现。
RAG召回率优化
以上是客户提供过来的原始知识库，其中：B列表示需要替换的词，C列表示替换的词，G列通过信息说明什么时候需要替换（有些需要结合上下文语境来判断是否替换，例：when in context of hong kong and China, we should use hong kong and mainland, instead of China），H列表示改列是否需要替换状态（属于干扰项，为false表示不用替换，但为true的时候有可能也不需要替换）。
知识库导入优化
此类优化主要包括以下几个关键环节：首先，将原始知识库转化为结构化文本文件并完成导入；其次，对文件进行精简，剔除对模型无用的信息，例如标记为 Replacement=false 的条目。最终，优化后的知识库仅保留“search for”“entry”和“ information”三个核心字段，如下所示：
索引配置优化
在知识库导入过程中，默认会将所有字段配置为参与检索状态。但由于 information 字段中包含大量关键词，如果参与检索，将在RAG关键词倒排索引召回阶段引入噪声，影响召回率。实际上，information字段只是用于模型在生成回复时判断是否执行替换操作，并不应用于检索匹配。所以，一定得取消勾选 information 字段的“参与检索”选项，如下图：
embedding模型变更
通过百炼默认的DashScope text-embedding-v4版本embedding模型进行向量化后，发现很简单的语句有时候会存在召回问题，以下是经典badcase：
Original Text：Coca-colar is the best-seller
Correct Text：Coca-colar is the best-seller
经过大模型校对以后没有把best-seller 替换成bestseller，本地知识库中关键词替换信息如下：
通过工具定位发现best-seller这个关键词分词时不正确，分成了best -s eller 三部分，如下图，最终使用DashScope text-embedding-v2版本来做向量化解决了该badcase，v2版本在关键词检索场景中优于v4版本。
放弃RAG方案
完成Prompt优化与RAG召回率提升后，智能体工程提交至编辑部进行测试。从反馈的badcase发现，针对长文本文章校对，RAG整体召回率偏低，尤其在文章后半部分的关键词难以被有效召回。经验证发现，文本前XX个字符范围内召回率较高，而超出该长度后显著下降（字符数并没有测试出来，官方说是896个字符，实际测试比这个小）。
对此，曾考虑将长文本拆分为多个短段落分别处理，但这样会导致上下文的英文时态不统一，另一种可行但较为复杂的方案是通过工作流来分步处理：先通过Prompt工程完成除关键词替换外的其余规则校对，再将校对后文本分成小段执行关键词替换，最终合并输出。但考虑耗时问题，最终采用了一种字符串匹配的方案，即通过工程化能力来解决关键字替换问题：首先通过字符串匹配能力召回知识库中相关的关键词信息（search_for、entry和information字段）；其次，将关键词信息拼接到prompt中；最后，通过模型能力来根据这些召回的关键信息判断是否需要替换。该方案很快得到验证，客户反馈过来的badcase都可以正常召回。而切换成这种方案后，就放弃了使用百炼平台，采用工程化方式来调用模型API。核心代码如下：
def load_guideline_file(file_name): records, l = load_file(file_name) print(l) guidelines = [] for record in records: if record[-1] is True: item = { "search_for": str(record[0]).strip(), "entry": str(record[1]).strip(), "information": str(record[2]).strip() } guidelines.append(item) return guidelines
def process(Agent, input_file, out_file, guidelines, batch_size, start=0, end=int(1e8)): """ 处理输入文件中的内容并保存到输出文件 Args: agent: QwenLong 实例 input_file: 输入Excel文件路径 out_file: 输出Excel文件路径 guidelines: 编辑指南列表 batch_size: 批处理大小 start: 起始索引 end: 结束索引 """ _, existing_count = load_file(out_file) contents, input_cnt = load_file(input_file) end = min(end, input_cnt) contents = contents[start:end] total_items = len(contents) processed_count = existing_count with tqdm(total=total_items, desc=f"Processing {Path(input_file).name}") as pbar: for batch_idx in range(0, total_items, batch_size): batch = contents[batch_idx:batch_idx + batch_size] unprocessed_batch = [item for idx, item in enumerate(batch) if (batch_idx + idx) >= existing_count] pbar.update(len(batch) - len(unprocessed_batch)) with ThreadPoolExecutor(max_workers=batch_size) as executor: future_map = {} results = [None] * len(unprocessed_batch) for idx, content in enumerate(unprocessed_batch): origin, test_article, _, _ = content test_article_lower = test_article.lower() guidelines_extracted = [ item for item in guidelines if item["search_for"].lower() in test_article_lower ] prompt_data = { "test_article": test_article, "guidelines": guidelines_extracted } prompt = proofreading_prompt.format(**prompt_data) future = executor.submit(agent.run, prompt=prompt) future_map[future] = (idx, content) forfuture in as_completed(future_map): idx, content = future_map[future] origin, test_article, _, _ = content max_retry = 10 retry_delay = 5 retry_count = 0 success = False while retry_count < max_retry andnot success: try: response, success = future.result(timeout=120) results[idx] = [origin, test_article, response] except Exception as e: print(f"Error processing item: {str(e)}") retry_count += 1 if retry_count < max_retry: print(f"Retrying in {retry_delay} seconds... (Attempt {retry_count}/{max_retry})") time.sleep(retry_delay) else: print("Max retries reached. Saving empty result.") results[idx] = [origin, test_article, ""] pbar.update(1) processed_count += 1 ordered_results = [r for r in results if r is not None] if ordered_results: save_output_to_excel(ordered_results, out_file) print(f"Finished processing {processed_count} items.") return
从业务明确需求到最终第一版本上线，历时4个月，最终也获得客户的认可。在成功完成一个场景落地后，客户其他的场景的大模型需求也都在逐步探索和建设中，包括AI 搜索、AI博客、AI翻译和AI数字人等。有了第一个成功案例，未来的建设会越来越顺畅。
以下是第一版本Proofreader的效果截图：
媒体行业正迎来大模型带来的新机遇，未来会有更多应用场景诞生。媒体客户出于对信息真实性、内容质量、法律法规和品牌形象等多方考虑，对于大模型准确性的要求非常高，但这并不影响使用大模型来辅助内容生产的过程，也许从辅助内容生产到替代部分内容生产环节还有很长的路要走，但相信随着模型能力的提升以及客户对大模型的理解和使用越来越深入，这一天迟早会到来。而另一方面，大模型的发展未来一定会创造更多的工作需求，积极拥抱AI带来的便利性，与AI同行，才能成为时代的领跑者！
粤ICP备14082021号
免费POC，
零成本试错
