代理AI 在現實世界中所面臨的限制
（影片從 16:14 開始）AI 僅透過資料計算來呈現結果，卻未能根據現實世界中的任何關鍵情境進行相應的調整。一旦發生錯誤，它只會簡單地進行重試。在未來，AI 將不再僅限於處理數據，而是需要取代人類，真正作為「操作員」去執行實際工作。舉例來說：假設我們設定了兩個 AI 代理來執行購買蘋果股票的任務。代理 A 接收到指令，準備從銀行帳戶扣除 1000 美元；然而就在此時，電腦突然發生故障，訊號中斷（即係統崩潰）。由於代理 B 未能接收指令，因此未能成功買入股票。當系統恢復正常後，人們卻發現資金被扣除，但股票卻未買進──這究竟是怎麼回事？而在現實世界中，實際情況往往是這樣的：
資料庫處理原則：資金流出與蘋果股票的買進操作必須同步記錄。一旦發生任何錯誤，整個流程將被回滾，恢復至彷彿從未發生過的狀態。就本例而言，這意味著資金必須退回至銀行帳戶。
LangChain 是一個開源的編排框架，旨在簡化基於大型語言模型（large language models-LLMs）的應用開發。它提供了一套標準化的接口，用於將 LLMs 與外部資料來源、工具以及複雜的業務流程相連接。*
當大型語言模式（LLM）的API在現實世界中處理商業交易時，它們無法保證商業營運的絕對安全性。然而，DBOS卻能夠實現這一點。最理想的商業AI，應具備傳統強大資料庫系統所擁有的特性。試問：ChatGPT或Claude這類模型，真的能夠取代人類去處理複雜的商業資料任務嗎？在使用AI執行此類工作時，往往容易在「文字轉SQL」的過程中發生嚴重錯誤——例如，當人類用戶發出指令：「請列出上個月銷售額最高的10位銷售人員的姓名」時，AI可能會在此環節出現偏差。
大型語言模型（LLM）AI 的四大致命弱點（影片從 22:21 開始）
1. AI 並非無所不知：AI
僅利用了網路上所有「公開」可用的資料。它透過攝取這些海量資料（即「資料堆」）來產生結果。然而在現實中，沒有任何一家公司會將其核心資料庫結構公諸於世。正因為
AI
無法窺探這些私密且獨特的業務資料庫結構，它便無法僅憑猜測來編寫正確的程式碼，從而也就無法得出準確的結果。
2.
程式編寫的複雜性：以「Spider」SQL
中針對學生測驗成績的題目為例，其難度無異於小學生的數學題。這類
SQL 程式碼的產生結果通常只有
10 到
20 行。但在現實世界的商業資料庫中，公司內部的任何一條
SQL 語句通常都需要編寫至少
100
行程式碼才能完成。。
3.現實世界中業務架構（Schema）或業務描述的複雜性：學生測試所用的資料表結構非常簡單，例如表名可能僅為“薪資”或“員工”——命名直觀且簡潔。但在真實的商業環境中，資料表的結構往往極為複雜，其表名、欄位名稱或描述資訊往往晦澀難懂、缺乏人性化。舉例來說，你可能會看到諸如「Zippers拉鍊,
2023TMP」這樣的描述；人類銷售人員憑藉其工作經驗，能夠立刻領會其含義。然而，AI
在看到這些資訊時，極有可能會感到困惑，完全摸不著頭腦。
4. 極具迷惑性的“行話：例如，在麻省理工學院（MIT）的數據庫中，有一個術語叫做“J-term”，特指一月份開設的短期學期課程。這類私密且封閉的內部術語通常不會收錄在大型語言模型的字典中。因此，如果無法在相關文件的上下文段落中找到深入且關聯緊密的業務描述作為佐證，AI 將根本無法理解這些術語的真實含義。
既然人工智慧（AI）無法處理涉及極端跨系統資料庫的SQL查詢，那麼解決方案究竟是什麼？
對於AI而言，這類問題極具挑戰性，因為其所需的基礎數據分散在五個截然不同的「數據宇宙」之中。
具體而言：列車時刻表屬於一類特定的資料庫；紅綠燈的號誌控制序列則歸屬於另一類資料庫；道路交叉口及路段長度等資訊是以CAD影像檔案的形式儲存於資料庫中；德國聯邦交通法規屬於純文字檔案；而慕尼黑市的地方性法規又是另一種類型的文字檔案。
如果AI在處理這些資料的SQL時，採用的是一種鬆散、黑盒化且拼湊式的流程，那麼整個系統將變得極其脆弱且難以掌控。一旦出現錯誤，想要追溯並找出問題的根源將變得異常困難。
人類解決問題的方式往往沿襲著一種古老而紮實的工程思維模式——即直接將一切事物轉化為若干標準化的數據陳述或表格。一旦所有資訊都轉換為資料表，便可利用頂尖的 SQL 查詢最佳化器來執行關聯查詢（Join SQL）。
因此，對於年輕人而言，最佳的職業建議莫過於投身於醫療保健領域或從事技術精湛的建築施工工作……因為這些工作能夠讓人直接觸及真實、具體的物理世界。
沒有留言:
張貼留言