iT邦幫忙

ai engineering相關文章
共有 54 則文章

技術 [Day 30]:完賽回顧——從風險要求走到可驗證的 AI Guardrails

寫到第三十天,這個系列也要告一段落了;雖然因為某些緣故導致比賽中斷了,但還是想要把整個系列寫清楚,也讓自己這些年累積的經驗沉澱下來。 前面從企業為什麼需要 AI...

鐵人賽 AI Engineering DAY 8

技術 [Day 29]:Enterprise Guardrails 應該放在哪裡?比較 App、Sidecar、Central Service、Gateway+BYOG 與 Provider-native

筆者在過去文章中提到的眾多 Guardrails案例、看起來只是多加一項檢查,實際在開發和部署時時卻得先問: 規則放在哪裡? 如果寫在各個應用程式裡,哪...

鐵人賽 AI Engineering DAY 8

技術 [Day 28]:實務上 Guardrails 不會只有一個:多層防護到底應該怎麼組合?

Day 27 談的是如何選擇 Guardrails 元件。選好之後,企業還要面對另一個問題:當業務規則改變,這些元件能不能跟著調整,並且知道調整後的防護是否仍然...

鐵人賽 AI Engineering DAY 8

技術 [Day 27]:Regex、NER、Classifier、Guardian LLM、LLM Judge 到底怎麼選?

選 Guardrails 元件,可以先從「這次需要拿回什麼結果」開始。 假設採購助手正在整理一份供應商比較報告。候選內容夾著不需要交付的姓名與私人電話,也多了一...

鐵人賽 AI Engineering DAY 8

技術 [Day 26]:等模型輸出 / 執行完再審查就太晚了嗎?來看看 Streaming Guardrails 的使用情境和能做到甚麼

等模型講完才審查,不一定太晚。回覆如果還留在伺服器端,檢查通過後才交付,就仍然來得及阻擋;反過來,即使護欄在生成途中持續檢查,只要文字先送到了使用者端,後面的阻...

鐵人賽 AI Engineering DAY 8

技術 [Day 23]:RAG 找回來的文件也可能攻擊你:Prompt Injection 該在哪裡攔?

產品文件可以提供保固條件;客服是否能收集資料、把資料送到哪裡,則由服務本身的政策與權限決定。RAG 把文件放進模型的上下文時,這兩種不同的權力,很容易在同一段文...

鐵人賽 AI Engineering DAY 8

技術 [Day 22]:Guardrails 可以防止幻覺嗎?從企業 RAG 的 Groundedness 談起

Guardrails 可以在回覆交付前,攔下部分缺乏來源支持的內容。但要說它「防止幻覺」,還得先問:這次檢查依據哪份資料,檢查了回答裡哪些主張? 前一篇談的是客...

鐵人賽 AI Engineering DAY 8

技術 [Day 19]:一份萬字文件裡只有一句個資:長文本 PII Guardrails 怎麼做?

新的章節:到底企業需要哪幾大類的 AI Guardrails? 在實際的企業場景裡,我們常常會遇到到底要使用哪些 AI 護欄的問題;大部分人想到的可能都是如何使...

鐵人賽 AI Engineering DAY 8

技術 [Day 17]:客服案例實戰:從 Rule、Reward、Judge 到 Human Review 的完整評估流程

一段客服逐字稿要交給摘要模型,但模型不能取得原始個資。姓名、電話和地址得遮住,顧客要查詢配送進度這件事又必須留下。做完去識別化後,怎麼確認這份資料能用? 今天沿...

鐵人賽 AI Engineering DAY 8

技術 [Day 16]:Human-in-the-Loop 不等於所有資料都給專家看

Day 14 裡,筆者遇過候選已經提供正式求助窗口,Judge 卻說它沒有提供的情況。Day 15 則談到另一個限制:Reward Model 能替同一組候選排...

鐵人賽 AI Engineering DAY 8

技術 [Day 15]:Reward Model 比 LLM 便宜,那能直接用它換掉 LLM As A Judge 嗎?

前兩篇已經花了不少篇幅談 LLM-as-a-Judge:Day 13 說明它適合判斷哪些問題,Day 14 則處理 Judge 自己也可能誤判的情況。到了 Da...

鐵人賽 AI Engineering DAY 8

技術 [Day 14]:Judge 也會亂判:筆者踩過的 LLM-as-a-Judge 大大小小坑

上一篇 Day 13 談 LLM-as-a-Judge (下稱 Judge)適合處理什麼時,筆者把它的位置放得很清楚:由規則式(Rule)Guardrails...

鐵人賽 AI Engineering DAY 8

技術 [Day 13]:LLM-as-a-Judge 到底適合判什麼?

在 Day 12 文章裡談規則式(Rule)Guardrails 時有個界線很明顯:有些事情只要條件寫得夠清楚,根本不需要 LLM As A Judge 來協助...

鐵人賽 AI Engineering DAY 8

技術 [Day 12]:能用規則 (Rule) 判斷的事情,就不要先叫 LLM

在 Day 10 的文章裡,筆者把合成資料的品質檢查拆成三層:先看資料結構,再用確定性規則核對已知條件,最後才把難以直接寫成規則的問題交給語意判斷。 讀者可能會...

鐵人賽 AI Engineering DAY 8

技術 [Day 11]:實戰-組合 Day 7-Day 10 的心法、以 PII Guardrails 為目標合成測試資料

Day 7 到 Day 10 分別談了 Seed、Stage、Dependency 與 Quality Control。四個部分各自拆清楚後,要把它們接成一條...

鐵人賽 AI Engineering DAY 8

技術 [Day 10]:資料生得出來不代表能驗收:替合成管線設計 Quality Control 機制

Day 9 把 redacted_text 和 entity_candidates 接回同一版 source_text。這能避免三份資料各說各話,卻還不能回答一...

鐵人賽 AI Engineering DAY 30

技術 Day 30|從 Vibe Coding 到 Agent-ready 的開發方法

耗時4個月,權限管理平台正式上線,超過 100 位使用者開始使用。 在這過程中,驗證 13 項功能的結果輸出,再用兩輪 UAT、合計 13 個情境檢查跨角色流程...

鐵人賽 AI Engineering DAY 8

技術 [Day 8]:不要叫模型一次生成:合成 PII 測試資料時拆成可追蹤的階段任務(Stage)

昨天 Day 7 的文章先把一筆 Guardrails 測試案例寫成種子資料(Seed Contract),分清楚哪些條件要固定、哪些內容可以變化,以及哪些資訊...

鐵人賽 AI Engineering DAY 7

技術 [Day 7]:先別寫 Prompt:先設計出資料種子(Data Seeding)來定義案例、邊界與資料分布

上一篇先把 Guardrails 的六個驗收情境改寫成合成資料需求,並且分清楚三類條件:哪些一定要固定、哪些可以變化、哪些不能交給模型自行發明。 接下來很容易直...

鐵人賽 AI Engineering DAY 6

技術 [Day 6]:客戶資料不能拿出來,我們要怎麼測 AI Guardrails?

在 Day 5 的文章中我們把「不要洩漏個資」拆成六個可以重跑的驗收情境,而文章最後留了一個很實際的問題:在測試 Guardrails 時三個案例可以手搓一搓生...

鐵人賽 AI Engineering DAY 5

技術 [Day 5]:Guardrail 有擋到就算驗收?把企業政策 (Policy) 變成可以一直重跑的測試、實踐 Policy As Code

筆者在 Day 4的文章裡談到,企業為什麼不能只要求 Guardrail「接得上」或「能跑得動就好」。 當企業今天用了 A Guardrail,半年後可能換成...

鐵人賽 AI Engineering DAY 25

技術 Day 25|超過 100 份 Spec 怎麼整理:建立 Agent 讀得懂的文件地圖

持續三個月的努力,DAP 在7/31正式開放上線了。 系統上線後,需求還是持續進來。回頭整理這三個月的開發紀錄,specs/ 已經累積 107 個編號資料夾,我...

鐵人賽 AI Engineering DAY 4

技術 [Day 4]:手搓 Guardrail 不難,企業真正難題怎麼把它管起來

筆者在 Day 3 的文章中把「不要洩漏個資」這句要求,拆成三件事: 系統要檢查什麼 照什麼規則判斷 發現問題後要怎麼處理 如果今天只有一個客服系統、一個模...

鐵人賽 AI Engineering DAY 24

技術 Day 24|兩輪 UAT 怎麼收口:快速修正,也要決定哪些先不上線

兩輪 UAT 合計準備 13 個功能情境。第一輪檢查跨角色流程,第二輪讓申請人操作。 這一階段的開發工作都交給指揮中心管理。它負責分流、檢查檔案衝突與安排 A...

鐵人賽 AI Engineering DAY 2

技術 【Day 2】名詞定義(上):六個基礎名詞

Agent、Harness、Tool、MCP 這幾個詞在不同框架的文件裡指涉的範圍各有出入,同一個詞在甲專案是協定規範,在乙專案是產品名稱。以下先把六個基礎名詞...

鐵人賽 AI Engineering DAY 3

技術 [ Day3]:「不要洩漏個資」太模糊:怎麼把政策轉譯成 Guardrails 可以測試的控制項?

Day 2 把 Guardrails 可以介入的位置展開了:從使用者輸入、檢索資料,到工具執行前後,都可能需要控制。但架構圖、流程圖畫完,工程師還有一個問題沒得...

鐵人賽 AI Engineering DAY 1

技術 【Day 1】前言:從「能動」到「能一直動」

去年我做的是處理會議紀錄的 Agent,今年做的是常駐 Agent,這兩件事的難點落在不同的地方。 會議 Agent 的問題是一次性的:語音轉文字、摘要、寄信,...

鐵人賽 AI Engineering DAY 23

技術 Day 23|規劃五個工作天:用優先矩陣安排第一波 UAT 修正

第一輪 UAT 結束後,規則確認、修正、重驗和第二輪測試資料準備,全部要放進這五個工作天。 Day 22 收到的回饋有大有小:單據無法結案會直接卡住流程,專案沒...

鐵人賽 AI Engineering DAY 22

技術 Day 22|第一次 UAT:用跨角色走查找出流程斷點

第一輪 UAT 開始,什麼請況都會出現,使用者如何操作真的是很難預期。 第一批人開始操作後,有一張單據從申請、審核一路走到最後,按下結案時卻出現伺服器錯誤。 原...

鐵人賽 AI Engineering DAY 1

技術 [ Day 1]:AI Guardrails 不應只是 AI Security、更是企業實踐 GRC 的手段之一

談到 AI Guardrails,常見的反應是:「這是 AI Security 的事吧?」也有人會問:「把限制寫進 Prompt 不就好了?」或是:「模型都這麼...