企業知識庫如何接入輿情分析 Agent？內部制度、歷史事件與公開信息的聯合研判

很多企業在做輿情預警時，遇到的最大障礙並不是"看不到輿情"，而是"看不懂自己"。公開信息側已經可以通過網絡輿情監測系統實時獲取，內部側卻散落着制度文件、處置預案、歷史事件覆盤、客服話術。當 AI 輿情分析開始介入，把兩堆資料塞進同一個上下文，問題立刻暴露：模型引用了一份早已廢止的制度，把三年前的處置口徑當成現行規則，或者把只對某個子公司有效的規定套到了集團層面。

樂思軟件在服務政府、企業、高校的過程中反覆看到同一類失敗：知識庫集成不是"接不上"，而是"接上了但依據失效"。因此本文提出一個核心觀點——聯合研判的關鍵不是把資料放在一起，而是確保每條依據在正確權限和時間範圍內生效。

一、三個高頻失效場景

1. 公開輿情與內部制度脫節

公開渠道出現集中投訴，輿情預警已觸發，但回覆口徑需要的《客訴響應分級規範》還在某個部門的共享盤裏，未進入檢索範圍。結果是分析師看到風險、卻給不出合規的處置建議。

2. 歷史事件無法複用

同類事件去年發生過，覆盤報告寫得很好，但因爲標題命名隨意、沒有標籤、沒有適用範圍字段，檢索時排不進召回結果。經驗沉澱在文檔裏，等於沒有沉澱。

3. 模型引用內部材料不準確

檢索增強生成（RAG）的常見故障是"引用幻覺"：模型確實召回了文檔，卻拼接了不同版本的條款，或者把摘要當成原文。對品牌聲譽管理而言，錯誤引用的代價往往高於不回答。

二、聯合研判的系統架構

建議把知識庫到輿情分析 Agent 的鏈路拆成七層，每層只解決一個問題。

檢索流程圖（文字版）

三、四類來源的標籤體系

聯合研判的可靠性，取決於每條依據是否帶齊四類元數據：來源標籤、更新時間、適用範圍、訪問權限。

關鍵細節在於"廢止日"字段。只寫更新時間的知識庫，無法回答"這條制度在事件發生時是否有效"。對於境外輿情監測場景，公開信息還需補充語種、國別與站點權威度標籤，避免把低可信來源與本地監管文件混爲一談。

四、權限矩陣與硬性紅線

五、舊制度、衝突版本與"檢索不到"怎麼辦

舊制度：雙時間軸檢索

檢索時同時攜帶兩個時間：事件發生時間與當前時間。制度研判以事件發生時間爲準，處置建議以當前生效版本爲準，兩者不一致時明確提示"制度已更新"。

衝突版本：不裁決，先暴露

Agent 不應自行決定哪一版更權威。正確做法是並列呈現衝突條款、各自的生效範圍與簽發層級，交由人工審批環節裁決，並把裁決結果寫回知識庫。

檢索不到答案：允許說"不知道"

設置最低置信度閾值。低於閾值時輸出"現有知識庫無對應依據"，同時列出缺失的文檔類型與建議補齊的責任部門。對輿情預警而言，一個誠實的空白遠比一個編造的口徑有價值。

六、模擬案例：公開投訴 + 內部處置規範的聯合研判

以下爲演示性模擬場景，非真實客戶案例。

背景：某製造企業輿情監測系統在夜間觸發預警，多個公開渠道出現集中投訴，指向某批次產品售後響應慢。

1. 公開信息側：系統完成聚類，識別投訴量、增速、主要訴求與傳播平臺，標記爲待研判事件。
2. 權限過濾：值班分析員身份爲集團輿情崗，可讀取集團級制度與歷史事件，不可讀取子公司財務類文件。
3. 檢索召回：命中《客訴響應分級規範》現行版、《產品質量事件處置流程》V3、以及兩年前的同類事件覆盤。
4. 衝突識別：發現子公司層面存在一份更寬鬆的響應時限規定，與集團規範不一致，標記爲需人工裁決。
5. 證據拼接：輸出風險提示草稿，逐條標註依據來源、版本號、生效日期與適用範圍。
6. 人工審批：品牌負責人確認口徑後發佈，同時將裁決結論與處置結果歸檔，迴流爲新的歷史事件標籤。

整個過程中，Agent 提供的是"可追溯的建議"，決策權始終在人。這也是當前企業 RAG 與智能體治理的共同方向：模型能力越強，越需要把權限與時效做成硬約束而非提示詞約定。

七、持續監測與分析支持的分工

架構解決的是"依據是否可靠"，監測解決的是"事件是否被及時發現"。樂思網絡輿情監測系統提供 7×24 的系統支持，覆蓋境內與境外輿情監測場景，可用於輿情預警的持續觸發；對研判人力不足的團隊，樂思軟件也可配備輿情分析師服務，與內部知識庫的檢索結果形成互補——系統負責廣度與時效，分析師負責判斷與口徑。

品牌聲譽管理從來不是一次性的響應，而是把每一次事件的判斷依據沉澱回知識庫，讓下一次研判更快、更準、更有據可查。