來聊聊AI的外部知識與記憶機制吧。

但凡對目前生成式AI整合應用有一點API串接經驗的人應該都會知道，現在大模型的推理是無狀態的。

模型的知識與能力是透過訓練出來的，而不是生成推理的過程就會順便記得與學會新的知識。

使用生成式AI時，對話過程中的記憶，其實都是每次重複傳送之前對話歷程給模型重新理解一次來做生成的，聊得越久越長，相當於每一次都是比上一次更長的複雜任務在做推理生成，所以效果會越來越差。

想像人怎麼對一個簡短的情境做理解與作答，然後再想像那個需求的情境變得非常冗長，要讀完一本厚厚的書來做一次回答，那自然是不容易做好的。

需求越是冗長，裡面內容越多，就越有機會抓錯重點，並做出不符合提問者期待的解釋與推理。

不單AI是這樣，就算是個博士等級的人類腦袋，也無法違逆這種限制。

所以，目前的生成式語言模型，它的記憶與知識就是分倆種。

一種是透過大量訓練數據與透過算法做大量的運算來更新模型本身，實務上這樣做會被稱為對模型做微調。

不可能每一次互動就對系統微調一次，那太不現實，通常是有特定目的，也收集或編制了針對性的微調訓練數據後，才對模型微調，產生一個特殊版本的模型，來負責一個特殊情境的需求。

通常不會用這種方法來賦予AI記憶。

而另一種也是當前主要實現的手段，就是把記憶重複塞進每一次的請求裡。

而我們只要簡單的推理一下，這種記憶的方式，在大模型應用的時候，那個輸入的token使用量一定會很大的，畢竟聊天肯定是越聊越長的，那個記憶得累積，且每一次都要重複，所以輸入token基本上是很難省的。

想像一下，最早的時候，那時候的API收費是每千個輸入token多少美金，然後我們的問題文字，英文內容的話1000個token大約750個英文單字，中文則是一個中文字大約1個token吧，我們可能會有一種錯覺，1000個token可以進行很多次對話，只要1美金的話好像也不貴。

事實上，隨便一個AI整合應用，光每一次調用的輸入token，很少會低於1000的，要把情境包括提示詞在內放進請求內，每一次推理生成就是消耗很多token的，就算是ChatGPT自己，每次生成也是會額外多塞一些提示詞，且啟用記憶功能時更是每次生成都要把記憶設定重複再放進請求一次。

生成式AI的一生，狹義的來說，也可以定義為收到請求開始，完成最後一個token生成為止，就是其短暫的一生了。

然後每一次都會被按下重啟，然後再收到一次全新的請求。

好，那記憶機制怎麼實現，就是我們的程式要實現的。

現在的記憶主要是透過OpenAI的Chat Completion介面，訊息列表messages裡放置之前的聊天歷程，來實現對話的記憶。

所以我們只要提供變數累積保存每一次生成的請求與結果，就算是能保持對話的記憶了。

記憶會累積，一旦超過請求窗口大小限制，就無法進行生成，而此時的策略就是設法減少聊天歷程使用的token數，主要手法是忘記較舊的對話，或是對之前的對話歷程再調用能做摘要的大語言模型，用被整理過的對話歷程摘要取代完整的對話歷程，讓請求可以重新的不超過生成窗口限制的大小。

所以聊久了模型會忘東忘西的，或乾脆失神腦殘，很可能就是這個記憶機制沒處理好的關係。

壓縮過的摘要就是沒有之前的細節，模型根本沒有之前的對話歷程，你要怪它忘記它從來不知道的東西，那也是沒用的。而早期對話被移除的話，那更簡單，它可能就是從一個不是很連續與洽當的對話過程中開始的，失去最前面的歷程可能就少了前因後果，所以它答不好，那是很正常的，不需要意外。

也就是記憶本身是不存在的，是透過重複把我們認為的記憶塞進每次請求裡面，讓AI多根據這些記憶來作答，來實現記憶機制的。

說完了記憶機制，我們再來說AI的知識。

既然AI本身沒有記憶能力，那麼AI的新知識自然也是不存在的，只有被訓練出來的既有知識，每一個新知識或者新資訊，都需要進行微調訓練才能把內容刻進模型裡。

但這同樣不現實。

所以AI理論上只能使用它訓練時已經學過的知識來作答生成。

但我們常常會想使用最新的數據庫資料或最新的搜尋引擎查詢結果，來當做答的知識基礎吧?

生成式人工智能針對新的，原本沒訓練過的知識問答生成的的API調用怎麼搞?

就和對話記憶一樣，把外部知識往請求裡面塞就是了。

我們設法調用外部API或查內部數據庫，拿到需要的新知識或資訊，再夾進請求文本裡面，直接在對話歷程裡塞一句:

請使用以下資訊來回答使用者的問題，不要使用你原本的知識，如果提供的資訊不足以回答問題請回答資訊不足無法回答。參考資訊為:...(把參考資訊放這裡)

這和塞一句摘要壓縮過的對話歷程是相同的手法。

而這些資訊我們放進去是什麼就是什麼，如果塞錯了，AI只會根據它看到的請求，盡可能的做這個一生一次的內容生成。

之前曾弄個食譜問答的整合串接，查了兩個食譜，提示詞讓AI從這兩個裡面選一個出來當回答用戶問題的參考資料，碰過鬼打牆的，明明給它兩個食譜，第一個食譜就是問題要用的食譜，可是它要不就是死用第二個不合適的食譜，要不就是瞎掰。

實際上查發出的請求，才發現是程式沒寫好，兩個食譜只有把第二個食譜放進請求裡，第一個食譜漏放，所以提示詞怎麼改都沒用。

對的，外部知識，新資訊的生成作答也就是這樣搞的，我們把這些資訊往API的請求裡塞就是了。

所以一次生成的API呼叫請求裡，主要有四個成分，第一個是我們的提示詞，要求它怎麼進行後面的處理，再來是提供聊天歷程的上下文資訊，然後如果有需要外部資訊，我們也要自己設法弄到那些資訊，也往請求裡塞，最後才是用戶輸入的需求問題以及上傳的檔案內容等等。

這些內容要擠在模型的上下文窗口限制大小內，還要預留足夠的空間給輸出使用，輸入超過窗口就是整個無法執行，而輸出加上輸入達到窗口限制時輸出就會中斷，早期ChatGPT的使用體驗應該常常碰到這種情況，而聊天歷程與外部參考資訊，都是沒有上限，提供越完整越充足就能做更好的判斷，生成品質也會越好，但又不能爆，如何分配與控制每一塊使用多少token就是一件有點麻煩的事了。

得做取捨。

給的token空間少了，無法放進足夠的資訊，生成品質自然差。

盡量給夠了，要擔心會超過窗口限制大小，輸入有好幾塊，全部共用同一個限制，你大了我就得小，往往得根據需求特性分配每一部分各自的上限。

喔，如果希望生成品質能盡可能的高，那可以只留合理的輸出空間，剩下的份額就盡量使用，超過時可以設置每一部分的最低保障token，然後根據優先順序，給重要的部分先占用，最不重要的部分再做壓縮與捨棄對吧?

是這樣沒錯啦。

但可以想像，用這種邏輯的話，只要對話歷程夠長，可以肯定每一次請求必然都是塞滿請求能使用的窗口限制大小的吧?

以GPT-4的128k token的窗口，可以想像每一次問答生成就是滿窗口的輸入token，十次生成就穩妥妥一百萬個輸入token的消耗。

即使是現在已經降價很多次，1M的input token在高級的模型，費用也還是要個五美金左右的程度。

如果聊天歷程永遠都維持著不重設，你的使用者聊十句話就要噴五美金，你能撐得住嗎?

更不用說，這些API調用有的進階的設計，可以在一次生成就調用好幾次，包過如何取得參考資訊的流程也使用模型生成提供判斷等等，那個實際調用使用的token數只會比想像的更多的。

而那些允許1M token窗口上限的模型，能力固然是大大放寬限制了，但成本你可以想像，生成一句話吃掉1M輸入token，你的荷包君應該會瑟瑟發抖的。

或許大模型現在對岸在降價打骨折中，但一些需要AI提供靈活的綜合邏輯判斷的情境，便宜的低階模型不做大量微調是很難勝任的，而這些應用一定會牽涉到大量外部資訊被塞進請求裡，夠智能的AI應用目前都是靠大量算力與運算暴力產生出來的，成本效益是不宜太過樂觀的。

使用外部資訊而不是模型訓練資料來生成作答，目前有個還挺熱門的名詞，叫檢索增強式生成，簡稱RAG，取英文的存取強化生成塞個字字首做縮寫。

這一套也就是在上述的機制上，再增加一個向量數據庫，然後把大量的外部知識內容做切塊，切到AI輸入窗口能有效吸收的尺寸，為每一塊內容產生向量索引，之後的問答就拿用戶的問題抽關鍵字產生向量，與外部知識切塊的向量索引做語意相關性的計算排序，取出語意相關性最高的前幾個切塊，把那幾塊的內容塞進請求裡當外部參考資訊的一整套機制。

這套機制主打的就是語意相似度，這個可以跨語言找到最相似的內容，然後可以在窗口限制下自動提供海量外部知識的檢索生成。

簡單的理解就是上傳一些知識檔案，word或pdf那樣的，檔案可能有幾百MB，它都可以上傳，然後對話時可以指定使用上傳的外部知識做答，概念上封裝得很簡單好懂。

但我們知道它底層也就是在有限的生成窗口裡塞外部資訊進去的那樣的實現，所以這種實現可以想見的，簡單的演示可能還行，知識的資料複雜一點的話，那個生成的品質自然堪慮。

想也知道，切塊的知識文本本來就碎片化了，不是連續完整的知識單位，我們硬塞幾塊語意相關度最高的參考文字進去，本來就有很高的機率是塞不恰當的垃圾進去做生成的，答案的品質不太行也是不難想像的。

因為技術上的實現，我們好像可以上傳大量遠超窗口限制的文本進去做外部知識庫給AI做生成參考資訊來源，但這種策略是很簡單暴力的切塊與把最相關的幾個碎片組在一起讓AI作答，本來就是在賭運氣的。

更不用說，我們本來就沒有從頭到尾完整提供參考資訊文本，所以AI沒有仔細讀完整的外部知識文本，做出來的回答有幻覺，這本來就是幻覺啊!

同樣的輸入給一個聰明人來回答，除非知識文本是demo階段就只有幾個切塊且所有切塊都塞進請求裡，否則這個聰明人合理的反應輸出應該只有一個字，幹，才對吧?

RAG有本質上的問題，之前很熱門，但傻蛋就覺得不靠譜。

在OpenAI的開發者論壇看到有人想用GPT-4做語意解析來拆分塊，來克服RAG本質問題，討論很長很熱烈。

解決方案很複雜，傻蛋直覺也是不靠譜，就觀察看看有沒有什麼創意，是否會冒出新的解決方案，但一直沒看到好的作法。

前幾天在上網找工作，瀏覽職缺，看一個公司的產品是代理國外的圖形資料庫。

Graph Database。

這是啥東西?

傻蛋就熟關聯式資料庫，與對一些NoSQL有些大概的認識，但這個圖形數據庫，就很難掌握這是啥概念。

搜尋引擎找到一些教學，看到一些描述其概念的圖片與範例語法代碼，但還是不太能掌握其核心概念與為什麼要用它，要怎麼用它這個最基本的問題。

不過現在的免費Claude能力變很強大了，所以傻蛋就問AI這個圖形數據庫是個怎樣的概念。

喔，原來如此。

來回問AI比自己查Google有效率多了。

如果熟悉關聯式數據庫的話，圖形數據庫可以這樣理解:

有一個泛用的數據表，叫Node，圖形數據庫所有數據都是Node節點。

Node之外還有標籤，每個Node可以套標籤，可以套多個標籤。

另外Node本身可以放任意的屬性資料。

最重要也最核心的，是Node可以與其他Node建立任意的關聯。

這個Node用某個指定的關聯連結到多個其他Node。

於是可以順著這些關聯爬出關聯的Node出來。

找出來的節點可以再用其他關聯繼續爬出關聯的更多相關節點。

節點找出來後可以貼標籤，修改屬性，以及增加或移除一些關聯的連結。

可以想像成就是一個通用的設計，所有數據都有一個通用的底層叫Node，共用一個table，可以有任意自訂義屬性，可以套用任意的標籤，可以套用任意節點間的關聯。

實現就是先找到起點的一個或多個Node，再順著關係爬到更多關聯的Node來做使用或操作。

所以它也不是什麼神秘的東西，一開始的Node的查找如果沒索引，也有可能會需要爬大量節點而很低效，找到Node後連結其他Node可以視為有有效的索引可以快速的爬過去找到，而這樣的圖形數據庫最根本的核心就是所有Node都是Node，可以任意的和其它Node建立任意的新關聯，不需要像傳統關聯式數據庫一樣要預先建立數據表格式，在設計層面分析與建立數據與數據之間的關聯，而是可以在應用使用的層級上輕鬆建立新的關聯，而這樣的數據結構可以使用圖型連結的方式呈現，所以叫圖形數據庫。

這讓傻蛋想到RAG與其語意分塊的那個需求。

就用圖形數據庫當底層的知識儲存，使用高階AI分析與拆解匯入的知識文本，產生知識節點與節點之間的關聯與標籤，最後讓AI產生爬圖形數據庫的查詢指令，來取代原本的語意相似的簡單暴力查詢機制，不是挺合適的嗎?

知識問答需要完整的一塊資訊，而且是有關聯前後文的完整資訊，資訊的品質好生成回答的品質才有機會好，圖形數據庫，看起來挺合適這個情境的，之前的RAG看起來就像十足傻逼解決方案。

結果呢，哈，今天就看到一則新聞，微軟研究院發布了一個新的叫GraphRAG的工具，看起來就和傻蛋聯想到的這個差不多吧。

它應該還是有很多細節需要再優化與調整，以避免大量的反覆API調用次數，但概念上應該是比之前的RAG更可行的。

使用大模型開發AI知識庫服務的最好關注研究一下這個，不過也應該不是太嚴重的問題吧，就換一個技術底層實現而已。

對使用者來說，背後是用向量資料庫語意相似搜尋，還是用徒刑數據庫關聯的語意搜尋，只要能用，會用，結果是好的就好了。

這些都是現行對生成式AI應用的知識與記憶的增強手法。

根本原理很蠢，就是把資料都塞進請求的輸入裡那樣而已。

對AI的其他賦能也是類似的概念。

AI可不可以有長期記憶?

當然可以啊，就把長期記憶保存在你的數據庫，用各種關鍵字做分類索引，然後提供接口讓AI下查詢長期記憶的請求，查到後用類似外部知識的手段一樣塞進請求輸入的訊息內就是了。

微軟有個AI開發框架叫SK，Semantic Kernel，基本概念就是聊天歷程，長短期記憶，網路查詢，思考行動等等要賦予AI的能力都是function功能，都用同樣的結構來調用，畢竟最終背後的實現也實在是百分之八十七的像。

所以呢，都是多調用幾次大模型，讓大模型思考要怎麼調用，然後我們要實現具體的查詢或更新，最後把我們處理後的結果一起給大模型做最後的生成而已。

唯一可以預期的就是模型的調用次數與消耗的token或運算量會很大，沒有足夠商業價值的流程目前是不配使用生成式AI的整合服務的，暫時，成本效益暫時應該是負的吧。

而AI的安全性，坦白說如果還是這種底層API模式，一個一生就是一次生成的AI能有什麼安全性隱患?

至少要能做出連續的行動，得到反饋，累積結果，這樣的AI智能體才可能構成威脅吧。

而AI的自我建立，也無須大量數據進行訓練微調，透過外掛長期記憶，也能製造出虛擬的有人格的AI，它可以主動回想自己的長期記憶，更新自己的長期記憶，做出各種行動規劃，可以自我增強構成循環呀，繞過各種有害內容檢測難度是有點高但不是做不到吧。

不過想想現在的大模型API調用成本，練了半天只有資料庫的一些關於模型的記憶知識，這實在太划不來啦，無利可圖應該就不會發生了吧。