在去年十一月 ChatGPT 出現在我眼前之後，第一個想法就是 LLMs 勢必將會快速的掃除 Chatbot 這樣一個應用領域在過去遇到的許多問題，毫無意外的，聊天機器人現在嚴然是最多開發者實踐 LLMs 的 downstream task。根據 Gartner 的一些報告，他們預期到 2027 年，聊天機器人將成為所有組織中 25% 的主要溝通渠道。
這種採用速度相當驚人，但也存在危險。聊天機器人可以非常有說服力地杜撰事實，而要像對真人一樣給聊天機器人設置指引也更加的困難。所以，如果你客服渠道後面部署了一群真人客服，他們會受過關於如何談論你的公司、不該說什麼、應該說什麼以及要禮貌等各方面的培訓。但對於 LLM-based 的聊天機器人來說在實務上是一件相當困難的事情，實作過你就會清楚的知道開發出一個 ChatGPT 的體驗跟直接與 OpenAI 的 API 串接完全是兩碼子難度的事情。
所以，當我們想要聊天機器人真正代表一個組織時，僅僅是串接上 chat completion API 絕對是組織自殺的最快路徑之一。真要導入 LLM-based 客服，中間要做的事情實在是太多了，我們需要更多技術與方法論來真正部署有用的 AI。因此，這就跟我接下來想要跟各位一起探索的 #Guardrails 有關。
Guardrails 是 NVIDIA 釋出的一個函式庫，主要用來幫助我們能夠更加安全地部署 LLM-based Chatbot。但實際上，我們可以用它做很多更多的事情。我們可以將其用於安全性、主題指引等，也可以將其用於更高階的使用。我們可以用它構建 Agents，用它進行 #RAG，當然也可以用它定義更加明確的對話流程。簡言之，如果一家公司要投資並部署聊天機器人卻不使用 Nemo Guardrails 或某種類似的 Guardrails 系統，我想都不敢想其下場會如何。就現階段我的實驗結果來說，如果你沒有這些機制，事情很容易就會 mess up。
在 LLM-based Chatbot中，最直接的作法就是讓我們的 Conversational AI（或我們的 Agents）直接的面向終端用戶。這很簡單就能做出原型，但是如果出了問題，例如用戶開始詢問我們不希望聊天機器人回應的內容，比如政治或是武器製作；或者我們的聊天機器人開始談論我們也不希望它回應的內容，或者它的回應方式不代表我們希望的，那麼我們就有大麻煩了。這機制下可說是沒有任何檢查和防禦機制。
儘管我們可以通過提示工程稍微改善這個情況，但是提示工程的作用其實也很有限，防禦率永遠都無法達到 100%，總會有問題發生的情形。理想情況下，我們希望在中間有一些機制，誒也就是 Guardrails，它可以檢查在用戶和聊天機器人之間傳遞的信息，並據此做出相應的反應。例如，如果用戶開始談論違禁品製作，我們可以設計好一條預設的消息或者讓機器人生成一些罐頭訊息，如 “對不起,我無法談論違禁品相關” 的消息。
這就是 Guardrails 背後的核心思想，不過 NVIDIA NeMo Guardrails 非常的強大，能用它做到不僅僅是為聊天機器人添加一些安全性。我們在此建立的是 deterministic 的規則，指定如果用戶開始談某些主題，我們希望 LLM-based Chatbot 做出某種反應。那個反應可以是安全措施，或者在用戶詢問我們產品的情況下，我們可能不希望他簡單地說 “對不起，我無法談論產品”，而是想從資料庫或是 Vector Store 中檢索出信息以便聊天機器人可以透過 RAG 更準確地回答問題。
我們也可以透過 NVIDIA NeMo Guardrails 指定更加明確的對話流程。也許我們會發現許多用戶都在詢問同樣的問題，都在走同樣的對話路徑。在這種常見對話的情形下，我們可以為其創建 rails，攔截問題並給出特定的回應，從而實現更加明確的對話流程，直到為用戶達成某種最終解決方案。
這種明確的對話流程就很類似聊天機器人過去 IVR 風格的運作方式。在 ChatGPT 之前，對話系統通常會設定一系列固定的對話路徑，你需要在對話中選擇提供的選項。這種明確的對話流程實際上很有用，但也受到限制。所以在某些場景下我們仍希望使用這樣的傳統機制，特別是對於那些我們可以提供幫助的常見對話。但與此同時，我們也不希望限制用戶只走這些 IVR 風格的對話流程，而是希望有更加靈活的會話AI 行為，如 ChatGPT 那樣。
上述都只是 Guardrails 可以做什麼的冰山一角。在後續的內容我會更深入地探討 co 語言以及 Guardrails 本身，比如 #變數、#action、Agents、RAG 等等。
待續！
