公共部门AI项目实战：从LLM预标注到可审计机器学习流水线构建

1. 项目概述：当机器学习遇上公共部门

在科技公司里，我们谈论机器学习工程，常常会想到的是A/B测试、秒级的模型迭代、海量的云算力和近乎无限的数据流。但如果你把视角转向公共部门——那些承载着公民提案、政策反馈和社会服务的政府平台，你会发现这里的游戏规则截然不同。我最近深度参与了一个国家级公民参与平台的机器学习项目，从数据标注到生产部署，走完了一整个流程。这段经历让我深刻体会到，在资源、流程和合规性多重约束下，构建一个可靠、可审计的AI系统，其挑战远不止于调参和选模型。

这个项目的核心任务，是对平台上成千上万的公民提案进行自动化的语义聚类和分类。想象一下，一个允许数百万市民就城市规划、公共预算发表意见的平台，每天涌入的非结构化文本数据。人工处理？效率低下且难以规模化。直接上最先进的模型？数据标注是第一个拦路虎——没有现成的标注数据，且文本充满口语化、模糊性和领域特定术语。更棘手的是，数据访问需要层层审批，基础设施依赖政府内部团队，每一次数据集的更新都可能因为权限问题而延迟数周甚至数月。这就是公共部门AI项目的典型写照：目标明确，价值巨大，但每一步都走在技术可行性与行政现实的钢丝上。

我们的解决方案，围绕几个关键词展开：LLM预标注、数据版本管理和模型可追溯性。我们用大语言模型来“打前锋”，快速生成一批初始标签，以缓解专家标注的资源瓶颈；我们像管理代码一样管理数据和模型的所有变更，确保任何时候都能回答“这个结果是怎么来的”；我们设计了一套虽不完美但务实的监控和评估体系，试图在有限的资源下，最大化系统的可靠性和透明度。这篇文章，就是这次实践的全记录。我会详细拆解我们从预标注到生产部署的完整流水线，分享其中踩过的坑、做出的权衡，以及那些在理想化的MLOps教科书之外，真正管用的工程经验。无论你是在类似约束环境下工作的工程师，还是对AI系统落地全流程感兴趣的研究者，希望这些来自一线的细节能对你有所启发。

2. 核心挑战与工程化应对思路

在理想世界里，机器学习项目的流程是线性的、可控的：获取干净数据、标注、训练、评估、部署、监控。但在我们面对的这个公共部门场景里，几乎每一个环节都充满了不确定性。技术问题与组织流程深度耦合，单纯优化模型指标往往徒劳无功。我们必须首先识别出那些最根本的约束，并据此设计我们的工程架构。

2.1 数据访问与治理：被官僚流程拖慢的迭代速度

项目最大的瓶颈并非来自算法，而是数据访问。所有原始数据都存放在受严格管控的政府内部数据库中。我们的团队需要申请特定凭证，并通过一个指定的网络通道进行连接。这个授权过程不是一次性的，凭证会定期轮换，部分数据表的访问权限还需要单独审批。

注意：这种依赖外部团队进行基础设施托管和安全管理的模式，将项目的关键路径从“代码就绪”转移到了“凭证就绪”。一次模型迭代的延迟，很可能是因为等待数据访问审批，而非训练本身。

这导致了几个严重的工程后果：

1. 迭代周期不可预测：开发节奏被外部审批队列主导，无法进行快速的、基于数据反馈的迭代。
2. 数据快照的静态化：为了避免每次实验都重新申请数据，团队倾向于在获得授权后，一次性拉取一个大的静态数据集快照，并在此后的几周甚至几个月内都基于这个“化石”数据工作。
3. 可追溯性断裂：当使用不同时间点获取的数据快照进行实验对比时，很难区分性能变化是源于模型改进，还是源于底层数据本身的漂移（例如，新时间段内公民关注的热点话题发生了变化）。

为了维持基本的开发节奏，我们被迫采取了一种“本地化”策略：在获得一个相对完整的数据快照后，立即进行预标注，并基于此开展后续的模型实验。这虽然保住了速度，但却以牺牲中央化的、版本化的数据溯源为代价。从数据成熟度来看，这大概处于DataOps成熟度模型的第1到2级：手动交付、低自动化、非正式流程。其组织影响是深远的：大量工程精力被消耗在手动重建数据集、验证数据一致性上，而非用于核心的分析与建模。

2.2 类别不平衡与评估指标的选择

拿到数据后，第一个技术挑战扑面而来：极端的类别不平衡。在我们的多分类任务中，最常见类别的样本数是最稀有类别的234倍。这种“长尾分布”是现实世界数据，特别是公共议题数据的典型特征——大部分讨论集中在少数几个热门话题，而大量小众但重要的议题则样本寥寥。

如果使用整体的准确率（Accuracy）作为主要指标，模型会简单地倾向于将所有样本都预测为多数类，从而得到一个很高的、但毫无用处的分数。这对于一个旨在公平反映多元民意的系统来说是灾难性的。因此，我们果断放弃了准确率作为核心评估标准，转而采用Macro-F1分数。

这里简单解释一下为什么是Macro-F1：F1分数是精确率（Precision）和召回率（Recall）的调和平均数，能同时衡量模型“找得准”和“找得全”的能力。而“Macro”意味着我们先计算每个类别的F1，然后对所有类别的F1取算术平均。这意味着，一个只有10个样本的稀有类别，和一个有10000个样本的热门类别，在最终的评价指标中拥有完全相同的权重。这迫使模型必须努力学好每一个类别，而不仅仅是讨好那些数据量大的类别。这是我们在工程实践中向“公平性”做出的一次重要妥协和技术对齐。

2.3 预标注策略：用LLM加速，靠人工校准

面对数万条待标注文本和有限的领域专家资源，从头开始进行人工标注是不现实的。我们引入了LLM预标注作为加速器。具体而言，我们使用Gemma 3 12B模型，在本地环境中对总计10,186条记录（涵盖36个类别）进行了批量自动标注。整个过程耗时约94.6分钟，生成了可用于启动模型训练的第一版标签。

但关键在于，我们从未将LLM的输出视为“真理”。我们清醒地认识到，LLM的标注存在幻觉、不一致和对提示词敏感等问题。因此，预标注的核心定位是生成一个高质量的“草案”，极大缩减人工审核的范围，而非替代人工。为了评估这个草案的质量，我们随后进行了一次严格的抽样审计：三位领域专家独立地对200条分层抽样的提案进行标注，并以至少两人达成一致的标签作为“黄金标准”（Gold Standard）。

审计结果很有启发性：

• 在200个样本中，有159个（79.5%）达成了多数一致，构成了可靠的评估集。
• 有41个（20.5%）样本无法达成最低共识，这揭示了数据中固有的模糊性。
• 在三位专家都提供了标签的155个样本中，有13个（8.4%）出现了完全分歧（三人三个不同标签），这标定了我们任务性能的理论上限——有些文本本身就是模棱两可的。
• 将LLM的预标注结果与159个“黄金标准”样本对比，Cohen‘s Kappa系数为0.481，准确率为50.3%。这意味着LLM复制了部分人类标注模式，但在约一半的审核案例中存在分歧。

这个流程确立���我们后续工作的基石：LLM用于规模化，人类用于校准和质量控制。所有模型的效果评估，都严格基于那159个有共识的“黄金标准”样本进行。同时，那41个无共识的样本被单独留存，等待未来更复杂的裁决机制（如引入第四位专家或业务规则）来处理。

2.4 架构设计的核心：可追溯性高于一切

在数据访问受限、流程存在诸多手动环节的背景下，确保每一步操作的可追溯性和可复现性成为了架构设计的最高优先级。我们无法承受“上周效果好的模型，这周为什么不行了？”这样的黑盒问题。

我们的策略是，将软件工程中“一切皆版本”的理念贯彻到机器学习流水线中：

1. 代码版本化：使用Git，每个实验、每个参数调整都有对应的提交。
2. 数据版本化：尽管完整的数据流水线自动化受限，但我们为每一个使用的数据快照（.csv文件）生成唯一的哈希值，并与代码版本绑定。
3. 模型版本化：训练出的模型文件、超参数配置、乃至使用的Python环境（通过requirements.txt或Dockerfile），全部打包并存储。
4. 实验元数据记录：每次训练运行的指标（Macro-F1, Accuracy, 每类F1）、耗时、硬件信息等，都自动记录到结构化的文件（如JSON或MLflow）中。
5. 流水线日志：从数据预处理、特征提取到训练、评估，关键步骤都有日志输出，并关联到运行ID。

我们搭建了一个虽不华丽但至关重要的“证据链”。当需要回溯某个结果时，我们可以根据模型版本，找到对应的代码提交、数据快照哈希、训练参数和评估指标。这虽然无法完全解决因底层数据源变化带来的漂移问题，但至少确保了在“同一份输入数据”的前提下，实验是完全可复现的。这对于在组织内部建立信任、进行审计和问题排查至关重要。

3. 模型策略实验与生产化权衡

有了经过预标注和人工审核的数据基础，以及可追溯的实验框架，我们接下来面对的就是模型策略的选择。我们的目标不是追求在学术数据集上的最高分数，而是在满足基本性能要求的前提下，找到最适合当前工程约束和组织现实的方案。我们系统性地对比了几种处理类别不平衡和提升性能的常见策略。

3.1 实验配置与基线模型

我们所有的实验都基于同一个“黄金标准”测试集（159个样本）进行。特征工程方面，我们采用了针对巴西葡萄牙语预训练的BERTimbau模型来生成文本嵌入。这是一个在资源受限环境下非常实用的选择：利用强大的开源预训练模型作为特征提取器，然后在其上训练一个相对轻量的分类器（如逻辑回归或XGBoost），既能获得不错的性能，又避免了从头训练大模型的计算开销。

我们首先建立了一个不平衡基线：直接使用原始的长尾分布数据，训练一个逻辑回归分类器。它的表现是我们的基准。随后，我们测试了三种改进策略：

1. SMOTE：一种经典的过采样技术，为少数类合成新的样本。
2. LLM合成数据增强：使用LLM（同样是Gemma），根据少数类的真实样本，生成语义相似的合成文本，以扩充这些类别的数据。
3. 双分类器路由架构：这是一个更复杂的工程架构。我们将36个类别按样本数量分为“多数类”和“少数类”两组，分别训练两个分类器（Pass1和Pass2）。推理时，先由Pass1分类器进行预测，如果其置信度低于某个阈值，则交由Pass2分类器再次预测。

3.2 离线评估与生产模拟的差异

最初，在离线训练和评估阶段，双分类器架构展现出了最好的性能。从下表可以看出，在各自的数据分区上，两个分类器都取得了较高的准确率和Macro-F1。

这个结果很诱人，似乎指出了明确的方向。然而，当我们把模型放到更接近生产环境的模拟中进行评估时（考虑延迟、吞吐量，并进行多轮运行取平均），故事发生了反转。

我们模拟了一个生产推理服务，连续处理2000条提案，并聚合了10次运行的平均结果，关键指标如下：

结果分析：

1. LLM合成增强胜出：它在质量（Macro-F1和准确率）和成本（延迟）之间取得了最佳平衡。合成数据有效缓解了不平衡，且没有引入过高的计算开销。
2. 不平衡基线依然稳健：其性能与LLM增强版本相差无几，延迟也几乎一致。这说明对于我们的任务，简单的逻辑回归配合高质量的BERT嵌入已经提供了一个很强的基线，过度复杂的处理可能收益有限。
3. SMOTE效果不佳：虽然延迟略有降低，但性能损失显著。这可能是因为SMOTE在文本的嵌入空间中进行插值，生成的合成样本在语义上不够合理，反而误导了模型。
4. 双分类器架构的陷阱：这是最深刻的教训。离线评估时，我们是分开评估Pass1和Pass2的，但在生产模拟中，它们需要协同工作。我们发现，Pass1分类器对于本应由Pass2处理的“少数类”样本也往往给出过高的置信度，导致路由机制失效，大量本应交给Pass2的样本被Pass1错误地自信分类，最终拉低了整体性能。同时，串行两个模型推理带来了近乎翻倍的延迟。

3.3 生产化决策：性能、成本与复杂度的三角权衡

基于以上实验，我们做出了最终的生产化决策：

• 首选方案：采用基于LLM合成数据增强的逻辑回归模型。它提供了可观的性能提升，且架构简单，易于维护和解释，延迟在可接受范围内。
• 备用方案：保留不平衡基线模型作为对照基准和回滚选择。它的简单性本身就是一种可靠性。
• 放弃方案：SMOTE和双分类器路由架构。前者牺牲了太多质量，后者则引入了不必要的复杂性和性能风险。

实操心得：在资源受限的公共部门项目中，“简单有效”远比“复杂先进”更有生命力。一个双模型路由架构带来的运维复杂度、调试难度和潜在的故障点，往往会抵消其理论上的性能优势。每次架构升级前，必须进行严格的生产环境模拟压测，离线指标具有欺骗性。

这个决策过程完美体现了工程上的权衡：我们牺牲了一点理论上限（双分类器在理想路由下的潜力），换来了更可靠的系统行为、更低的延迟、更简单的运维和更高的可解释性。在公共部门的语境下，后者的价值往往更大。

4. 构建可审计的机器学习流水线

模型选定之后，更大的挑战在于如何将它变成一个持续、可靠、可审计的生产系统。在公共部门，模型的决策可能关系到资源分配或政策参考，因此“黑箱”是不可接受的。我们需要构建的不仅是一个预测服务，更是一个证据生成和留存系统。

4.1 数据与模型的血缘追溯实现

可追溯性的核心是建立完整的数据血缘。在我们的约束条件下，无法实现全自动的、端到端的 lineage tracking，但我们通过一套组合拳实现了足够实用的追溯能力。

1. 版本化快照与哈希链：我们为每一个输入数据文件（如proposals_2025_04.csv）计算SHA-256哈希值。这个哈希值，连同文件的获取日期、来源描述，被记录在一个中央的data_manifest.json文件中。任何训练或处理脚本，在读取数据时，都必须将这个哈希值作为元数据记录下来。这样，任何一个模型产出物，都能向上追溯到它所使用的确切数据快照。

2. 实验追踪与参数绑定：我们使用轻量级的MLflow来管理实验。每次训练运行都会记录：

• run_id: 唯一实验ID。
• git_commit: 训练代码对应的Git提交哈希。
• data_snapshot_hash: 输入数据哈希。
• hyperparameters: 所有超参数（学习率、批次大小等）。
• metrics: 在验证集和测试集上的所有评估指标。
• artifact_uri: 序列化模型文件的存储路径。

通过git_commit和data_snapshot_hash，我们就能唯一确定一次实验的“代码+数据”状态。以下是我们的实验记录表示例：

3. 推理日志的标准化输出：生产中的推理服务，每处理一条请求，不仅返回预测结果和置信度，还会在日志中输出一个结构化的记录，包含：

• request_id: 请求唯一ID。
• timestamp: 时间戳。
• model_version: 模型版本（对应MLflow的run_id）。
• input_text_snippet: 输入文本的前N个字符（出于隐私考虑可哈希处理）。
• predicted_class: 预测类别。
• confidence: 置信度分数。
• top_k_predictions: 排名前K的类别及置信度。

这些日志被集中收集（如使用ELK栈），并可以通过model_version和request_id进行关联查询。当收到对某个预测结果的质询时，我们可以快速定位到该次推理所使用的模型版本、当时的输入，乃至当时模型的其他预测选项。

4.2 面向业务的监控与预警设计

监控不能只停留在“服务是否存活”的层面。我们需要知道模型在生产中的表现是否在退化。然而，在缺乏实时真实标签（Ground Truth）的典型生产环境中，这是一个难题。我们设计了分层级的监控策略：

第一层：系统健康度监控。这是最基础的，包括服务可用性、响应延迟（P50, P95, P99）、吞吐量（QPS）和资源利用率（CPU/内存）。任何异常都会触发告警。我们使用Prometheus和Grafana来实现。

第二层：数据分布监控。我们无法实时知道预测的对错，但可以监控输入数据的分布是否发生了显著变化。我们每日计算生产推理请求中，各个预测类别的比例分布，并与过去一段时间的基线分布（例如上周的平均分布）进行对比。使用群体稳定性指数或卡方检验来量化差异。如果分布发生剧烈偏移，可能意味着外部事件导致用户关注点变化（数据漂移），或者模型本身出现了某种偏差。

第三层：基于置信度的代理监控。我们假设，一个健康的模型，其预测置信度的分布应该是相对稳定的。我们监控以下置信度指标：

• 平均置信度的变化。
• 低置信度（如< 0.6）预测所占比例的变化。
• 预测结果的“熵”或不确定性指标。

如果出现平均置信度持续下降，或低置信度预测比例大幅上升，这可能暗示模型遇到了它不熟悉的输入模式（概念漂移），需要工程师介入分析。

第四层：定期的人工抽样审计。这是最可靠但成本最高的手段。我们建立了一个制度：每周随机抽取一定数量（如100条）的生产预测结果，交由领域专家进行人工复核。将人工标签与模型预测对比，计算本周的“生产准确率”和“生产Macro-F1”。这个指标虽然滞后，但它是模型真实性能的黄金标准。我们将这个指标也录入监控大盘，并设置趋势告警（如连续两周下降超过5%）。

这套组合监控方案，在无法获得即时反馈的背景下，为我们提供了尽可能多的“感知”能力，以便在问题影响扩大之前及时发现。

4.3 模型更新与回滚流程

在公共部门，模型的变更需要更加谨慎。我们制定了一个简化的模型上线流程：

1. 候选模型验证：新训练的候选模型必须在预留的、版本化的测试集上达到预设的性能门槛（如Macro-F1提升至少2%，或在不降低Macro-F1的前提下显著降低延迟）。
2. 影子测试：将候选模型以“影子模式”部署到生产环境。即，它并行处理真实的用户请求，但其预测结果不返回给用户，只用于日志记录。运行一段时间（如24小时）后，分析其与当前线上模型的预测差异、置信度分布等。
3. 小流量实验：如果影子测试无异常，将少量（如5%）的生产流量切到新模型，进行A/B测试。对比新老模型在业务指标（如有的话）和监控指标上的表现。
4. 全量发布与回滚计划：逐步放大流量至100%。关键点在于，每一次发布，都必须明确且快速地回滚方案。在我们的系统中，回滚意味着将负载均衡器的配置指向旧版本的模型服务端点，通常在几分钟内即可完成。所有模型版本及其对应的代码、数据、配置都必须长期保留，以确保任何历史版本都是可重新部署的。

这个流程确保了模型更新的可控性和可逆性，符合公共系统对稳定性的高要求。

5. 组织、流程与治理的协同

技术方案再精巧，如果脱离了组织的流程和治理框架，也注定失败。在这个项目中，我们遭遇的许多核心挑战，其根源都在于“人”和“流程”。

5.1 打破数据孤岛与建立数据契约

缺乏统一的数据目录是我们早期工作的主要障碍。业务指标的定义、数据转换的逻辑，散落在各个Jupyter Notebook、SQL脚本和部门成员的脑子里。当不同团队需要协作时，往往需要花费大量时间进行“知识考古”和手动核对。

我们的应对措施是，在现有条件下，推动建立非正式的“数据契约”和“指标字典”：

• 指标字典：我们用一个共享的Wiki页面，维护了所有关键业务指标和模型指标的精确定义、计算口径和负责人。例如，“提案热度”这个指标，明确其计算公式为“过去7天内的评论数+点赞数”，并由数据团队的小张负责维护。
• 数据契约：对于跨团队共享的关键数据表或特征，我们通过文档约定其Schema、更新频率、数据质量要求（如非空率>99%）和负责人。虽然这不是一个自动化的系统，但通过文档化和共识，极大地减少了误解。

经验之谈：在无法立即上马昂贵的数据治理平台时，一个维护良好的共享文档（如Confluence或GitHub Wiki）是最具性价比的解决方案。关键在于指定明确的维护负责人，并把它变成团队工作流程的一部分（如，代码评审时如果引入了新的指标，必须同时更新指标字典）。

5.2 在审批流程中寻找敏捷空间

如前所述，漫长的数据访问审批是迭代速度的杀手。我们无法改变整个官僚体系，但可以在局部优化：

• 预申请与批量申请：与数据管理部门建立沟通，提前规划未来一个季度可能需要的核心数据表，尝试进行批量申请，而不是每次实验前临时申请。
• 建立“安全沙箱”数据：推动基础设施团队提供一份脱敏的、样本量较小的公开数据集，供前期算法调研和原型开发使用。这避免了在探索阶段就陷入漫长的审批。
• 明确数据使用协议：在申请时，清晰说明数据的使用目的、范围、存储方式和销毁计划，这有助于加快安全团队的评估速度。

这些措施无法根除问题，但能为我们争取到更多连续、稳定的开发时间。

5.3 培养跨职能的“MLOps”意识

在公共部门的技术团队中，传统的开发、运维、数据科学角色界限可能比较分明。机器学习项目要求这些角色紧密协作。我们通过具体项目来推动这种融合：

• 让数据科学家关心运维：在项目初期，就要求数据科学家提供模型的预期吞吐量、延迟和资源需求。让他们参与设计监控指标。
• 让开发工程师理解模型：组织内部技术分享，让后端工程师理解模型服务的基本流程、常见的失败模式（如数值溢出、特征缺失），以便他们能更好地编写调用代码和故障处理逻辑。
• 建立联合值班机制：在模型上线初期，安排数据科学家和运维工程师共同值班，快速处理线上问题。

这种文化的建立是缓慢的，但却是项目长期成功的基石。它确保了机器学习系统不被视为一个神秘的“黑匣子”，而是一个由整个团队共同负责的产品。

6. 总结与对未来实践的启示

回顾整个从预标注到生产的旅程，最大的感悟是：在公共部门成功部署机器学习系统，是一场关于权衡和务实的持久战。它要求工程师不仅是一名算法专家，更是一名系统架构师、流程推动者和沟通者。

技术上的核心启示是，在资源受限的环境中，可靠性往往源于简单性和可追溯性，而非模型的复杂性。LLM预标注是一个强大的加速器，但它必须被置于严格的人类审核流程之下。数据版本化和实验追踪不是“锦上添花”，而是应对底层数据不稳定的“生命线”。生产环境的评估与离线评估可能存在巨大差异，架构决策必须经过贴近现实的压测。

组织与流程上的核心启示是，技术瓶颈的根源常常在技术之外。数据访问的官僚流程、碎片化的知识管理、割裂的团队职能，都会直接转化为工程上的摩擦成本和不可靠性。因此，工程师需要主动参与流程优化，通过建立轻量级的契约、文档和沟通机制，在现有的组织框架内创造更高效的协作空间。

这个项目远非终点。展望未来，有几个方向值得持续探索：如何将定期的人工抽样审计流程进一步自动化、制度化？如何设计更细粒度的、基于置信度的动态路由，让简单模型处理简单样本，复杂模型处理复杂样本，从而在效果和成本间取得更优平衡？更重要的是，如何将我们在单个项目中积累的这套可追溯、可审计的工程实践，沉淀为团队甚至部门级别的标准模版和工具链，让下一个公共AI项目的启动成本更低、可靠性更高？

机器学习在公共部门的旅程才刚刚开始。其最终目标，不仅是提升效率，更是通过透明、可靠的技术，增强公共服务的可信度和公民的参与感。这条路上充满了独特的挑战，但也蕴含着推动技术向善的巨大价值。希望我们这次实践中的经验与教训，能成为同行者脚下的一块垫脚石。