謝謝AI,真的很謝謝他才能讓我在短時間內學到很多預料之外的內容。
這是一個「完全」由ai開發的portal,甚至連接下來30天的內容也是ai產的。
主要業務是一個ai客服平台。從前端經由portal(大平台)再到後方的engine檢索km,來得到最精確回答的一系列過程。
雖然我覺得RAG檢索KM,很有趣,但portal更有趣!!
接下來的30天就讓我們從頭開始認識這個portal(我真的很想把頭貼換成王大陸)需要知道哪些技術細節吧。
昨天我們把容錯的不對稱講透了:身分服務掛掉時,提問那條路傾向 fail-open(放行、標成匿名),改設定那條路 fail-closed(一律拒絕),按操作的風...
昨天收尾時,我們補上了身分鏈的最後一段——Portal 自己去敲下游引擎的門時,怎麼用一張短命的 OIDC(OpenID Connect)token(權杖)證明...
昨天 Day 12 我們站在使用者的角度看了那個招牌甜頭:換一家 LLM 供應商,設定檔改一行字,業務 Java 程式碼一個字都不用動。但「0 行不動」這四個字...
昨天 Day 13 我們把「可抽換」拆到了底——標記、分類表、名冊三樣東西,外加一條結論:名冊握著所有零件,執行期報出名字就能挑一個。文末我留了個鉤子,說「逐請...
昨天 Day 14 我們把切換粒度縮到最小:「這一筆」請求帶個 header 臨時換家供應商,下一筆照舊。那是行員主線(/chat)上的事。今天換一個視角:Po...
昨天 Day 15 我們把 Portal 的管理面講完——控制面讓我們在執行期查詢、切換、停用供應商,KM 反向代理則讓後台能讀寫知識庫,第四章那套「換廠商 0...
昨天 Day 16 我們攔掉了第一種髒輸入——夾帶「ignore previous instructions」這類想覆寫系統指令的提示注入。注入是「惡意」的,被...
昨天 Day 17 我們把入境守門的第二件事講完了——八類 PII(個資)怎麼辨識,為什麼「員編 6 位數、Email 裡也夾數字」這件小事會逼出一套講究先後順...
昨天 Day 18 把縱深防禦那條防線整個畫出來時,最後一格我刻意留了個尾巴:模型生成回答之後,還有一道「出境 Guardrail」。前面三天(Day 16 到...
昨天 Day 19 我們把出境守門講完了——模型吐出來的文字一樣要過關,PII(個資)遮一遮就放行,不當內容整則攔下,判準是「風險能不能靠局部處理化解」。但 D...