FDE 多模态数据清洗指南：把社交平台内容变成可信数据

本文根据 Miles Ma 的 X 长文整理。原文发布于 2026 年 10 月 27 日，案例来自一家美妆企业的 FDE 落地项目。文中的业务场景和工具组合是作者的项目经验，下面将其整理为可迁移的工程框架；具体平台接口、模型效果、费用和字段仍需要用自己的数据验证。

企业做舆情分析、竞品调研或营销复盘时，最难的往往不是让模型生成一段总结，而是先把采集回来的内容整理成可追溯、可比较、可复核的数据。小红书、抖音、视频号和微博里的文字、图片、音频、视频混在一起；同一个产品有全称、简称和用户口语；评论又挂在原帖或其他回复下面。

如果清洗阶段把原始证据、对象关系或时间线弄丢，后面的用户洞察看起来再完整，也很难回答“这个结论来自哪里”。原文给出了一条八步链路：

定数据规范
  → 保留原始内容
  → 梳理数据关系
  → 多模态归一
  → 冲突和质量清洗
  → 生成结构化数据
  → 执行验收
  → 按规则和版本入库

第一步：先写清楚数据要拿来做什么

同一批采集数据，服务不同业务时需要不同的清洗口径。舆情报告关注事件、传播和风险；竞品分析关注品牌、产品线、成分和用户评价；营销复盘关注渠道、内容、互动和反馈；评论分析则必须保留提问、上下文和回复关系。

用途不同，去重规则也可能相反。一个新品素材被十个账号发布，传播复盘需要保留十次发布；统计自然讨论时，则可以把它们归入同一个重复素材组。如果一开始直接删掉九条，后面就无法切换统计口径。

在采集和清洗前，先写一份数据规范，至少回答：

• 哪些字段和原始文件必须保留；
• 帖子、评论、回复、用户和附件如何关联；
• 哪些判断必须附原文、时间码或图片位置；
• 哪些数据可以自动使用，哪些必须人工确认；
• 结果进入哪个报告、查询或数据库，以及什么条件才算验收通过。

数据规范的作用不是增加文档工作，而是让后面的删除、合并和模型标注都有明确依据。

第二步：原始内容永远不能被覆盖

原文、图片、音频、视频、链接、发布时间和平台原始 ID 都应保留。清洗后的文本、OCR、ASR、视觉标签和模型抽取结果放在独立字段，不能覆盖原内容。

这样做至少有三个好处：

1. 识别错误时，可以回到原图、原音频或原视频检查。
2. 更换模型或规则后，可以重新处理，而不必重新采集。
3. 报告中的结论能够定位到原始证据，便于复核和解释。

一个适合长期维护的记录，可以分成四层：

raw/       原始文本、文件、链接和平台响应
derived/   OCR、ASR、视觉识别和模型抽取结果
quality/   冲突、重复、风险和人工复核状态
published/ 报告、索引和对外可查询的数据

模型输出只是新增的加工结果，不应成为唯一事实来源。尤其是价格、型号、日期、人物、产品功效和用户意图等字段，必须能够回到原始内容。

第三步：把用户、原帖、评论和回复连起来

只保存作者、正文、时间和互动量，勉强可以做词频统计，却无法可靠分析评论语境。一句“这个也太差了”，可能评价原帖中的产品，也可能只是回复上一条评论；它属于哪一层，要看父级 ID。

单个平台内至少保留这些关系键：

字段	用途
user_id	标识发布或回复的账号
post_id	标识评论所属的原帖
comment_id	标识当前评论或回复
parent_comment_id	指向被回复的评论
platform	区分不同平台的同名或同号 ID

主键可以使用“平台名 + 平台原始 ID”，避免跨平台撞号。平台之间不要仅凭昵称、头像或相似表达把账号拼成同一个人；没有可靠主键和明确授权时，只能汇总内容、对象和话题，不能生成个人的跨平台完整轨迹。

一句话概括：平台内把关系保留完整，平台间把来源分开保存。

第四步：分别处理四种模态，再统一格式

不同模态需要不同处理方法，但最终都应落到一套可以查询的记录：谁在什么时间说了什么，提到了什么对象，证据在原内容哪个位置。

文字

保留原文，再处理乱码、空白、链接、语言和重复段落。模型抽取观点时，最好同时返回对应原句，而不是只返回一个“正面/负面”标签。

图片

OCR 可以提取价格、型号、日期和截图文字；视觉模型可以识别对象、场景和部件。两种结果都应保留图片位置或区域信息，方便判断一段文字和一个对象是否真的位于同一区域。

音频

统一格式和采样率后再做 ASR，输出需要包含时间码。多人对话再增加说话人区分；普通口播不必为了“完整”而引入不必要的说话人识别层。

视频

先拆出音轨和关键帧：音轨做 ASR，关键帧做 OCR 和视觉识别，最后按时间合并。没有必要一开始逐帧分析整段视频，可以先低频抽帧和全文转写，定位相关片段后再提高局部抽帧密度。

统一后的证据记录可以类似这样：

{
  "object": "某款精华",
  "attribute": "使用肤感",
  "value": "先润后黏",
  "source": {
    "platform": "example",
    "post_id": "原始ID",
    "modality": "text",
    "location": "字符区间或时间码"
  },
  "confidence": "needs_review"
}

这里的重点不是字段名称本身，而是每条结构化结论都带着来源和复核状态。

API、本地模型与轻量工作台

小批量验证可以先调用 API，数据量稳定后再把高频任务搬到本地。原文列举的常见组合包括 FFmpeg 做转码、拆音轨和抽帧，PaddleOCR 做本地文字识别，Whisper 做本地语音识别，以及云端 OCR、ASR 服务。

选型时不要只比较单价，还要用自己的真实样本测试方言、噪声、中英混合、竖屏字幕和截图小字。试用额度、并发限制、模型版本和服务价格会变化，上线前应查看服务商当前控制台和文档。

当任务会反复执行，可以做一个小型工作台：

文件或链接进入
  → 自动选择 OCR / ASR / 视觉工具
  → 查看原文与识别结果
  → 人工修正
  → 导出 JSON / CSV

工作台还应记录调用次数、耗时、费用和失败原因。运行一段时间后，团队才能判断哪些环节继续使用 API，哪些环节值得本地部署。API Key 只能放在环境变量或密钥管理系统中，不要写入导出的数据、日志和 Git 仓库。

第五步：发生冲突时，先回到证据

多模态处理很容易产生两个都像正确答案的结果。例如，ASR 把语音识别成 100，画面 OCR 却识别成 11000。直接选择置信度更高的一方，可能把错误数字一路带进统计和报告。

可以先建立证据等级：

等级	证据	处理方式
A	官方字段或人工确认结果	可作为当前事实
B	原图、原音频或原视频可以直接确认	保留位置并进入结构化结果
C	多个模型一致，且上下文吻合	可暂时使用，保留待抽查标记
D	单个模型识别或判断	不宜直接支撑关键结论
E	关键词、正则或简单规则产生的候选	只能用于召回或排队

发现冲突后，按时间码和图片位置回看原始证据，核对单位、上下文和发布时间。无法确认时，不要强行选择；把记录放进待核队列，不参加精确数值统计。

修正记录至少要保存原始值、修正值、证据等级、修正原因、复核状态和模型版本。原值不能被静默覆盖。

第六步：重复、低质量和异常分开处理

公开数据里通常同时存在广告、搬运、统一素材、乱码、无关内容和异常互动。这些状态不应被一个“删除/保留”开关混在一起。

先筛相关内容：关键词和词典负责尽量找全，语义模型补充简称、缩写和近义说法。再处理重复内容：完全复制、轻微改写、同图不同文和同视频再发布，可以放入同一个重复组，但原始记录仍要保留，统计时再决定按帖子、素材还是账号去重。

最后识别异常。发布时间、内容相似度、账号历史、发帖节奏和互动网络都可以作为信号，但风险分只负责把可疑内容排到前面。活动统一素材、媒体矩阵和合作账号也会高度相似，不能看见高分就直接删除。

建议把记录标为四种状态：

• 正常可用；
• 重复关联；
• 低质量，等待修复或隔离；
• 高风险，进入人工复核。

这样既保留了审计线索，也避免把模型的异常判断误当成删除命令。

第七步：从自然语言生成可查询字段

一句“这款精华刚涂上挺润，过一会儿有点黏，敏感肌可能要先试一下；同价位我还想看看另一款”，同时包含当前产品、即时肤感、后续肤感、适用人群、风险提醒、价格区间和对比意向。

只打一个“负面”或“中性”标签，后面几乎无法使用。更通用的字段可以分成五类：

1. 谁在表达，评价对象是谁；
2. 提到了什么产品、部件、功能或服务；
3. 对象之间发生了什么关系或事件；
4. 用户的观点、问题和意图是什么；
5. 判断依据是哪句原文、哪个图片位置或哪段音频。

规则稳定、频率高的任务交给规则和小模型；多语种、多对象、复杂指代和长文本再交给大模型。低置信结果进入人工复核。

让大模型按照固定 JSON 返回字段和证据，并提前写清字段名称、可选值、空值规则和错误处理。结构化输出只有经过 schema 校验、证据绑定和质量状态检查，才适合进入下游系统。

第八步：验收通过，再按版本入库

入库前至少检查：

• 原始内容、链接和平台 ID 是否完整；
• 评论能否回到原帖和上级评论；
• OCR、ASR 和视觉结果是否带位置或时间码；
• 冲突是否有处理状态，未确认值是否被排除在精确统计之外；
• 标签是否绑定了正确对象；
• 规则、模型、字段和修正是否有版本号。

团队还应准备一批人工确认过的测试样本，包括正常数据和容易出错的难例。每次更换模型或规则，都用同一批样本重新跑一遍，并记录准确率、漏检、误合并和需要人工接管的比例。

最终把原始数据、处理结果、质量状态和版本信息分开保存。这样才能重新处理、比较新旧结果，也能查清一条数据是在采集、识别、抽取、清洗还是入库阶段发生变化。

一条可以落地的最小路径

如果还没有成熟的数据平台，不必一开始就做全量自动化。可以按下面顺序验证：

1. 选一个明确业务问题和一小批有代表性的样本。
2. 建立数据字典，确定对象、关系、证据和验收条件。
3. 原样保存文件、链接、时间和平台 ID，再生成 OCR、ASR 和模型结果。
4. 用一批人工确认的难例测试冲突、重复、缺失和异常状态。
5. 把待核记录交给业务人员处理，记录修正原因和版本。
6. 通过验收后再扩展数据量、平台数量和自动化范围。

这条路径的核心不是“让模型一次洗干净”，而是让每一步都能回到证据、能被人工接管、能在换模型后重新运行。

来源与边界

• Miles Ma：FDE 实战案例｜数据清洗

本文整理的是原帖公开方法和工程化补充，不代表作者对所有平台、模型或服务的当前承诺。OCR、ASR、视觉识别、价格、并发和平台接口会随供应商版本变化；上线前请使用当前文档和自己的真实样本复核。社交平台数据还涉及隐私、平台条款和个人信息处理义务，采集、保存、跨平台关联和对外发布前应获得相应授权并设置访问控制。