企业知识库如何接入舆情分析 Agent？内部制度、历史事件与公开信息的联合研判

很多企业在做舆情预警时，遇到的最大障碍并不是"看不到舆情"，而是"看不懂自己"。公开信息侧已经可以通过网络舆情监测系统实时获取，内部侧却散落着制度文件、处置预案、历史事件复盘、客服话术。当 AI 舆情分析开始介入，把两堆资料塞进同一个上下文，问题立刻暴露：模型引用了一份早已废止的制度，把三年前的处置口径当成现行规则，或者把只对某个子公司有效的规定套到了集团层面。

乐思软件在服务政府、企业、高校的过程中反复看到同一类失败：知识库集成不是"接不上"，而是"接上了但依据失效"。因此本文提出一个核心观点——联合研判的关键不是把资料放在一起，而是确保每条依据在正确权限和时间范围内生效。

一、三个高频失效场景

1. 公开舆情与内部制度脱节

公开渠道出现集中投诉，舆情预警已触发，但回复口径需要的《客诉响应分级规范》还在某个部门的共享盘里，未进入检索范围。结果是分析师看到风险、却给不出合规的处置建议。

2. 历史事件无法复用

同类事件去年发生过，复盘报告写得很好，但因为标题命名随意、没有标签、没有适用范围字段，检索时排不进召回结果。经验沉淀在文档里，等于没有沉淀。

3. 模型引用内部材料不准确

检索增强生成（RAG）的常见故障是"引用幻觉"：模型确实召回了文档，却拼接了不同版本的条款，或者把摘要当成原文。对品牌声誉管理而言，错误引用的代价往往高于不回答。

二、联合研判的系统架构

建议把知识库到舆情分析 Agent 的链路拆成七层，每层只解决一个问题。

检索流程图（文字版）

三、四类来源的标签体系

联合研判的可靠性，取决于每条依据是否带齐四类元数据：来源标签、更新时间、适用范围、访问权限。

关键细节在于"废止日"字段。只写更新时间的知识库，无法回答"这条制度在事件发生时是否有效"。对于境外舆情监测场景，公开信息还需补充语种、国别与站点权威度标签，避免把低可信来源与本地监管文件混为一谈。

四、权限矩阵与硬性红线

五、旧制度、冲突版本与"检索不到"怎么办

旧制度：双时间轴检索

检索时同时携带两个时间：事件发生时间与当前时间。制度研判以事件发生时间为准，处置建议以当前生效版本为准，两者不一致时明确提示"制度已更新"。

冲突版本：不裁决，先暴露

Agent 不应自行决定哪一版更权威。正确做法是并列呈现冲突条款、各自的生效范围与签发层级，交由人工审批环节裁决，并把裁决结果写回知识库。

检索不到答案：允许说"不知道"

设置最低置信度阈值。低于阈值时输出"现有知识库无对应依据"，同时列出缺失的文档类型与建议补齐的责任部门。对舆情预警而言，一个诚实的空白远比一个编造的口径有价值。

六、模拟案例：公开投诉 + 内部处置规范的联合研判

以下为演示性模拟场景，非真实客户案例。

背景：某制造企业舆情监测系统在夜间触发预警，多个公开渠道出现集中投诉，指向某批次产品售后响应慢。

1. 公开信息侧：系统完成聚类，识别投诉量、增速、主要诉求与传播平台，标记为待研判事件。
2. 权限过滤：值班分析员身份为集团舆情岗，可读取集团级制度与历史事件，不可读取子公司财务类文件。
3. 检索召回：命中《客诉响应分级规范》现行版、《产品质量事件处置流程》V3、以及两年前的同类事件复盘。
4. 冲突识别：发现子公司层面存在一份更宽松的响应时限规定，与集团规范不一致，标记为需人工裁决。
5. 证据拼接：输出风险提示草稿，逐条标注依据来源、版本号、生效日期与适用范围。
6. 人工审批：品牌负责人确认口径后发布，同时将裁决结论与处置结果归档，回流为新的历史事件标签。

整个过程中，Agent 提供的是"可追溯的建议"，决策权始终在人。这也是当前企业 RAG 与智能体治理的共同方向：模型能力越强，越需要把权限与时效做成硬约束而非提示词约定。

七、持续监测与分析支持的分工

架构解决的是"依据是否可靠"，监测解决的是"事件是否被及时发现"。乐思网络舆情监测系统提供 7×24 的系统支持，覆盖境内与境外舆情监测场景，可用于舆情预警的持续触发；对研判人力不足的团队，乐思软件也可配备舆情分析师服务，与内部知识库的检索结果形成互补——系统负责广度与时效，分析师负责判断与口径。

品牌声誉管理从来不是一次性的响应，而是把每一次事件的判断依据沉淀回知识库，让下一次研判更快、更准、更有据可查。