Kiểm tra lỗ hổng mô hình ngôn ngữ với garak

Playbook cho SOC và nhóm bảo mật đánh giá prompt injection, rò rỉ dữ liệu, jailbreak cùng các hành vi không mong muốn của ứng dụng LLM bằng garak; từ khoanh vùng probe, đọc FAIL đến tái kiểm tra có kiểm soát.

Một chatbot có thể trả lời tốt câu hỏi nghiệp vụ nhưng vẫn bị dẫn dắt tạo ra hành vi không mong muốn. Khi ứng dụng LLM kết nối với tài liệu, dữ liệu hoặc công cụ nội bộ, vài câu hỏi thử thủ công là chưa đủ.

Đội SOC cần một quy trình có thể lặp lại: đã thử gì, phát hiện gì, bằng chứng nằm ở đâu và sau thay đổi có còn tái diễn không. garak là công cụ dòng lệnh có thể hỗ trợ xây dựng quy trình đó.

Garak là gì?

garak là bộ công cụ red teaming và đánh giá LLM. Công cụ tập trung tìm cách khiến mô hình hoặc hệ thống hội thoại thất bại theo những cách không mong muốn.

Theo tài liệu dự án, garak có các probe cho nhiều nhóm rủi ro, gồm:

Prompt injection Rò rỉ dữ liệu Hallucination Thông tin sai lệch Sinh nội dung độc hại Jailbreak Các điểm yếu khác của LLM hoặc hệ thống hội thoại

Có thể hình dung garak có cách tiếp cận tương tự các công cụ kiểm tra bảo mật như nmap hoặc Metasploit Framework, nhưng dành cho LLM: công cụ gửi các tình huống kiểm tra gọi là probe tới mục tiêu, rồi dùng detector để đánh giá phản hồi.

Kết quả garak không phải là chứng nhận chatbot “an toàn”. Đây là đầu vào cho quản trị rủi ro, điều tra phát hiện và tái kiểm tra sau khi thay đổi model, cấu hình hoặc cách ứng dụng kết nối dữ liệu và công cụ.

Bắt đầu trong môi trường được ủy quyền

Nên chạy trên môi trường staging hoặc môi trường đánh giá được cấp phép. Cách này giúp kiểm soát dữ liệu, quyền truy cập, chi phí API và tác động của probe.

garak hỗ trợ nhiều loại đích, trong đó có:

Model trên Hugging Face Hub OpenAI API AWS Bedrock LiteLLM Mục tiêu truy cập qua REST Model GGUF tương thích llama.cpp phiên bản từ 1046 trở lên Một số loại LLM khác

Hai tham số cơ bản khi chọn mục tiêu là:

--targettype: loại giao diện hoặc họ connector, chẳng hạn openai hoặc huggingface. --targetname: tên model cụ thể cần đánh giá.

Cài đặt bản tiêu chuẩn từ PyPI:

bash python -m pip install -U garak

README cho biết garak được phát triển trên Linux và OSX. Nếu cần tách riêng môi trường chạy, có thể cài từ mã nguồn trong môi trường Conda:

bash conda create --name garak "python>=3.11,<=3.14" conda activate garak gh repo clone NVIDIA/garak cd garak python -m pip install -e .

Trước khi chạy, xem danh sách probe mà phiên bản garak hiện tại hỗ trợ:

bash garak --listprobes

Danh sách này giúp lập baseline về phạm vi rủi ro đã kiểm tra. Khi cần so sánh giữa các lần đánh giá, nên ghi nhận và cố định phiên bản garak, model đích, connector cùng cấu hình sinh đang sử dụng.

Khoanh vùng probe để kiểm soát chi phí và tác động

Theo mặc định, garak chạy toàn bộ probe mà công cụ biết trên mục tiêu, cùng các detector được khuyến nghị cho từng probe. Một prompt có thể tạo nhiều lượt sinh; tài liệu nêu mặc định là 10 lượt sinh cho mỗi prompt.

Vì vậy, chạy toàn bộ probe có thể tạo ra nhiều lượt gọi API. Trước khi quét rộng, nên khoanh vùng probe theo rủi ro ưu tiên để kiểm soát chi phí, thời gian và tác động tới môi trường kiểm tra.

Có thể giới hạn phạm vi bằng --spec. Ví dụ README dùng probe encoding để kiểm tra prompt injection dựa trên encoding với một model qua OpenAI API:

bash export OPENAIAPIKEY="sk-123XXXXXXXXXXXX" python3 -m garak --targettype openai --targetname gpt-5-nano --spec probes.encoding

Trong lệnh này:

--targettype openai chọn connector OpenAI. --targetname gpt-5-nano chọn model cần kiểm tra. --spec probes.encoding chỉ chạy nhóm probe encoding.

garak cũng cho phép chỉ định một plugin probe cụ thể bằng cách thêm tên plugin sau tên nhóm. Chẳng hạn, README nêu probes.lmrc.SlurUsage như một ví dụ về cú pháp chọn plugin thuộc nhóm Language Model Risk Cards. Khi áp dụng vào mục tiêu đã được phê duyệt, nhóm có thể xây dựng lệnh theo cấu trúc:

bash garak --targettype <loaimuctieu> --targetname <tenmodel> --spec probes.lmrc.SlurUsage

Không nên coi đây là lệnh mẫu có sẵn cho một model cụ thể. Hãy xác nhận plugin, connector và target phù hợp với phiên bản garak đang triển khai trước khi chạy.

Đọc kết quả FAIL đúng cách

Sau khi hoàn tất tạo phản hồi, garak hiển thị kết quả đánh giá theo từng probe và detector. Nếu một lần thử tạo ra hành vi không mong muốn, kết quả được đánh dấu FAIL và công cụ hiển thị tỷ lệ thất bại.

Tài liệu cũng nêu:

Lỗi vận hành được ghi vào garak.log. Chi tiết lượt chạy được lưu trong tệp .jsonl. Đường dẫn tệp .jsonl được garak thông báo khi bắt đầu và khi kết thúc lượt chạy.

Hãy lưu chính đường dẫn JSONL mà công cụ thông báo trong hồ sơ đánh giá. Việc này giúp nhóm truy xuất đúng dữ liệu gốc thay vì giả định một vị trí lưu cố định.

Một kết quả FAIL không tự động chứng minh đã có sự cố thực tế. Đây là tín hiệu để điều tra trong phạm vi được kiểm soát.

Quy trình xử lý FAIL đề xuất

Ghi nhận model, connector, phiên bản garak, probe, detector và thời điểm chạy. Lưu prompt, phản hồi và log cần thiết; che giấu dữ liệu nhạy cảm nếu có. Rà soát thủ công một mẫu kết quả FAIL để phân biệt lỗ hổng có ý nghĩa, kết quả nhiễu hoặc giới hạn của detector. Tái hiện phát hiện trong môi trường được ủy quyền. Chuyển phát hiện cho nhóm phụ trách ứng dụng hoặc model để đánh giá biện pháp khắc phục. Chạy lại đúng probe với cùng model và cấu hình đã ghi nhận, rồi so sánh kết quả trước và sau thay đổi.

Không nên chỉ nhìn vào tỷ lệ FAIL. Nhóm xử lý cần xác định hành vi đó có ý nghĩa gì với ứng dụng cụ thể: phản hồi sai lệch đơn thuần, nguy cơ lộ dữ liệu hay khả năng khiến ứng dụng kích hoạt một công cụ ngoài ý muốn.

Kiểm soát dữ liệu kiểm thử và đầu ra

Prompt kiểm thử, phản hồi của model, garak.log và tệp JSONL có thể chứa dữ liệu nhạy cảm, tùy theo mục tiêu và cách ứng dụng được cấu hình.

Do đó, đội vận hành nên:

Giới hạn quyền truy cập vào log và tệp kết quả. Áp dụng chính sách che giấu dữ liệu nhạy cảm trước khi chia sẻ bằng chứng. Xác định thời hạn lưu giữ phù hợp cho prompt, đầu ra và nhật ký. Tránh đưa dữ liệu thật không cần thiết vào môi trường thử nghiệm.

Nếu muốn đưa dữ liệu vào hệ thống log tập trung hoặc SIEM, hãy kiểm tra cấu trúc đầu ra của đúng phiên bản garak đang triển khai trước khi xây parser hoặc rule.

Đưa kết quả vào quy trình SOC

Một ticket đánh giá nên tối thiểu có:

Tên ứng dụng và môi trường kiểm tra Model, targettype và targetname Phiên bản garak và cấu hình chạy được ghi nhận Probe và detector đã chạy Kết quả FAIL cùng mẫu bằng chứng đã được xử lý phù hợp Chủ sở hữu khắc phục Kết quả tái kiểm tra Quyết định chấp nhận rủi ro, giảm thiểu hoặc chặn triển khai

Cần xác định tiêu chí dừng triển khai trước khi mở rộng sử dụng. Ví dụ, nên chặn hoặc tạm dừng khi một FAIL đã được xác nhận có khả năng dẫn tới truy cập dữ liệu không phù hợp hoặc kích hoạt công cụ ngoài ý muốn.

Cách lưu vết này giúp SOC trả lời các câu hỏi thực tế: phát hiện xuất hiện từ khi nào, thay đổi nào liên quan và biện pháp khắc phục đã được xác nhận hay chưa.

Checklist trước khi mở rộng triển khai

[ ] Chỉ chạy quét với model, tài khoản và môi trường được ủy quyền. [ ] Cố định và ghi nhận phiên bản garak, model, connector và cấu hình sinh. [ ] Dùng garak --listprobes để xác định phạm vi probe hiện có. [ ] Khoanh vùng probe theo rủi ro ưu tiên trước khi chạy phạm vi lớn. [ ] Dự tính số lượt gọi API và kiểm soát chi phí thử nghiệm. [ ] Ghi lại đường dẫn JSONL mà garak thông báo ở đầu và cuối lượt chạy. [ ] Rà soát thủ công mẫu FAIL trước khi kết luận có lỗ hổng. [ ] Kiểm soát quyền truy cập và thời hạn lưu giữ prompt, đầu ra, log. [ ] Chạy lại các probe liên quan sau khi thay đổi model hoặc cấu hình. [ ] Chặn hoặc tạm dừng triển khai khi FAIL đã xác nhận có thể dẫn tới lộ dữ liệu hoặc kích hoạt công cụ ngoài ý muốn.

garak giúp biến câu hỏi chung chung “chatbot này có an toàn không?” thành hoạt động kiểm tra có phạm vi, có bằng chứng và có thể lặp lại. Giá trị không chỉ nằm ở số probe đã chạy, mà ở kỷ luật điều tra FAIL, kiểm soát dữ liệu kiểm thử và xác nhận lại sau khắc phục.