Chuyển đến nội dung chính
Mỗi quy tắc guardrail trả lời ba câu hỏi — tìm cái gì (một loại), tìm ở đâu (một giai đoạn), và làm gì với nó (một hành động). Trang này nói về lựa chọn thứ ba đó. Hành động của một quy tắc là trường có hệ quả lớn nhất trên nó: nó quyết định một match sẽ dừng request, âm thầm viết lại nó, hay chỉ để lại một dấu vết. Trình tạo quy tắc hiển thị năm hành động tất cả — block, mask, flag, annotate, và spotlight. Trang này bao quát ba lựa chọn thực thi mà bạn dùng tới đầu tiên: block, mask, và flag. Chọn một cho mỗi quy tắc (hoặc, với một quy tắc PII, định tuyến các entity khác nhau tới các hành động khác nhau; xem §5). Hai cái còn lại là các hành động định hình prompt, không chặn: annotate chèn một ghi chú bảo mật lên thượng nguồn (xem bảo mật code), và spotlight bọc input không đáng tin cậy đã match trong các dấu phân cách để mô hình xử lý nó như dữ liệu, không phải hướng dẫn. Danh sách đầy đủ nằm trong Tổng quan Guardrails. Về engine rộng hơn — loại quy tắc, giai đoạn, gắn một chính sách vào một key — bắt đầu tại Tổng quan Guardrails hoặc tài liệu tham khảo Guardrails đầy đủ.

1. Quyết định guardrail block mask flag trong một dòng

block

Từ chối cuộc gọi với HTTP 400 guardrail_blocked. Mô hình không bao giờ chạy (giai đoạn input) hoặc câu trả lời của nó không bao giờ trả về (giai đoạn output).

mask

Redact mỗi match — ví dụ jane@acme.com[EMAIL] — và cho văn bản đã làm sạch đi qua. Request tiếp tục.

flag

Không thay đổi về traffic. Ghi lại một match trong feed và đi tiếp. Chỉ quan sát.
Đây là ba hành động thực thi. Bất cứ cái nào bạn đặt đều được tôn trọng ở mọi nơi quy tắc chạy — trình tạo quy tắc trong console, sandbox Test, và đường relay /v1/* trực tiếp đều đọc cùng giá trị block / mask / flag.

2. Một ví dụ cụ thể — ba quy tắc, ba hành động

Đây là một guardrail duy nhất mà ba quy tắc của nó mỗi cái chọn một hành động khác nhau. Bạn soạn cái này trong console (/console/guardrails) trên phiên của mình — relay key sk-orca-... chỉ dùng cho các cuộc gọi /v1/*, không bao giờ để chỉnh sửa chính sách. Tạo hoặc chỉnh sửa một guardrail yêu cầu vai trò Developer+.
{
  "rules": [
    { "type": "keyword", "stage": "input",  "action": "block",
      "keywords": ["internal-only", "do-not-share"] },
    { "type": "pii",     "stage": "input",  "action": "mask",
      "entities": ["email", "phone"] },
    { "type": "regex",   "stage": "output", "action": "flag",
      "pattern": "(?i)acme\\s+confidential" }
  ]
}
Mỗi quy tắc làm gì trên một request:
  • Quy tắc block từ chối bất kỳ prompt nào chứa một trong các thuật ngữ literal đó — HTTP 400, mô hình không bao giờ chạy.
  • Quy tắc mask viết lại email và số điện thoại thành [EMAIL] / [PHONE] trong prompt trước khi mô hình thấy nó.
  • Quy tắc flag theo dõi output của mô hình tìm một dấu confidential và ghi lại một match mà không thay đổi phản hồi — nên bạn có thể đo nó xuất hiện thường xuyên thế nào trước khi quyết định thực thi.
Engine chạy mọi quy tắc áp dụng được và gộp các kết quả thành một verdict. Nếu bất kỳ quy tắc nào block, request bị block.

3. block — từ chối với HTTP 400

Một hành động block từ chối toàn bộ cuộc gọi. Người gọi nhận HTTP 400 với mã lỗi guardrail_blocked và một thông điệp nêu tên guardrail và quy tắc đã kích hoạt.
Một block giai đoạn input kích hoạt trước khi đo lường, nên không có gì bị tiêu thụ. Một block giai đoạn output hoàn lại quota đã tiêu trước sau khi từ chối câu trả lời. Dù cách nào, người gọi không trả gì cho một cuộc gọi bị block.
Một kết quả guardrail_blockedskip-retry — chạy lại cùng prompt qua một channel khác sẽ chỉ block lại, nên gateway sẽ không phí một lần retry. Xem lỗi guardrail_blocked.
Trên một phản hồi non-streaming, câu trả lời được sàng lọc trước khi trả về. Trên một phản hồi streaming, một scanner cắt stream giữa chừng và phát một thông điệp thay thế trước khi bất kỳ nội dung bị block nào đến được client. Xem phạm vi streaming.
Dùng block khi một match nghĩa là request không được tiếp tục — secret trong một prompt, một nỗ lực jailbreak, một lằn ranh tuân thủ cứng rắn.

4. mask — redact và tiếp tục

Một hành động mask redact mỗi match và cho request đi qua với văn bản đã làm sạch. Mô hình thượng nguồn không bao giờ thấy bản gốc. Trên một quy tắc PII, mỗi match được thay bằng một thẻ có kiểu dẫn xuất từ entity — một email trở thành [EMAIL], một SSN trở thành [SSN], một thẻ tín dụng [CREDIT_CARD], v.v. (Bạn có thể ghi đè chuỗi thay thế cho mỗi entity tùy chỉnh; xem định dạng masking.)
Masking giai đoạn input hoạt động trực tiếp trên mọi stream. Nó viết lại request trước khi mô hình chạy, dù streaming hay không. Masking giai đoạn output chỉ áp dụng cho phản hồi non-streaming — văn bản đã che được chuyển tiếp sau khi toàn bộ câu trả lời được sàng lọc. Trên một phản hồi streaming, gateway tính toán mask nhưng chưa chuyển tiếp văn bản đã redact, nên một quy tắc mask không redact một phản hồi streaming hôm nay; masking output trong stream nằm trong lộ trình. (Một block output vẫn cắt một stream giữa chừng — xem §3.) Hãy chứng minh tổ hợp giai đoạn/stream chính xác của bạn trong sandbox trước. Xem phạm vi streaming.
Dùng mask khi nội dung ổn nhưng một chuỗi con không nên đến được mô hình — redact PII là trường hợp kinh điển. Điểm khởi đầu chìa khóa trao tay là preset PII Shield; xem PII Shield.

5. flag — chỉ ghi log, không thay đổi gì

Một hành động flagchỉ quan sát: request giống hệt từng byte với một request không có quy tắc nào cả, ngoại trừ một match được ghi lại trong Matches feed. Không có gì bị block, không có gì bị redact.
flag là cách bạn đo một quy tắc trước khi thực thi nó. Phát hành một keyword hoặc regex mới dưới dạng flag, theo dõi Matches feed trong vài ngày để xem tỷ lệ dương tính thật-so-với-giả của nó trên traffic thực, rồi thăng cấp nó lên mask hoặc block khi bạn tin tưởng nó. Tinh chỉnh một pattern nhiễu với flag bật tốt hơn phát hiện các dương tính giả trong production với block bật. Xem tinh chỉnh dương tính giả.
Một match được gắn cờ ghi lại loại quy tắc, hành động, giai đoạn, và một chuỗi chi tiết — và chuỗi con đã match chỉ khi Log raw content được bật cho guardrail đó (mặc định tắt, lập trường bảo thủ về quyền riêng tư). Xem logging & quyền riêng tư.

6. Ghi đè hành động theo từng entity

Một quy tắc PII duy nhất có thể định tuyến các entity khác nhau tới các hành động khác nhau qua entity_actions, thay vì chồng các quy tắc trùng lặp. Mỗi giá trị ghi đè phải là một trong block / mask / flag / annotate, và phải tham chiếu một entity mà quy tắc đã khai báo — validator từ chối mọi thứ khác.
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Quy tắc này che email, điện thoại, và IP nhưng block thẳng request trên một số thẻ hoặc SSN. Xem entity PII tùy chỉnh để xếp lớp các detector của riêng bạn dưới cùng mô hình ghi đè.

7. Chọn hành động đúng

Nếu bạn muốn…DùngHiệu ứng
Dừng request hoàn toànblockHTTP 400, không quota, skip-retry
Loại bỏ một chuỗi con, giữ cuộc gọimaskVăn bản đã redact được chuyển tiếp
Theo dõi mà không động vào trafficflagChỉ ghi lại match
Các hành động kết hợp với giai đoạn. Cùng một hành động hành xử hơi khác trên input so với output — một block input tiết kiệm quota trước; một block output hoàn lại nó; masking output chỉ áp dụng cho phản hồi non-streaming, trong khi một block output cắt cả phản hồi streaming lẫn non-streaming như nhau. Đọc giai đoạn inputgiai đoạn output cùng với trang này.

8. Đi đâu tiếp theo

Lỗi guardrail_blocked

Một lỗi 400 trông như thế nào, tại sao nó không tốn quota, và cách skip-retry hoạt động.

Định dạng masking

Thẻ có kiểu, chuỗi thay thế tùy chỉnh, và một prompt đã che đọc như thế nào đối với mô hình.

Phạm vi streaming

Chính xác tổ hợp hành động × giai đoạn × stream nào được thực thi hôm nay.

Chế độ thực thi

Cách block / mask / flag ánh xạ lên mô hình thực thi rộng hơn của gateway, bao gồm verdict audit của firewall.
Firewall có từ vựng verdict riêng của nó (allow, audit, deny, sanitize, và nhiều hơn) cho chính sách tool — khác với các hành động nội dung này. Xem guardrails so với firewall.