Siebel 開發者對服務請求搜尋中檢索增強生成的實務解析

每個採用 Siebel 的支援服務台都曾遇過這樣的情境：一位客戶反映「應用程式在我登入後立刻凍結」。三個月前，另一位客戶提交了一張工單，內容為「系統在儀表板載入前卡住」。這兩個問題極可能共用相同的根本原因與相同的解決方案。然而，在大多數組織已依賴長達二十年的傳統關鍵字搜尋下，這兩張服務請求永遠不會被關聯在一起。一位支援人員解決了問題、記錄下來並關閉工單——而下一位支援人員卻只能從零開始，因為搜尋引擎只比對輸入的確切字詞，而非背後的意圖。

Siebel 26.6 如何改變檢索模型

Siebel 26.6 透過導入 RAG（檢索增強生成）驅動的搜尋功能來解決這項長期存在的缺口。新系統不再依賴字面關鍵字比對，而是先摘要傳入的服務請求，將該摘要轉換為嵌入向量，再針對 OpenSearch 向量索引執行語意相似度搜尋。此方式能將用詞不同的工單對應到相同的底層含義，從而呈現關鍵字搜尋會遺漏的過往解決方案。

檢索範圍涵蓋歷史服務請求與相關的 Fusion 知識庫文章，為支援人員提供更廣的解決背景。系統支援下鑽功能與並排的解決方案比較，讓代理人員能夠評估類似問題過去是如何處理的。此外，系統還能透過將新建請求關聯為既有請求的子請求，來維持組織內部的層級關係。

導入考量

從實作角度來看，Siebel 26.6 中的 RAG 功能可進行配置，且作為 Siebel 平台的內建元件交付，而非需要獨立的技術堆疊。這一點值得關注，因為 Siebel 於 2006 年被 Oracle 收購後至今仍廣泛部署於大型企業，過去一直需要自訂整合才能實現進階搜尋功能。將 RAG 原生嵌入平台，與更廣泛的產業趨勢一致——包括 Salesforce、ServiceNow 和 Microsoft 在內的企業應用廠商，正競相將生成式 AI 檢索功能直接建入其支援與 CRM 工作流程中。

然而，作者提醒有幾項因素需要關注。資料品質依然至關重要——語意檢索的有效性在很大程度上取決於底層服務請求歸檔的整潔度與完整性。基於 LLM 的摘要步驟也帶來了效能與合規方面的權衡，組織必須加以評估，尤其是在受監管的產業中，工單資料可能包含受 GDPR、HIPAA 或類似法規規範的敏感客戶資訊。

作者強調，排序後的搜尋結果應被視為支援人員的決策輔助工具，而非自動判定結果。在決定適當的解決路徑時，人為判斷仍然不可或缺。

長期價值與上線建議

支持語意搜尋的一個核心論點在於其價值會隨時間複合增長。隨著每張關閉的工單不斷擴充可搜尋的「已解決問題」知識庫，未來的解決速度將逐步提升。對於擁有龐大 Siebel 歸檔的組織而言——部分歸檔甚至涵蓋數十年累積的支援歷史——這種複合效應可為支援團隊帶來顯著的生產力提升。

作者建議在全面上線前，先以雜亂的真實歸檔資料進行驗證，確保系統在實際環境下能穩定運作。評估 Siebel 26.6 的組織也應關注 Oracle 如何持續將 AI 能力整合到其更廣泛的 Fusion Applications 套件中，因為未來的版本可能會在此檢索基礎上進一步擴展。