本文介紹瞭如何結合NVIDIA Nemotron開放模型與圖形數據庫，構建一個能夠從非結構化IT支持工單數據中挖掘洞見、追蹤關聯關係的AI智能體系統。該系統包含模塊化數據處理管道、上下文增強、根因分析、洞見生成以及自動化警報與交付等核心階段，並通過交互式儀表板提供按需摘要功能。
現代組織通過工單系統、事件報告、服務請求、支持升級等產生大量的運營數據。這些工單通常包含有關係統性故障、重複出現的問題和團隊績效的關鍵信號。但從它們中提取洞見是一項挑戰。
大多數工單平台是為工作流執行而構建的，並非用於分析。結構化字段不一致，自由文本描述雜亂，工單之間的關聯關係很少被捕獲或可查詢。
因此，當領導層詢問...
“我們組織內最常見的重複性問題是什麼？”
“哪些團隊反覆處理相同的根本原因？”
“為什麼某些組解決工單的速度比其他組快或慢？”
“我們在哪些方面看到了解決質量或一致性的差距？”
...您只能拼湊脆弱的查詢、導出或電子表格——如果您嘗試的話。
ITelligence 是某機構內部IT組織構建的內部AI智能體，它結合了NVIDIA Nemotron開放模型的高級AI推理能力和圖形數據庫的表達能力。該智能體的目的有兩個：1) 通過有效利用LLM生成上下文洞見，揭示非結構化支持工單數據中隱藏的見解；2) 使用基於圖形的查詢來追蹤關係、識別異常並大規模發現模式。
這篇博客文章旨在分享我們的經驗，併為其他組織構建類似的、強大的AI驅動智能體提供實用指南。
雖然所描述的實施方案側重於IT運營，但所提出的架構和工作流程是領域無關的，可以應用於任何基於工單的環境，這些環境需要將非結構化記錄轉化為結構化洞見——包括安全事件響應、客户支持平台或設施管理系統。
構建基礎
系統的核心是一個模塊化、可擴展的數據管道，用於攝取、豐富和分析運營數據，以支持根本原因和洞見生成。該架構由以下關鍵階段組成：
1. 數據攝取與圖形建模
可以使用預定的提取、轉換、加載作業從多個企業系統中提取數據，包括IT服務管理平台、端點資產清單和身份源。我們選擇了基於批處理的方法，而不是使用流平台或事件驅動的攝取。這一決定是基於我們的用例可以容忍最終一致性。實時攝取對於我們的分析並非必需，定期ETL作業提供了一個更簡單、更易於維護的解決方案，這與我們的運營需求非常契合。
每個數據流都被規範化並加載到圖形數據庫中，其中實體被建模為節點，它們的關聯被建模為關係。這種圖形表示支持靈活的多跳查詢，這在傳統的關係型或扁平報告結構中實現起來成本高昂或非常複雜。
2. 上下文增強作業
為了用更豐富的上下文增強每個工單，可以運行增強作業，在工單生成時將輔助屬性與用户和設備關聯起來。示例包括：
- 工單發起者是否為新員工
- 設備類型
- 工作模式
- 僱傭類型
- 基於源標識符或請求來源判斷是用户創建還是機器人生成
這些增強可以為圖形增加語義深度，並使下游分析能夠按相關維度細分數據，而無需依賴用户填寫的字段。
3. 根本原因分析作業
確定真正的根本原因通常超出了標準ITSM分類的能力。為了解決這個問題，我們可以調用一個LLM管道，單獨處理每個工單。對於每個工單，我們可以傳入：
- 用户報告的問題
- IT人員的解決備註
- 任何已增強的元數據
然後，我們可以提示LLM提取一個簡潔的、以逗號分隔的根本原因關鍵詞列表，代表問題的真實本質。這些生成的RCA可以作為新屬性存儲在工單節點上，從而能夠實現超越傳統ITSM類別的精確分組和分析。
我們為此目的測試了通過NVIDIA NIM提供的不同開源模型，使用llama-3_3-70b-instruct獲得了最準確的結果。
4. 洞見生成作業
一旦工單通過結構化的RCA得到增強，我們就可以運行預定的洞見生成作業，使用LLM綜合組織或團隊級別的模式。這些作業可以針對不同的洞見類型進行提示工程：
- 平均解決時間洞見：系統可以選擇解決時間最長的工單，並提示LLM總結這些案例耗時長的原因——突出延遲、錯誤路由、依賴關係或標準操作程序中的差距。
- 客户滿意度洞見：對於客户滿意度得分低或用户反饋差的工單，可以生成執行級摘要，突出未滿足的期望、重複的投訴以及潛在的改進領域——按團隊或組織分組。
- RCA洞見：選擇最頻繁出現的根本原因的工單。可以提示LLM提取這些工單中的常見症狀、重複的解決步驟和高級別模式——使團隊能夠識別潛在的系統性問題。
- 新員工洞見：分析新員工打開的工單，以發現入職痛點和早期困難，向領導者提供關於差距和改進領域的清晰、可操作的反饋。
這些洞見可以關聯回圖形上下文，以提供針對每個領導者、團隊或服務所有者的、可操作的情報。
5. 分佈式警報和自動化洞見交付
為了使洞見可操作化，我們可以構建一個分佈式警報系統，持續評估圖形中的KPI趨勢。預定義的規則可以在指標偏離預期閾值時觸發通知——例如，平均解決時間激增、RCA重複出現或客户滿意度下降。這些警報可以直接發送給相關的領導者或經理，並提供上下文、受影響的工單和建議的關注領域。
該框架還可用於定期交付自動生成的、AI生成的通訊簡報。每份簡報可以根據組織或經理進行定製，並可以包括：
- 最主要的RCA和重複模式
- 影響平均解決時間等關鍵績效指標的高影響工單
- 來自低客户滿意度案例的用户反饋摘要
- 周度KPI趨勢
所有洞見都是LLM使用結構化提示和增強的工單數據生成的，確保每個利益相關者都能自動收到有針對性的、上下文感知的摘要。
這種以清晰的圖形建模和精確的提示工程為基礎的分層架構，使系統能夠擴展洞見生成，同時保持對新數據源、組織結構和用例的適應性。
設計直觀的AI驅動界面
由於一個豐富、高度連接的數據集為系統提供支持——涵蓋工單、用户、根本原因、組織層次結構、設備等——數據檢索需要既強大又易於訪問。用户不應該需要理解底層的圖形模式、編寫Cypher查詢或依賴自定義腳本來探索運營洞見。
我們需要一個界面，能夠：
- 允許用户按有意義的維度切片和過濾數據
- 支持結構化查詢和按需摘要
- 對沒有深厚技術專長的分析師和經理來説足夠直觀
- 減少歧義並提高在解釋用户意圖時的準確性
這引導我們評估兩種界面範式：對話式聊天機器人 和 交互式儀表板。
考慮到數據模型的複雜性以及在解釋用户意圖時需要精確性，我們有意選擇了後者——交互式儀表板——作為平台界面的基礎。它提供了一種清晰、可靠且用户友好的方式來導航和從高度結構化的圖形中提取洞見。
為什麼不用基於RAG的聊天機器人？
鑑於最近圍繞RAG和對話式AI的勢頭，很自然會問：為什麼不直接在圖形上構建一個聊天機器人界面？
雖然這個想法很吸引人，但我們認為它在實踐中存在不足，尤其是在處理豐富且高度關聯的模式時。
在這種情況下，底層數據庫包含許多互連的實體和屬性：工單、用户、設備、層次結構、根本原因、團隊、服務、分配組等。將開放式的自然語言查詢轉換為精確的、可執行的圖形查詢不僅不簡單，而且容易出錯且經常存在歧義。
我們的目標是提高用户工作效率，而不是讓用户在聊天機器人界面中來回交互以澄清其意圖。當用户需要答案時，他們應該快速準確地獲得答案，而無需猜測如何措辭問題才能讓系統理解。
推薦方法：具有按需摘要功能的AI驅動儀表板
為了使洞見既易於訪問又具有交互性，我們建議與交互式數據可視化平台集成，該平台由圖形數據庫和自定義摘要API服務提供支持。所有靜態數據，如指標、KPI、預生成的洞見、工單及其元數據，都可以實時從圖形中直接提取。
然而，一個手動操作的領域仍然存在：即使用户按標準篩選工單，他們仍需要手動查看單個工單以發現常見的痛點和解
決模式。這使得分析緩慢且難以確定系統性改進的優先級。
為了自動化此工作流程，我們可以引入一個直接連接到儀表板的摘要服務API。當用户選擇篩選條件時，這些變量可以作為JSON有效負載通過綁定到文本面板的數據源發送到摘要服務API。
在後端，摘要服務可以：
- 接收選定的標準
- 從圖形中檢索匹配的工單
- 將它們注入到結構化提示中
- 將提示發送到某中心的NIM API，用於基於LLM的摘要生成
- 將響應返回到數據可視化平台進行顯示
然後，輸出可以在AI生成的摘要面板中呈現，提供一個簡潔的執行摘要，包括：
- 常見問題和症狀
- 典型的解決路徑
- 重複出現的故障模式
- AI生成的建議
這消除了手動工單分類的需要，並從儀表板直接為團隊提供按需的、上下文相關的理解。
瞭解更多
這個AI智能體旨在彌補IT工單運營中的一個關鍵差距：從大量非結構化工單數據中獲取有意義洞見的挑戰。通過集成AI驅動的分析、基於圖形的建模和靈活的查詢，該平台將運營噪音轉化為清晰、可操作的情報。
從自動化的根本原因識別和豐富的上下文增強，到實時的執行摘要和主動警報，該智能體可以賦予團隊做出明智決策所需的清晰度和速度。
