人工智慧驅動的聊天機械人可幫助使用者即時訪問常見資訊，而無需打擾專家。
翻譯自 Dev Nag 的《為什麼知識管理不起作用》。 DevOps和平台團隊經常被打斷工作的訊息所困擾，從已經回答了幾十次的一次性問題到文件中已經提供的資訊請求：“如何連線到資料庫？ 為什麼我的部署不起作用？ 此錯誤是什麼意思？ ”
這不僅僅是DevOps的情況，使用者正在傳送大量安全問題、合規性查詢、HR請求等。 沒有人願意浪費專家的時間和精力來回答這些重複的問題，但真的沒有更好的選擇。
這些中斷的後果遠遠超出了回答問題所花費的時間。 還有上下文切換的成本：加州大學歐文分校的研究人員發現，在中斷後，需要 25 分鐘才能完全恢復到之前的任務。 還有乙個更嚴重的機會成本，當高影響力的任務被重複性問題排擠並且積壓變得越來越多時，這種成本就會被擠出來。
DevOps 工程師工作的很大一部分是為其平台、管道、文件等提供內部支援。 團隊經常輪流解決多個通訊平台上的內部問題。 這些轉變使 DevOps 工程師和可靠性工程師 （SRE） 不再專注於構建使可靠性流程高效且一致的工具，這通常會導致疲勞和人員流失。 雖然DevOps團隊可能會為開發人員生成文件以自行獲取資訊，但大多數人不願意手動搜尋文件（通常儲存在不同的知識庫中）來查詢答案。 取而代之的是，團隊聊天是人們現在協作、提出問題並立即獲得有意義的答案的地方。 傳統知識管理的問題在於它側重於獲取和儲存資訊。 它沒有兌現知識共享和傳播的承諾; 相反，負擔仍然在提問者身上。 這導致DevOps團隊在團隊聊天中被訊息淹沒。 他們一遍又一遍地從不同的人那裡得到同樣的問題，他們沒有意識到他們的問題幾天前已經在同乙個頻道中得到了解答。 所以他們正在做他們一直在做的事情：進入Slack或Microsoft Teams並提出問題，知道專家會提供正確的答案。 採用檢索增強生成 （RAG） 和大型語言模型 （LLM） 的人工智慧 （AI） 聊天機械人是解決這個問題的一種方法。 通過從各種 ** 中獲取資訊，包括聊天頻道（包括 Slack 和 Teams）中先前回答的問題、知識庫、GitHub、Notion、Confluence 中社群生成的內容、公司上傳的文件、管理員指定的 ** 等，聊天機械人可以自動、即時地回答重複的問題。 提問者不必改變提問的方式或地點。 他們可以在不消耗專家時間的情況下獲得所需的資訊。 該技術對聊天對話中的非結構化資訊進行索引，並將其與來自各種知識庫的結構化知識相結合。 儲存此資料是為了快速語義搜尋，當搜尋找到與使用者查詢匹配或多個匹配項時，它會獲取相關資料並將其傳遞回 lln 以定義最佳響應。 這使聊天機械人能夠回答可能不完整或不準確的問題，總結其發現並引用其**。 這可以節省數小時的時間和精力，否則這些時間和精力將花費在手動回答重複性問題上。 這也節省了使用者的時間，因為它可以將所有最佳實踐、操作指南、流程、已解決的對話和常見問題即時提供給任何授權員工——所有這些都在聊天中。 資訊交到使用者手中，而不必搜尋不同的知識庫，這是與企業資料互動的有效方式。
這個人工智慧聊天機械人並不是要取代人類; 它旨在支援人們並消除雜務，以便團隊可以專注於影響更大的任務。
要了解如何實現在聊天中自動提供相關資訊的聊天機械人，請參閱 QueryPal 的入門指南。