数据质量提升与报告增强策略

• 目标：统一说明系统如何把抓取到的原始数据，逐步提升为适合检索、分析与 AI 总结的高质量输入
• 适用范围：雪球、公众号、知识星球、微信聊天记录等多种来源

1. 整体思路

本文说明一条从原始抓取到可用于检索、分析与 AI 总结的处理链路。重点不在于“直接把抓取结果交给模型”，而在于先完成清洗、抽取、筛选、评分、检索增强与上下文组织，再进入总结阶段。

原始数据质量提升，不是单点动作，而是一条流水线：

原始抓取 → 按来源原样入库 → 内容抽取 / 文本清洗 → 质量特征计算 → 统一检索层 → 关键词 / 语义混合增强 → 输入组织 → AI 总结

核心原则：

1. 原始数据保留，不要直接把源数据“改写到只剩一份处理后的版本”
2. 来源侧原始结构与统一检索层分离，每个来源保留自己的真实结构，统一检索层只承接“可搜索、可召回、可比较”的公共视图
3. 不是所有来源都用同一套清洗强度，噪音大的来源要强过滤，信号高的来源可以轻处理
4. 不是所有历史内容都应平等进入模型输入，需要经过评分、分流与检索增强筛选
5. AI 负责总结，不负责替代前面的数据治理

2. 一页式总览：原始数据是如何变成高质量 AI 输入的

3. 为什么不能把原始抓取结果直接喂给 AI

如果把原始数据直接丢给模型，通常会出现四类问题：

1. 噪音放大

   • 目录、合集门槛、图片占位、短回复、闲聊会和真正信息混在一起
   • 模型很容易把“看起来像内容”的噪音也总结进去

2. 主题拆散

   • 同一主题在不同来源、不同作者处会有完全不同的表达方式
   • 不做聚类和混合召回，模型容易把同一件事写成 3-5 条分散要点

3. 历史缺失

   • 当前窗口的信息往往只是“延续、强化、反转”中的某一种
   • 没有历史上下文，模型只能做静态描述，很难判断这是新变化还是老逻辑复读

4. 高低信号混淆

   • 一条高价值订单验证，和十条低质量闲聊，在模型可分配的注意力里往往是平等的
   • 如果不做评分和分流，模型容易被“多但弱”的内容带偏

因此，更稳妥的做法不是“抓到就总结”，而是：

先把原始数据变成高质量输入，再让 AI 做总结。

4. 数据质量提升流水线

4.1 原始抓取与按来源原样入库

先把内容按来源原样进入各自的原始数据层，而不是一开始就合并成单一结构。

目的：

• 保存完整原始上下文
• 保留来源特有字段
• 为后续清洗、重算与回溯提供底稿

4.2 附件与正文抽取

对于不是纯文本的内容，需要先把“可读文本”抽出来：

• 文章正文抽取
• 图片 OCR
• PDF 文本提取
• 后续可能的音频转写 / 富文本还原

这一步的作用，是把原始附件变成后续可检索、可评分、可聚类的文本输入。

4.3 文本清洗

清洗不是为了“美化文本”，而是为了去掉会污染检索和总结的噪音，例如：

• HTML 标签
• 付费提示 / 合集门槛
• 图片占位文本
• 重复模板句
• 纯互动式短回复
• 无信息量寒暄

清洗后的文本，会成为后续检索、评分、主题归类与上下文召回的共同基础。

4.4 质量评分

评分的目的不是给内容做“好坏审判”，而是帮助系统判断：

• 哪些内容适合进【核心动态】
• 哪些适合只做补充
• 哪些应进入低信号样本
• 哪些不该主导全文

常见评分信号包括：

• 文本长度
• 是否包含订单 / 出货 / CapEx / 渗透率 / 目标价 / 客户等硬信息
• 是否包含观点、分歧、判断、验证
• 是否有高质量正文
• 是否只是短回复、图片占位、口语化情绪表达

4.5 低信号样本分流

不是所有被抓到的内容都适合作为“主样本”。

报告链路通常会把样本拆成：

• 有效样本：默认用于总结主干
• 低信号样本：默认不进入核心动态，除非其中存在独立信息增量

这样做的作用：

• 不让闲聊、短回复、目录、合集门槛把 AI 带偏
• 保留可回看性，但不污染主判断

4.6 主题标记

为了提高归组质量，会先给样本打主题标签，例如：

• AI应用/模型更新
• 光通信/CPO/设备链
• 存储/CPU链
• 订单/业绩验证

但标签不是静态真理，需要持续调参。

例如：

• 如果内容只是 AI 需求向封测 / 测试 / 光模块 / 材料 / 电源等硬件链传导
• 就不应误归入“AI应用/模型更新”
• 而应按对应硬件链主题或其他交易线索处理

4.7 统一检索层

在统一检索层中，把不同来源的可检索文本投影成可比较的公共视图，统一支持：

• 结构化过滤
• 关键词检索
• 模糊检索
• 语义检索
• 混合召回

4.8 报告前检索增强

报告生成前，不是直接“把当前窗口所有文本扔给模型”，而是做：

• 读取数据侧已经准备好的检索结果与语义索引
• 对近窗内容做一次轻量新鲜度补齐检查
• 当前窗口主题聚类
• 历史相似上下文召回
• 结构化输入组织

在这种设计里：

• 主要的向量化与索引工作尽量前移到数据流水线完成
• 报告生成前只保留小额度的新鲜度兜底

这样既能保证新鲜度，也不会把主要计算压力压在出报告那一刻。

5. 报告检索增强的核心策略

报告类能力通常优先采用：

时间窗主查询 + 关键词 / 语义混合增强

含义是：

1. 当前窗口主事实仍由时间窗硬过滤保证
2. 关键词检索、语义检索与混合召回 主要用于：
   • 同主题不同说法合并
   • 历史相似上下文补充
   • 主题延续 / 强化 / 分歧 / 转向判断
3. 各来源只是过滤维度，不应该每个来源重新发明一套完全不同的搜索逻辑

6. 参数说明：主题聚类阈值、回看范围与上下文数量到底在做什么

这一部分专门解释报告增强里的关键参数。

6.1 主题聚类阈值（clusterSimilarityThreshold）

作用： 决定当前窗口内两条样本是否应合并成同一个主题簇。

直觉理解：

• 阈值更高 → 更保守，只有非常相似的内容才会合并
• 阈值更低 → 更激进，不同表达更容易被合并

影响：

• 太高：同一主题被拆散，报告重复
• 太低：不同主题被硬并，报告失真

6.2 历史回看范围（contextLookbackDays）

作用： 历史上下文回看多远。

直觉理解：

• 天数更短 → 更贴近近期脉络，背景更“新”
• 天数更长 → 能补更多历史线索，但也更容易把老信息拉进来

影响：

• 太短：缺乏主题延续背景
• 太长：容易引入过时信息或扩大噪音

6.3 历史相似度下限（contextSimilarityThreshold）

作用： 决定历史语义召回的相似度下限。

直觉理解：

• 阈值更高 → 只保留更像当前主题的历史内容
• 阈值更低 → 更容易召回“边上沾一点”的内容

影响：

• 太高：历史上下文不够，主题延续判断偏弱
• 太低：历史背景变脏，容易混入口语化、弱相关内容

6.4 单个主题的历史上下文条数（maxContextPerCluster）

作用： 每个主题簇最多保留多少条历史上下文给模型看。

直觉理解：

• 数量更少 → 输入更干净，更适合小时报
• 数量更大 → 背景更充分，更适合晨报/晚报/周报

影响：

• 太少：上下文不够，模型容易只看当前窗口
• 太多：输入过重，模型容易被历史背景带跑偏

6.5 单篇报告展示的主题数（maxPromptClusters）

作用： 一个报告里最多展示多少个主题簇。

直觉理解：

• 更少 → 聚焦主线
• 更多 → 覆盖更全，但可能稀释重点

6.6 近窗补齐额度（embedSyncLimit / embedSyncRounds）

作用： 控制报告生成前，为近窗样本补多少语义索引、补几轮。

直觉理解：

• 更大 / 更多轮 → 覆盖更全，但更慢
• 更小 / 更少轮 → 更轻量，但可能来不及把近窗样本补齐

补充说明：

• 这两个参数更像报告侧的 freshness safety net（新鲜度兜底）
• 它们的意义不是“每次报告都重做一遍向量索引”，而是对近窗里尚未完成语义索引或文本刚变化的文档做有限补齐
• 更适合的结构是：数据侧负责大部分向量化处理，报告侧只保留小额度兜底
• 因此这两个参数更适合被理解为“最后一道新鲜度保险丝”，而不是主工作量控制器

6.7 参数的实际调优思路

一般顺序建议：

1. 先调 样本清洗 / 低信号分流
2. 再调 clusterSimilarityThreshold
3. 再调 contextSimilarityThreshold
4. 最后调 回看范围和上下文条数

因为如果脏样本本身没处理好，后面所有参数都会被污染。

7. 按来源的差异化策略

7.1 雪球（Xueqiu）

判断：噪音中等偏高，必须做筛选与分流。

处理策略：

• 保留时间窗内的雪球原始数据直查能力
• 用质量特征层做基础质量分级与主题标记
• 做低信号样本识别：
  • 短回复
  • 图片占位 / 查看图片
  • 评论区互动 / 交流贴
  • 过短且无主题、无硬信息增量的帖子
• 收紧 AI应用/模型更新 标签的使用边界
• 在输入组织时拆成：
  • 有效样本
  • 低信号样本
• 最近窗口的语义索引优先在数据侧完成：
  • 同步轮次尾部做有限补齐
  • 报告生成前只保留小额度新鲜度兜底
• 对小时报的历史上下文继续收紧：
  • 更高相似度阈值
  • 更少的上下文条数
  • 过滤口语化 / 跟风式 / 起哄式上下文

结论：

• 雪球需要 清洗 + 评分 + 低信号分流 + 更严格的上下文管控

7.2 公众号（WeChat MP）

判断：噪音中等，需要清洗，但比雪球更像长文资料流。

处理策略：

• 保留时间窗内的公众号原始数据直查能力
• 用质量特征层记录：
  • 清洗后正文
  • 质量分层
  • 主题标签与主主题
• 做有效文章识别与低信号文章分流
• 收紧 AI应用/模型更新 标签的使用边界
• 主入库批次尾部做有限补齐与语义索引更新
• 正文补全后如文本明显变长，再做小额度语义索引重补
• 关键词 / 语义混合召回重点用于：
  • 同主题长文归并
  • 历史文章补上下文
  • 减少同主题长文反复展开

结论：

• 公众号需要 清洗 + 适度评分 + 低信号分流
• 重点在“长文归并”，不是像雪球那样强力压回复噪音

7.3 知识星球（ZSXQ）

判断：高信号来源，通常不需要做雪球/公众号那种重清洗与重评分。

处理策略：

• 保留时间窗内的知识星球原始数据直查能力
• 自动串联附件抽取、检索刷新与语义索引更新
• 报告增强时：
  • 可直接用窗口样本进入聚类
  • 以语义检索和混合召回做历史资料补充
  • 以圈子 / 时间 / 主题为主过滤维度
• 默认不必先引入复杂清洗分数体系
• 如后续某些圈子噪音高，再做圈子级例外规则

结论：

• ZSXQ 默认应走：高信号资料流策略
• 重点是 聚类 + 背景召回，不是先做重筛噪

7.4 微信聊天记录（WeChat Chat）

判断：高噪音、高隐私、高上下文依赖，必须重清洗 / 重评分 / 重过滤。

处理策略：

• 不建议把每条聊天消息直接当报告样本
• 应优先按：
  • 会话
  • 时间段
  • 线程 / 话题块
    聚合后再决定是否进入报告层
• 必须先做：
  • 敏感信息边界定义
  • 低信号过滤
  • 会话窗口级清洗
  • 可检索 / 不可检索分层

结论：

• 微信聊天记录必须走：强过滤 + 强脱敏 + 强上下文聚合
• 不能直接复用 ZSXQ 的高信号策略

8. 适用边界与迁移条件

这套流程更适合以下场景：

• 数据来自多个来源，且噪音水平不一致
• 需要同时支持检索、分析与时间窗总结
• 当前窗口之外，历史上下文也会影响结论判断
• 希望在保留原始数据可回溯性的前提下，提高 AI 输出稳定性

如果要迁移到其他场景，建议优先确认以下前提：

• 是否保留了按来源存放的原始数据
• 是否能区分高信号样本与低信号样本
• 是否具备统一检索层，而不是各来源各自为战
• 是否具备历史上下文召回能力
• 是否允许按来源设计差异化策略，而不是一刀切复用同一套规则

如果这些前提尚不成立，应先补数据治理和检索层，再讨论总结模型的输出质量。

9. 真实案例：原始抓取数据如何变成可总结输入

下面两个案例用于说明这套方法不是抽象概念，而是可以落到真实处理链路中的。

9.1 案例一：雪球小时报（2026-05-11 20:00-21:00）

这个窗口里，原始抓取到的内容并不天然“适合总结”。里面同时混着：

• 先进封测设备交期拉长的高质量产业信息
• 关于光通信估值的观点型讨论
• 汽车销量与新能源渗透率的数据型讨论
• 多条短回复、闲聊、图片占位、口语化感想

如果把这些原始帖子直接喂给模型，风险是：

• 模型会把闲聊也当成“新增动态”
• 同一主题会被拆散
• 历史背景会被弱相关口水话污染

处理方式如下：

1. 原始帖子先进入雪球原始数据层
2. 计算质量分层与主题标签
3. 执行低信号样本分流
4. 数据侧优先完成检索刷新与语义索引补齐
5. 报告前只做轻量新鲜度检查
6. 对当前窗口样本做主题聚类
7. 对每个主题簇只召回少量高相关历史上下文
8. 再把“有效样本 + 历史上下文 + 低信号样本”分层组织成模型输入

该窗口在调参后，实际效果是：

• 原始样本仍全部保留
• 但模型输入中已拆成：
  • 有效样本：3
  • 低信号样本：6
• 口语化历史上下文（如“笑死”“抢不到”“世界和平”等）被过滤出主背景
• 最终报告聚焦成 3 条主线：
  • 先进封测 / 测试设备瓶颈
  • 光链估值分歧
  • 汽车总量偏弱但新能源渗透率继续走高

这个案例说明：

• 不是原始数据不够，而是原始数据里“强信号”和“弱信号”混在一起
• 经过分流、聚类和上下文收口后，模型才能稳定聚焦真正有价值的变化

9.2 案例二：公众号小时报（2026-05-11 20:00-21:00）

公众号的原始数据问题和雪球不同。
它不是回复噪音多，而是经常夹带：

• 合集门槛
• 付费提示
• 目录式文字
• 标题党或信息密度不高的短文

如果直接把这些文章原文丢给模型，常见后果是：

• 模型把合集说明、目录提示也总结进去
• 多篇同主题长文被重复展开
• 长文里真正重要的订单、景气、验证线索没有被压缩成结构化主线

处理方式如下：

1. 原始文章先进入公众号原始数据层
2. 做正文清洗，得到可用于分析的清洗文本
3. 计算质量分层与主题标签
4. 识别有效文章与低信号文章
5. 主入库批次尾部优先完成检索刷新与语义索引补齐
6. 如果后续正文补全让文本明显变长，再做小额度语义索引重补
7. 报告前只做轻量新鲜度检查
8. 对同主题长文做聚类与历史上下文召回
9. 再把结构化样本交给模型总结

该窗口在实际演练中，表现为：

• 原始文章数：5
• 可用文章数：4
• 低信号文章数：1
• 最终主线收敛为：
  • 存储重估
  • 光互联 / 器件 / 连接件景气验证
  • SpaceX 硬件链映射
  • 上游硅片与材料盈利传导

这个案例说明：

• 公众号的重点不是“压短回复噪音”
• 而是“把长文里的有效信息提纯、归并、去重复”

9.3 从案例里可以提炼出的通用经验

无论是雪球还是公众号，真正决定总结质量的，不是“模型聪不聪明”，而是：

1. 是否保留原始数据以便回溯
2. 是否先做清洗和特征计算
3. 是否把低信号样本从主样本里分流出来
4. 是否给模型补了正确、干净、不过量的历史上下文
5. 是否按主题组织输入，而不是把所有文本平铺塞给模型

10. 常见失败模式

这一节专门总结：为什么一套“看起来已经抓到数据”的系统，最后仍然会产出低质量总结。

10.1 直接把原始数据扔给模型

最常见，也最致命。

表现：

• 模型把目录、付费提示、短回复、图片占位也写进摘要
• 主线不清楚，噪音和正文混在一起
• 相同主题被重复写好几次

本质问题：

• 不是模型不会总结，而是输入本身没有经过治理

10.2 只有清洗，没有分流

有些系统会做基础清洗，但还是把所有内容一股脑交给模型。

表现：

• 看起来文本已经“干净”了
• 但低价值样本仍然占据大量输入篇幅
• AI 被大量弱信号内容带偏

本质问题：

• 清洗解决的是“脏文本”
• 分流解决的是“弱信号样本”
• 这两件事不能互相替代

10.3 只有评分，没有主题归并

给每条内容打了高低分，但没有做聚类与主题合并。

表现：

• 高分内容很多，但它们可能其实都在说同一件事
• 报告看起来“信息丰富”，实际是在重复不同措辞的同一主题

本质问题：

• 评分只能帮助排序
• 不能解决“同主题不同说法”这个问题

10.4 历史上下文太少

为了追求输入简洁，把历史背景压得太薄。

表现：

• 报告只会写“今天发生了什么”
• 很难判断这是新变化、旧逻辑延续，还是对旧观点的修正

本质问题：

• 当前窗口信息本身往往是不完整的
• 没有历史上下文，就很难做“变化判断”

10.5 历史上下文太多或太脏

另一个极端，是拼命给模型补背景。

表现：

• 历史材料淹没当前窗口事实
• 小时报写得像长文复盘
• 甚至把旧信息当作当前新增动态

本质问题：

• 历史上下文不是越多越好
• 历史上下文必须控制：相似度、数量、时间范围、语气质量

10.6 标签体系过宽，导致主题误归类

典型例子就是：

• 只要出现“AI”字样，就都被打进“AI应用/模型更新”
• 结果封测、测试、光模块、材料、电源这些硬件链内容也被归错类

表现：

• 主题章节看起来完整，实际上归类混乱
• 读者会误以为“应用侧有新增”，但实际是硬件链景气传导

本质问题：

• 标签是辅助系统，不是真理
• 如果标签边界太宽，反而会污染报告结构

10.7 参数调优顺序反了

很多时候团队一上来就调主题聚类、回看范围和历史上下文参数，但前面的数据治理还没稳定。

表现：

• 参数越调越多
• 输出还是不稳定
• 最后很难判断问题到底出在噪音、评分、聚类还是历史上下文

更合理的顺序是：

1. 先稳住清洗
2. 再稳住低信号分流
3. 再调标签边界
4. 再调主题聚类阈值
5. 最后调回看范围和历史上下文

10.8 把所有来源当成同一种数据

这也是常见错误。

表现：

• 用同一套规则处理雪球、公众号、知识星球、聊天记录
• 结果不是过清洗，就是不过滤

本质问题：

• 雪球更像碎片化交易流
• 公众号更像长文资料流
• 知识星球更像高信号研报流
• 微信聊天记录更像高噪音上下文流

统一框架是对的，但不同来源的策略必须分层。

11. 推荐落地顺序

如果把这套方法迁移到更多场景，建议顺序是：

1. 先从噪音中等、业务价值高的来源开始
2. 再把数据侧向量化处理与报告侧兜底分层清楚
3. 然后把同样的方法复用到高信号来源
4. 最后再处理高噪音、高隐私、高上下文依赖的聊天类数据

原因：

• 中等噪音来源更容易体现清洗、分流、聚类、检索增强的价值
• 在来源数量扩展之前，先把“数据侧主做、报告侧兜底”的职责边界收清楚，整体会更稳
• 聊天类数据的风险与设计边界最多，应最后做

12. 一句话版结论

• 雪球：要清洗、要评分、要低信号分流、还要更严格的上下文管控
• 公众号：要清洗、适度评分、偏长文归并
• 知识星球：默认高信号，不必重清洗，重点做聚类和背景召回
• 微信聊天记录：高噪音高隐私，必须重过滤、重聚合、重边界控制