---
title: "AI Guardrails：以 Python 構建企業級 LLM 安全防護策略 - Nero Un 阮智軒"
tags: PyConTW2025, 2025-organize, 2025-共筆
---

# AI Guardrails：以 Python 構建企業級 LLM 安全防護策略 - Nero Un 阮智軒

{%hackmd L_RLmFdeSD--CldirtUhCw %}

<iframe src=https://app.sli.do/event/2UttcVRPeaqUus1crDpSBR height=450 width=100%></iframe>

:::success
本演講提供 AI 翻譯字幕及摘要，請點選這裡前往 >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=60vgrn5n97vZyeCw7gHT)
AI translation subtitles and summaries are available for this talk. Click here to access >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=60vgrn5n97vZyeCw7gHT)
:::

> Collaborative writing start from below
> 從這裡開始共筆

## 簡報
<iframe src="https://www.slideshare.net/slideshow/embed_code/key/Ho9OO7YQ0fjo4Q?hostedIn=slideshare&page=upload" width="476" height="400" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>

## Hallucination

- 事實性 true/false
- 忠實性 是否符合上下文

## 實作簡介 - Halluciation detector

dataset: [HaluEval](https://github.com/RUCAIBox/HaluEval)

- LiteLLM 統一調用不同LLM

### 設計

input -> LLM as a Judge -> Result parsing -> validator
-> Response

- Result Parsing
- 因為LLM的output不能信任 所以在寫一個檢查json格式
- Validator 判斷是否通過

### 使用pytest撰寫側案來驗證

### 使用fastapi建立api服務

1. 高效能
2. api as a document
3. 整合Python Typing

問就是用

主要設計兩支api
- 單筆：用於一般計算
- 多筆：用於批次/離線計算

## 導入前後的成本

以openai gpt4.1 nano


## 企業導入guardrails的實務考量 Benchmarking

1. 商源模型普遍較佳 但不等於最佳
2. 但不是越貴越好 例如 gpt-4.1-nano > gpt-4o 成本相差25倍
3. 使用時注意機敏資料外洩風險

OSS LLM:
1. 千問2.5 7b準確度居然比gemini2.0-flash高
1. opensource LPU LLM 在速度有極大優勢 不同參數大小都保持領先
- 適用於即時性任務

## 企業如何整合到服務或產品上

應用層
針對PII redaction
中介層
Middleware guardrails: RAG Guardrails

## 自我評估 AI guardrails 成熟度評估

- 模組化
- 自動化

## 技術趨勢 - guardrails 成為 ai service 標準配備

## shout out

前一場演講的Kevin去年也講了相關主題
{%preview https://tw.pycon.org/2024/zh-hant/conference/talk/324/ %}

---
## Q & A
> 講者留言：大家有問題可以留在 QA 裡～到 9/14 前都會回覆 (By Nero)
- Q: 想請問講者 guardrails 其中一種解法是不是就是讓另一個 LLM 檢查 LLM 的輸出？那和 prompt engineering 比較起來優勢會是什麼？因為本質上還是使用 prompt 去限制 output (嗎？
- Ans：
- Prompt Engineering 比較像是調參；而Guardrails 是一個模組的統稱、裡面除了可以用 LLM 改還可以撰寫自訂的 Function (Keywrod Serarch、Pydntic Model Compare, etc.) 來做到 Guardrails 的功能。
- 所以 Guardrails 是模組的定位、和 prompt engineering 最大差別是是可以用工程的方法管理、Scaling 和測試。
- 另外還有成本問題，在 Prompt 中加入複雜的規則來限制意味 Token 數量也增加了，而且有論文顯示複雜的 instruction / 多任務的情況下效果會不佳。
- 但必須要說 Prompt Engineering 和 Guardrails 定位不衝突；模型——但是參數少、對於任務的遵循能力不強的，Prompt Engineernig 做得再複雜也不會比 GPT 4o 的來得好；但後者的成本在演講的實驗裡的成本是差了 25 倍。
- 結論是還是把 Prompt Engineering 和 Guardrails 解耦來開發和管理。

### Slido 問題回覆區
1. 前面三星跟北捷的案例，如果企業想在一開始就避免這類濫用風險，會建議企業該以「流程設計」還是「技術護欄」優先？
- 還是和人力及成本有關；如果人力並沒辦法 Cover Guardrails 的開發和維護的成本、那麼只能而流程設計來執行；舉例如銀行早期的 Chatbot、基本上有一個 E2E 的流程和相對應的模版，所以它也不會像 LLM Based 的 Chatbot 用 LLM 來減少 E2E 流程的維運。

3. AWS Bedrock Guardrails 的「自動推理檢查」目前不支援 Streaming API 跟你說的不太一樣，只能用 Guardrails.ai 才可以嗎？
- 我看目前 Bedrock Guardrails 有支援（？）
- [Document](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-streaming.html)

5. benchmarking 的環節上分享了不同模型在延遲與成本上的比較，想問企業通常會把哪一個（成本 vs. 延遲 vs. 安全）放在第一順位？
- 和產業有關 @@
- 金融業和醫療一定是 安全 > 成本 > 延遲
- 遊戲、直接面對客戶的服務，那一定是 延遲 > 成本 > 安全
- 所以看產業對於法規與服務 SLA 的需求

7. 在平台層、中介層、應用層三個層次導入 Guardrails，對企業來說哪個最容易獲得短期成效？
- 先在平台層導入：Keyword、Similary Compare、Data Model Validation 成本比較低但可靠的
- 隨後從不同服務去完成 PoC、後續再透過需求收集和整理來開發可通用、複用的 Guardrails 模組。

9. 在測試資料集中是否有分正向、反向的題目？是否在測試前有先進行 label ，才去計算準確率？
- 這次使用的[HaluEval](https://github.com/RUCAIBox/HaluEval)是有人工 Label Answer 和 Hallucination Answer、可以從資料欄位判斷
- 但一般而已可以用 LLM 快速協助 Labeling、再由人工確認來減少 Labeling 的成本

---
Below is the part that speaker updated the talk/tutorial after speech
講者於演講後有更新或勘誤投影片的部份