在這個模型中,我創建了一個具有外部插件功能的基本 AI 介面;介面 AI_Contracts 可實現與 AI 的介面;實作介面並將編譯後的 DLL 放入 APPPlugins 資料夾中,使 AI_Interface 能夠發現並呼叫插件,取得要傳回給使用者的回應;本專案分4個階段進行設計;每個階段或里程碑都使聊天機器人能夠發展和擴展,成為值得公開發布的豐富產品;
這裡給出了介面的基本設計,透過文字輸入和輸出;維護 CHAT 歷史記錄;此介面可以進行介面的基本測試;尚未添加頭像;這也是因為頭像不是必需的,而是裝飾性的;第一階段我們主要關注製作功能介面;
這是我們允許用戶設計可以由人工智慧執行的腳本的機制;在開始階段;提供機制是重點。初始使用的介面僅提供需要實現的類別的結構;主腳本將針對在指定位置找到的所有此類物件呼叫使用者函數。這實現了廣泛的可擴展性。這也是可以向用戶提供擴展和內部函數或 AI 框架以用作幫助程式腳本的一點。
在 AI 的第一個版本中,還將建立一個範例外掛程式來測試介面。 SAMPLE_PLUGIN 這也將為進一步的插件建立提供模板; ###注意:小BUG! AI_Contracts.Dll 需要與插件一起部署在 Plugins 資料夾中嗎?插件分離的相對引用。當插件與應用程式位於同一資料夾中時,應用程式會嘗試繼續讀取自身並崩潰,因此需要單獨的資料夾; MAN EXE 還需要存取 AI_Contacts DLL SO...
雙部署!
在此階段,我們透過提供問答資料庫來建立內部記憶功能。在這裡可以創建簡單的問答式回應,為應用程式的使用者提供一個起點。儘管存在將每個回合保存到資料庫的實作。在本次迭代中,選擇更加重視監督方法。需要提供資料庫編輯器。但這將在稍後階段提供;執行順序將是首先是插件,然後是問題和答案,以便確定回應發現的優先順序。當人工智慧沒有回應時,還需要後備響應來處理;
狀態機可以提供維持情緒狀態的機制;在本次迭代中,使用了一個介面來為情緒狀態物件提供結構;每個狀態都會載入到Handler中;腳本的每一輪都會偵測到情緒,正面和負面地調整當下持有的情緒,從而使情緒更加具體化。這裡當情緒狀態改變時給予通用回應。其他形式的狀態也可以透過使用狀態機來輪流進行;先前的程式方法通常利用“旅行變數”,但經常用有限商值替換狀態到狀態以解決情緒偏差。 IE 快樂 = 0.78 , SAD 0.23 ;這種技術不允許有強烈的情緒;情緒強度增加,即:如果下一回合偵測到快樂,則快樂增加;但如果下一個情緒只是中性的話,則會減少。直到強度等級降低到值 0,可以將狀態變更為中性。
聊天機器人介面可以提供對插件進行編碼和編譯的能力;這裡我提供了一個用於創建插件的選項卡式介面,我們在第一階段實現的模板用於提供一個入門範例腳本供用戶編輯和擴展。提供保存腳本和編譯腳本;
也為每個表格建立了一個用於編輯問題和答案文件的資料編輯器。
在這裡,我們將重構程式碼安排並將功能擴展到 UserScripting 框架。重構過程和註釋可以方便以後編輯和完善應用程式;以及向用戶提供理解;
儘管語音辨識隨著時間的推移而不斷改進,但也需要語音來提供豐富的使用者介面;它主要是為了語音輸出而添加的。
一些圖形改進和主題將添加到應用程式中:(也許是 LCARS _ 星際迷航設計!)
對於 AI_Contracts 元件的部署和集中存取:也決定將函式庫與 NUGET 集中為 SpydazWb.AI.Contracts ;這使得進一步的更新能夠集中用於插件建立和最佳交付:此時 AI_Contracts 原始碼也已從專案中刪除,並添加為 NUGET 參考組件; AI_Contracts 專案現在可以與 UI 和外掛程式分開開發;插件也可以作為 Nuget 套件部署在與 Nuget 分開的集中來源上;即集中式網站!