1. Hai lớp kiểm tra
Mọi quy tắc guardrail và mọi đánh giá firewall đều thuộc một trong hai lớp.Kiểm tra built-in / tất định
Keyword denylist (keyword), regular expression (regex), phát hiện
PII (pii), và max-length (max_chars) quy tắc guardrail là thuần
túy chuỗi local và regex — không có lời gọi mô hình, không có network
hop, không có gì có thể timeout. Đánh giá quy tắc firewall (glob tên
tool, argument predicate, phạm vi egress) cũng tương tự: tất định và
local.
Trên thực tế, các kiểm tra này thêm độ trễ không đáng kể vào
request của bạn. Chúng an toàn để chạy trên hot path và là thành phần
của các template guardrail built-in.
Kiểm tra nâng cao / ngữ nghĩa
llm_judge, grounding, và các quy tắc vendor external ủy thác kiểm
tra cho một mô hình hoặc vendor. Chúng có tốn một round-trip. Ba thuộc
tính giới hạn chi phí đó:
- Dispatch đồng thời. Nếu chính sách của bạn có nhiều quy tắc nâng cao, chúng được dispatch song song — một kiểm tra chậm không bao giờ phải xếp hàng nối tiếp sau một kiểm tra khác.
- Timeout theo từng quy tắc. Mỗi quy tắc nâng cao có một timeout
(
judge_timeout_ms/grounding_timeout_ms/timeout_ms). Kiểm tra grounding mặc định là ~3 000 ms; judge dùng một giá trị có thể cấu hình (0 → mặc định engine). Quy tắc có giới hạn — nó không thể treo vô thời hạn. - Fail-open theo mặc định. Khi một quy tắc timeout hoặc vendor trả
về lỗi, sự kiện được ghi lại nhưng request tiếp tục. Đặt
judge_fail_open: false(judge) hoặcfail_open: false(external) để đổi sang fail-closed.
2. Nhìn tổng quan
| Loại kiểm tra | Thêm độ trễ? | Cách giới hạn |
|---|---|---|
keyword denylist | Không đáng kể — scan chuỗi local | Không mạng; không cần timeout |
regex | Không đáng kể — RE2 match local | Không mạng; không cần timeout |
Phát hiện pii | Không đáng kể — scan regex/entity local | Không mạng; không cần timeout |
max_chars | Không đáng kể — đếm ký tự | Không mạng; không cần timeout |
| Đánh giá quy tắc firewall | Không đáng kể — glob + predicate matching | Không mạng; không cần timeout |
llm_judge | Một lời gọi mô hình có giới hạn | judge_timeout_ms; fail-open mặc định |
grounding | Một lời gọi mô hình có giới hạn | grounding_timeout_ms (mặc định ~3 000 ms); fail-open mặc định |
Vendor external | Một lời gọi vendor có giới hạn | timeout_ms; fail_open mặc định |
| Nhiều quy tắc nâng cao | Một round-trip có giới hạn (dispatch đồng thời) | Trường hợp xấu nhất = max timeout đơn, không phải tổng |
3. Kiểm tra chạy ở đâu trong vòng đời request
Thực thi không phải tất cả xảy ra cùng một thời điểm. Sàng lọc input và output thêm thời gian ở các điểm khác nhau:llm_judge kiểm tra prompt injection) thêm một
lời gọi mô hình có giới hạn trước khi lời gọi mô hình chính bắt
đầu.
Output guardrail chạy sau khi mô hình phản hồi. Một quy tắc output
built-in thêm overhead không đáng kể vào đuôi. Một quy tắc output nâng
cao (vd: grounding kiểm tra độ trung thực RAG) thêm một lời gọi có
giới hạn sau khi bạn đã có câu trả lời của mô hình.
Firewall đánh giá quy tắc là tất định và xảy ra inline trên
tool-call routing — không đáng kể, như đã lưu ý ở trên.
Một request bị chặn không tốn model token và không thêm độ trễ
thượng nguồn cho các block giai đoạn input. Một input block kích hoạt
trước khi đo lường và trước lời gọi thượng nguồn, nên bạn không phải
trả cả quota lẫn thời gian round-trip thượng nguồn. Một output-stage
block hoàn trả quota đã tiêu trước sau khi phản hồi bị từ chối.
4. Cách timeout và fail-open giới hạn trường hợp xấu nhất
Các quy tắc nâng cao có hai điều chỉnh: Timeout — thời gian tường tối đa mà kiểm tra được phép. Request chờ nhiều nhất là khoảng này cho quy tắc đó. Dispatch đồng thời có nghĩa là giới hạn này áp dụng theo từng quy tắc, không theo từng chính sách. Nếu bạn có ba quy tắcllm_judge mỗi cái với timeout 2 000 ms, tất cả ba
chạy cùng lúc và tổng chờ là ~2 000 ms, không phải ~6 000 ms.
Fail-open vs fail-closed — phải làm gì khi quy tắc không hoàn thành
đúng giờ (hoặc vendor lỗi):
| Cài đặt | Hành vi khi timeout / lỗi |
|---|---|
fail_open: true (mặc định) | Ghi lại sự kiện; để request tiếp tục như thể kiểm tra đã pass |
fail_open: false | Coi timeout / lỗi là một block; trả về HTTP 400 guardrail_blocked |
5. Hướng dẫn thực tế
Giữ các quy tắc hot-path là built-in. Nếu mối quan tâm chính của bạn là PII, rò rỉ credential, độ dài prompt, hoặc keyword denylist — tất cả những điều đó đều là quy tắc built-in. Chúng không thêm độ trễ đáng kể và nên là lựa chọn mặc định của bạn cho mọi kiểm tra mà text matching có thể xử lý. Dùngllm_judge và grounding khi bạn cần ngữ nghĩa. Độc hại,
quấy rối, phát hiện lạc đề, ý đồ prompt injection, và độ trung thực RAG
là thực sự mờ — không có regex nào nắm bắt chúng đáng tin cậy. Đây là
các trường hợp đúng cho quy tắc nâng cao. Chấp nhận rằng mỗi cái thêm
một lời gọi mô hình thêm có giới hạn.
Điều chỉnh timeout theo ngân sách độ trễ của bạn. Nếu mục tiêu
end-to-end của bạn là 1 000 ms, đặt judge_timeout_ms: 800 (hoặc ít
hơn) để judge không thể tiêu hết toàn bộ ngân sách của bạn. Timeout
mặc định của engine là điểm bắt đầu an toàn; giảm nó nếu bạn có yêu
cầu chặt chẽ.
Đối với output grounding, lời gọi mô hình đã xong. Kiểm tra
grounding chạy sau khi mô hình thượng nguồn phản hồi — độ trễ thêm
chỉ ở đuôi, không nằm trên critical path cho time-to-first-token. Điều
này làm cho nó là nơi có rủi ro thấp để thêm thực thi ngữ nghĩa.
Nhiều quy tắc nâng cao? Phân tán công việc. Vì các quy tắc nâng cao
chạy đồng thời, xếp chồng ba quy tắc llm_judge tốn gần bằng một —
timeout đơn lẻ dài nhất quyết định thời gian tường, không phải số
lượng. Dùng điều này để xếp chồng các kiểm tra ngữ nghĩa mà không có
chi phí cộng dồn.
Enforcement modes
Fail-open vs fail-closed — tham chiếu đầy đủ để điều chỉnh hành vi
của chính sách dưới điều kiện timeout và lỗi.
Guardrails
Loại quy tắc, trường judge, ngưỡng grounding, và tham chiếu cấu hình
guardrail đầy đủ.