這個議題的核心在於如何從供應鏈營運產生的海量非結構化數據中，提取出可操作的、有價值的知識。來源文件對「非結構化供應鏈知識問題」和「數據源挑戰」進行了深入的剖析，指出這是傳統知識管理和簡單的檢索增強生成（RAG）系統面臨的主要障礙。
魔鬼藏在細節裏，其實我并不想這麽說，但是事實就是如此。在輔導客戶導入AI的訪查中觀察到：同樣有管理制度的公司，要求工程師在幫客戶解決問題或者安裝施工，都要填寫安裝或施工報告。都有憑有據，但是落差很大，有的巨細靡遺，包含用料，解決過程，所花耗的時間…等等；但是有的卻是寫個OK了事。還有甚至所有的過程記錄都在Line對話裏，然後船過水無痕。這也就是我們以下要説的「非結構化」
以下是在「非結構化數據」的背景脈絡下，來源文件對「數據源挑戰」的具體看法：
——————————————————————————–
一、 核心問題：關鍵知識的隱藏與分散
供應鏈營運產生了海量的營運數據，但關鍵知識，例如系統使用規範、故障排除工作流程和解決技術，卻仍然隱藏在非結構化通訊中。這些非結構化來源包括支援工單、電子郵件、事件報告和聊天記錄。
這種知識的分散狀態，導致了以下管理挑戰：
- 機構知識的隔離:：營運知識往往分散在組織孤島中。許多寶貴的機構知識—即經驗豐富的團隊成員所知曉、但未正式記錄的非書面資訊、流程和專業知識——通常被隔離在專家的腦中，無法被自動化捕捉或重複使用。
- 知識的瞬時性與孤立性： 工單系統雖然記錄了營運異常和解決方案，是寶貴程序和專業知識的儲存庫，但這些知識通常孤立在通訊線程中。這導致解決方案被重複發現，而非重複使用。
二、 數據源的本質挑戰
當嘗試使用原始非結構化數據（如支援工單或聊天記錄）作為知識庫時，其原始數據品質成為 RAG 系統有效性的主要限制。
來源文件明確指出，供應鏈支援工單和聊天記錄通常具有以下關鍵缺陷：
- 嘈雜、不一致且不完整：這種低品質使得直接檢索（direct retrieval）成為一種次優（suboptimal）的選擇。
三、 實際工單系統中的具體挑戰
來源文件在討論用於實驗的真實世界供應鏈支援工單數據集時，詳細描述了數據源所面臨的兩大類挑戰：
1.內容挑戰
工單內容本身在表達上充滿不一致性，難以進行標準化處理：
- 描述細節不一 ：問題描述的細節程度各不相同。
- 術語和縮寫不一致 ：存在不一致的術語和縮寫。事實上，LLM 在處理領域特定的術語和縮寫方面仍然具有挑戰性。
- 多重通訊線程： 單一工單中包含多個通訊線程。
- 非標準化解決流程：解決流程缺乏標準化。
- 時間參照： 包含需要上下文理解的時間參照。
2.營運挑戰
數據的收集和記錄方式也造成了知識的不完整性：
- 風格差異：不同的支援團隊成員在不同時間參與，導致通訊風格多樣化。
- 數據不完整與上下文缺失：數據不完整，且缺乏必要的上下文。
- 側邊資訊未反映 ：來自平行通話或聊天記錄的側邊資訊未反映在工單中。
- 缺乏明確結案狀態：存在未結案且缺乏明確解決狀態的工單。
四、 數據挑戰對傳統 RAG 的影響
這些數據源挑戰直接限制了傳統或簡單 RAG 實施的性能：
- 冗餘： 類似問題重複出現在多個工單中，造成知識冗餘。
- 噪音：包含不相關或瞬時性資訊（例如：特定日期、工單 ID），這些內容稀釋了有用資訊。
- 缺乏泛化能力：原始工單數據難以從特定案例中提取出可泛化的模式。
- 無法應對複雜任務： 簡單的 RAG 擅長處理事實性查詢，但在需要掃描大量語料庫並合成答案的「掃描與收集」問題上則表現不佳。
結論：應對挑戰的「離線優先」策略
為了克服這些固有的數據挑戰，來源文件提出了「離線優先」（offline-first）方法論，而不是專注於執行時（runtime）優化。
這種方法論的目標是在 RAG 檢索發生之前，透過多代理系統執行複雜的知識組織和合成工作，從而：
將原始工單數據轉化為一個更緊湊、更易於管理且可維護的結構。
在檢索上下文中消除冗餘和噪音，同時提高信噪比。
提供更簡潔、更集中的文件供檢索，使 RAG 系統能夠使用更高品質的上下文。
最終，研究結果證明，透過離線知識合成處理，能夠將原始工單總體積減少到僅 3.4%，同時顯著提高 RAG 答案的有用性。
參考資料：arXiv:2506.17484v1 [cs.AI] 20 Jun 2025
鈳恩智聯，莊濠禧
