Cẩm Nang Kiểm Định Mô Hình Cho GenAI: Bài Học Từ Ngành Ngân Hàng
Các tiêu chuẩn kiểm định mô hình đang thay đổi mạnh mẽ khi đối mặt với hệ thống dựa trên LLM. Bài viết phân tích năm điểm phá vỡ cấu trúc truyền thống, đề xuất khung phân loại rủi ro và chiến lược đánh giá kết quả đầu ra cho AI tạo sinh, rút ra từ kinh nghiệm thực tế trong lĩnh vực tài chính - ngân hàng.
Cẩm Nang Kiểm Định Mô Hình Cho GenAI: Bài Học Từ Ngành Ngân Hàng
Trong bối cảnh AI tạo sinh (GenAI) đang thâm nhập nhanh vào mọi lĩnh vực, các quy trình kiểm định mô hình truyền thống trong ngân hàng đang đứng trước thách thức chưa từng có: làm sao để xác thực một "chiếc hộp đen" mà ta không thể nhìn thấy dữ liệu huấn luyện hay tái tạo lại thuật toán. Từ những thay đổi mang tính cấu trúc, các chuyên gia đang chuyển trọng tâm từ việc sao chép kết quả sang thiết kế các bài kiểm tra hành vi, đánh giá phân tầng rủi ro và giám sát liên tục để phát hiện các sai lệch tiềm ẩn (drift). Một khuôn khổ mới đang được xây dựng, không chỉ dành riêng cho tài chính mà còn cho bất kỳ lĩnh vực nghiêm túc nào triển khai GenAI.
Giới thiệu vấn đề
Hãy bắt đầu với một tình huống ngày càng phổ biến tại bộ phận Quản lý Rủi ro của các ngân hàng lớn. Một chuyên viên kiểm định mô hình rủi ro nhận được một hồ sơ trình duyệt mới. Mô hình lần này là một trợ lý AI có khả năng đọc báo cáo tài chính của khách hàng vay, thu thập các nghiên cứu của bên thứ ba và soạn thảo bản nháp đầu tiên của một bản ghi nhớ tín dụng. Nó giúp các nhà phân tích tiết kiệm hàng giờ làm việc mỗi tuần và nghiệp vụ này muốn đưa AI vào hoạt động ngay từ quý sau.
Chuyên viên mở mẫu kiểm định tiêu chuẩn để bắt đầu quá trình rà soát. Mẫu này được hoàn thiện qua hàng thập kỷ thanh tra, đã dùng cho mọi bảng chấm điểm tín dụng, mô hình dự báo tổn thất và hệ thống định giá. Câu hỏi đầu tiên: "Cung cấp mẫu dữ liệu phát triển (development sample)."
Nhưng không có mẫu dữ liệu phát triển. Mô hình AI này được huấn luyện trên một kho ngữ liệu không ai trong ngân hàng từng thấy, bởi một nhà cung cấp không chịu mô tả về nó. Và đó mới chỉ là câu hỏi đầu tiên trong số... chín mươi câu còn lại. Quản lý rủi ro mô hình chưa bao giờ được thiết kế cho AI tạo sinh trong lĩnh vực ngân hàng. Đây chính là điểm mà hầu hết các bộ phận chức năng rủi ro mô hình trong lĩnh vực tài chính trên toàn cầu đang mắc kẹt. Một sự thách thức hiệu quả đối với mô hình không thể huấn luyện lại, không thể nhìn thấy dữ liệu huấn luyện, giờ đây phải trông khác hoàn toàn so với việc đánh giá một bảng chấm điểm tín dụng truyền thống. Nghệ thuật của người kiểm định chuyển từ việc sao chép sang việc thiết kế bài kiểm tra.
Tại sao khuôn khổ này quan trọng ngoài phạm vi ngân hàng?
Thách thức cốt lõi được mô tả trong bài viết - làm sao để xác thực một hệ thống mà bạn không thể kiểm tra toàn diện - hiện đang trở thành vấn đề chung cho bất kỳ ai triển khai AI tạo sinh trong một môi trường sản xuất nghiêm túc. Cho dù bạn đang xây dựng một công cụ tóm tắt y khoa, một trợ lý nghiên cứu pháp lý hay một chatbot phục vụ khách hàng, những câu hỏi tương tự vẫn được đặt ra: "Tốt" trông như thế nào khi không có chân lý khách quan (ground truth)? Làm thế nào để phát hiện lỗi sai một cách tự tin (confident errors) trước khi chúng đến tay người dùng?
Khuôn khổ nêu trong bài viết này - dựa trên việc phân loại rủi ro (risk tiering), đánh giá dựa trên kết quả (outcome-based evaluation), kiểm tra độ mạnh mẽ (robustness testing) và giám sát sự sai lệch thầm lặng (silent drift) - được xây dựng cho ngân hàng, nhưng có thể chuyển giao trực tiếp cho bất kỳ lĩnh vực nào mà chi phí của việc sai lầm quan trọng hơn chi phí của việc chậm trễ.
Quản lý rủi ro mô hình trong ngân hàng thực sự làm gì?
Nếu bạn làm việc trong lĩnh vực khoa học dữ liệu ngoài ngân hàng, kỷ luật này có thể còn xa lạ. Hãy đặt bối cảnh một cách đúng đắn. Ngân hàng vận hành chủ yếu dựa trên các mô hình dự đoán thống kê truyền thống. Các mô hình này quyết định ai được cấp tín dụng và với mức giá nào. Chúng xác định ngân hàng phải nắm giữ bao nhiêu vốn đối ứng với danh mục cho vay. Chúng dự báo tổn thất trong các kịch bản suy thoái giả định, định giá các tài sản kém thanh khoản, phát hiện các giao dịch đáng ngờ và xác định khoản dự phòng đi thẳng vào báo cáo tài chính công bố. Khi một trong các mô hình này sai, hậu quả không chỉ là một người dùng không hài lòng; mà là rủi ro bị định giá sai, dự phòng bị khai thiếu, các kết luận/xử phạt từ cơ quan quản lý và đôi khi là một khoản lỗ rất lớn.
Ngành công nghiệp đã trả giá đắt cho bài học này. Các mô hình tín dụng giả định giá nhà không bao giờ giảm trên toàn quốc đã góp phần quan trọng vào cuộc khủng hoảng năm 2008. Một mô hình rủi ro được sửa đổi tại một ngân hàng vào năm 2012 đã báo cáo thiếu mức độ phơi nhiễm một cách nghiêm trọng đến mức lỗ giao dịch lên tới hàng tỷ USD trước khi bất kỳ ai phát hiện ra. Các cơ quan quản lý đã phản ứng bằng cách chính thức hóa kỷ luật này: Hướng dẫn giám sát của Hoa Kỳ ban hành năm 2011 (thường được biết đến với tên SR 11-7) đã định nghĩa rủi ro mô hình là khả năng xảy ra các hậu quả bất lợi từ các quyết định dựa trên kết quả đầu ra của mô hình không chính xác hoặc bị sử dụng sai mục đích, và yêu cầu các ngân hàng quản lý nó một cách có chủ đích.
Đạo luật AI của EU cũng hệ thống hóa các kỳ vọng tương tự cho các hệ thống AI rủi ro cao được sử dụng trong đánh giá mức độ tín nhiệm, định giá hoặc các dịch vụ ngân hàng thiết yếu. Các nghĩa vụ cốt lõi của nó về quản lý rủi ro, quản trị dữ liệu, tài liệu kỹ thuật, lưu trữ hồ sơ, minh bạch, giám sát của con người và độ chính xác/mạnh mẽ khớp gần như hoàn toàn với các yêu cầu về tính hợp lý về mặt khái niệm, phân tích kết quả và giám sát liên tục trong SR 11-7.
Cấu trúc quản lý rủi ro mô hình khá nhất quán giữa các tổ chức lớn, dựa trên mô hình tuyến phòng thủ (Lines of Defense):
| Tuyến phòng thủ | Bên đảm nhiệm | Vai trò |
|---|---|---|
| Thứ nhất | Kinh doanh & Phát triển mô hình | Xây dựng mô hình, tự kiểm tra, chịu trách nhiệm về hiệu suất và mục đích sử dụng |
| Thứ hai | Quản lý rủi ro mô hình / Kiểm định | Độc lập phản biện trước khi phê duyệt và liên tục phản biện sau đó |
| Thứ ba | Kiểm toán nội bộ | Kiểm tra xem hai tuyến đầu có đang làm đúng việc của mình hay không |
Tuyến phòng thủ thứ hai là phần mà bài viết này tập trung vào. Người kiểm định không chỉ kiểm tra số học. Họ đặt câu hỏi liệu cách tiếp cận mô hình hóa có hợp lý về mặt khái niệm hay không, liệu dữ liệu có hỗ trợ cho nó hay không, liệu kết quả đầu ra có thực sự hoạt động tốt, liệu việc triển khai trong sản xuất có khớp với những gì đã được phê duyệt hay không, và liệu những người sử dụng kết quả đó có hiểu các giới hạn của nó. Không gì có thể đi vào hoạt động mà không có sự ký duyệt của họ, và mọi thứ đều được xem xét lại định kỳ.
Ba trụ cột làm nền tảng cho quá trình đánh giá đó đã ổn định trong hơn một thập kỷ: tính hợp lý về mặt khái niệm (cách tiếp cận có thể bảo vệ được không?), phân tích kết quả (kết quả đầu ra có trụ vững khi được kiểm tra?), và giám sát liên tục (nó còn hoạt động tốt ở thời điểm hiện tại không?).
Vì sao GenAI phá vỡ quy trình kiểm định mô hình truyền thống?
AI tạo sinh đã đến các ngân hàng nhanh hơn bất kỳ công nghệ mô hình hóa nào trong thời gian gần đây, và không theo một hình dạng cụ thể nào. Nó có thể là tóm tắt khiếu nại, truy vấn chính sách nội bộ, thu thập nghiên cứu, soạn thảo nháp đầu tiên của bản ghi nhớ tín dụng, hoặc bất kỳ loại hình nào khác.
Những mô hình này rất hấp dẫn vì chúng ảnh hưởng trực tiếp đến chi phí, nhưng chúng cũng có thể rủi ro. Vì chúng hoạt động gần với khách hàng và gần các quyết định tín dụng. Đây chính là những nơi mà một tổ chức được quản lý chặt chẽ có ít "khẩu vị rủi ro" nhất cho một câu trả lời sai.
Và bộ máy kiểm định tồn tại để ngăn chặn rủi ro đó không còn phù hợp nữa. Mọi câu hỏi trong mẫu đánh giá đều giả định các đặc tính mà các hệ thống này không có.
1. Năm điểm phá vỡ cấu trúc trong kiểm định mô hình GenAI
| Đặc tính | Lý do kiểm định cổ điển không thể xử lý |
|---|---|
| Không có "mô hình" mà là một "hệ thống" | Xử lý truy vấn, truy xuất thông tin (retrieval), mẫu lời nhắc (prompt), mô hình nền, cấu hình giải mã (decoding settings), bộ lọc an toàn (guardrails), điều phối (orchestration). Thay đổi bất kỳ bộ phận nào, hành vi của hệ thống đều thay đổi |
| Kết quả đầu ra là một phân phối, không phải một điểm số | Tính phi xác định (non-determinism) là một tính năng thiết kế. Ngay cả ở cài đặt nhiệt độ (temperature) thấp nhất, hiệu ứng batching và ngữ cảnh vẫn tạo ra sự biến thiên |
| Không có chân lý khách quan cho các tác vụ mở | AUC, KS, Gini và MSE... hoạt động dựa trên một chỉ tiêu quan sát được. Tóm tắt văn bản và soạn thảo nháp có gì để so sánh đâu |
| Bạn không xây dựng thành phần cốt lõi | Không có dữ liệu huấn luyện, không có tài liệu phương pháp luận, không thể tái tạo. Chỉ có một "system card" và các điểm benchmark không liên quan |
| Sai lệch phiên bản mà không có yêu cầu thay đổi | Các mô hình dạng hosting được cập nhật phía sau một endpoint ổn định. Không có gì trong quy trình quản lý thay đổi được kích hoạt, vì về mặt thủ tục, không có gì thay đổi |
Hàng đầu tiên có một hệ quả trực tiếp về thủ tục. Đơn vị kiểm định là hệ thống, không phải mô hình. Hai trường hợp sử dụng (use case) khác nhau nằm trên cùng một mô hình nền sẽ được tính là hai lần kiểm định riêng biệt.
Hàng thứ hai đảo ngược một bản năng mà chúng ta cần gọi tên. Một hệ thống trả lời đúng 95% thời gian và tạo ra câu trả lời sai một cách đầy tự tin 5% thời gian là một "đối tượng" khác với một mô hình có tỷ lệ lỗi 5% trên một phân phối lỗi đã biết. Sự trôi chảy (fluency) của một câu trả lời không tương quan với tính đúng đắn – điều chưa từng thấy ở một mô hình xác suất vỡ nợ (PD) đã được hiệu chuẩn.
Vì những điểm phá vỡ cấu trúc này khiến cho việc kiểm định tràn lan là bất khả thi, nên phân loại rủi ro trở thành đòn bẩy quyết định bao nhiêu bằng chứng là đủ.
2. Phân loại rủi ro cho GenAI: Một khuôn khổ thực tế
Mọi thứ phía sau đều phụ thuộc vào việc phân loại rủi ro, vì vậy đây là nơi người kiểm định tập trung nhiều nhất. Các yếu tố cổ điển vẫn được áp dụng - sự phụ thuộc của nghiệp vụ, tác động của sai lầm, độ phức tạp, khả năng kiểm soát. Hai yếu tố nữa đặc biệt quan trọng trong các hệ thống này:
Kết quả đầu ra có thể "đi" xa đến mức nào?
| Mức độ phơi nhiễm | Ví dụ | Hàm ý thực tế |
|---|---|---|
| Đầu vào cho một quyết định nội bộ | Nghiên cứu tóm tắt là đầu vào cho quyết định cấp tín dụng | Bước xem xét của con người chính là biện pháp kiểm soát |
| Đến tay khách hàng hoặc cơ quan quản lý | Thư từ, công bố thông tin, phản hồi khiếu nại | Rủi ro về uy tín và hành vi (conduct risk) chi phối rủi ro mô hình |
Hệ thống chỉ tạo văn bản hay còn "hành động"? Một hệ thống soạn thảo thứ mà con người đọc có rủi ro thấp. Nhưng một hệ thống có thể gọi công cụ (tools), ghi vào các hệ thống lưu trữ hồ sơ hoặc kích hoạt các quy trình hạ nguồn (downstream) lại có một cấu hình rủi ro hoàn toàn khác.
3. Ba câu hỏi mà một báo cáo đánh giá rủi ro mô hình AI phải trả lời
Các câu hỏi giống như những gì chúng ta vẫn luôn hỏi. Nhưng thứ được coi là bằng chứng đã thay đổi hoàn toàn.
Minh họa quy trình đánh giá mô hình AI tạo sinh
4. Trước khi nhìn vào kết quả đầu ra
A. Có nên dùng mô hình ngôn ngữ ở đây hay không?
Đây là thách thức rẻ nhất và mang lại giá trị nhất. Một số lượng đáng ngạc nhiên các trường hợp sử dụng được đề xuất là các bài toán tất định (deterministic) - nơi mà một mô hình tạo sinh lại đưa thêm sự biến thiên vào để giải quyết một việc mà bộ phân tích cú pháp (parser) làm chính xác hoàn toàn. Nếu một phương pháp đơn giản hơn đạt được 90% giá trị mà không hề có nguy cơ bịa đặt (fabrication), thì sự so sánh đó cần được nằm trong báo cáo. Sự phức tạp phải tự chứng minh được vị trí của nó.
B. Chính xác thì "hệ thống" gồm những gì?
Hãy yêu cầu một bản đồ các thành phần. Sau đó hỏi thành phần nào mà tổ chức thực sự có quyền kiểm soát.
| Thành phần | Ai kiểm soát | Điều gì có thể hỏng |
|---|---|---|
| Truy xuất và chỉ mục (Retrieval & Index) | Bạn | Bằng chứng lỗi thời hoặc thiếu; truy cập quá rộng |
| Mẫu lời nhắc (Prompt template) | Bạn | Hướng dẫn mơ hồ; lỗ hổng bị tấn công/chèn lệnh (prompt injection) |
| Mô hình nền (Base model) | Nhà cung cấp | Mọi thứ |
| Cấu hình giải mã (Decoding settings) | Bạn | Sự phân tán (dispersion) của đầu ra |
| Bộ lọc an toàn (Guardrails) | Bạn | Vừa chặn quá mức lẫn chặn không đủ |
| Điều phối (Orchestration) | Bạn | Lỗi cộng dồn qua các bước |
Trong môi trường sản xuất, chất lượng truy xuất và cấu trúc lời nhắc thường chi phối hiệu suất hơn cả. Mô hình nền thường là nguồn biến thiên ít quan trọng nhất - điều này khá may mắn, vì đó cũng là phần bạn không thể kiểm tra.
C. Điều gì đã tạo nên nó?
Đặc tả kỹ thuật không phải là "chúng tôi dùng một mô hình nền." Mỗi lựa chọn tùy chỉnh đều cần có lý do chính đáng:
- Sử dụng prompt (điều hướng) so với fine-tuning (tinh chỉnh): Tại sao chọn cách này, với chi phí nào, gánh nặng bảo trì ra sao?
- Nội dung và cấu trúc của prompt: Các prompt cần được quản lý phiên bản như một phần logic của mô hình.
- Cấu hình giải mã: Nhiệt độ (temperature) và phương pháp lấy mẫu kiểm soát trực tiếp mức độ phân tán; thay đổi chúng cũng được coi là thay đổi mô hình.
- Giới hạn ngữ cảnh: Tài liệu đầu vào thực tế có nằm gọn trong khung không? Điều gì xảy ra nếu vượt quá?
- Dữ liệu tinh chỉnh: Nguồn gốc, có chứa thông tin mật hay không, các ví dụ đã được kiểm tra chất lượng như thế nào?
D. Phần nào chúng ta có thể trung thực giải thích?
Các công cụ giải thích mô hình truyền thống không giúp được gì nhiều ở đây. Trong thực tế, có hai cách tiếp cận khả thi. Cách thứ nhất là gán nhãn cấp độ phát biểu (claim-level attribution) – kiểm tra từng phát biểu mang tính dữ kiện trong đầu ra của mô hình xem nó có truy vết được về một đoạn văn cụ thể trong tài liệu nguồn hay không. Cách này có thể thực hiện được và hữu ích. Cách thứ hai - mô tả đầy đủ hành vi hệ thống trên mọi đầu vào có thể - là bất khả thi.
Sự thay thế thực tế là kiểm thử hành vi (behavioral testing) trên một tập hợp các tình huống có cấu trúc. Bạn chủ động kiểm thử hệ thống trên nhiều loại đầu vào có kiểm soát, quan sát cách nó hành xử và sau đó khái quát hóa một cách cẩn trọng từ những quan sát đó. Bạn đang xây dựng hồ sơ hành vi (profiling) cho hệ thống, chứ không phải chứng minh tính đúng đắn của nó.
Phân tích kết quả cho rủi ro LLM: Các chỉ số về Hallucination (Ảo giác) và Tính bám rễ (Groundedness)
Phân tích kết quả là bước quan trọng nhất. Đây là nơi chúng ta kiểm tra xem hệ thống có thực sự làm những gì nó được quảng bá và nó hỏng ở đâu.
Các chỉ số phụ thuộc vào nhiệm vụ
Điểm khởi đầu là ánh xạ trường hợp sử dụng vào đúng các chiều đánh giá.
| Nhiệm vụ | Chiều đánh giá cốt lõi |
|---|---|
| Tóm tắt (Summarisation) | Tính đầy đủ (completeness), nhất quán về mặt thực tế với nguồn, độ trôi chảy |
| Trả lời có truy xuất (RAG) | Các khẳng định có được nguồn từ ngữ cảnh đã truy xuất hay không / câu trả lời có tuân thủ chỉ dẫn trong truy vấn / tài liệu truy xuất có đầy đủ và sạch nhiễu |
| Sinh văn bản mở (Open generation) | Tuân thủ chỉ dẫn, phong cách và giọng điệu, độ dài, tính chính xác thực tế theo tham chiếu ngoài |
Các chiều cấp cao này chỉ là điểm khởi đầu. Trong thực tế, một báo cáo kiểm định cần chấm điểm mọi đầu ra trên các chiều riêng biệt được công bố rõ ràng. Việc gộp chúng lại thành một điểm chất lượng duy nhất sẽ che giấu các cách thức cụ thể mà hệ thống có thể thất bại.
Nhóm chỉ số thứ nhất: Đầu ra có đáng tin cậy về mặt thực tế không?
| Chỉ số | Nó hỏi điều gì | Cách chấm điểm |
|---|---|---|
| Tính trung thực về mặt thực tế | Các khẳng định về vấn đề có đúng không? | Bộ tham chiếu có nhãn của chuyên gia, kiểm tra từng khẳng định |
| Tỷ lệ ảo giác | Có bịa đặt các thực thể, con số, trích dẫn hay mệnh đề không? | Đếm các đoạn bịa đặt: tự động hóa cho trích dẫn, kiểm tra thủ công cho phần còn lại |
| Tính bám rễ | Mọi khẳng định có truy vết lại từ bằng chứng đã cung cấp hay không? | Kiểm tra quan hệ kéo theo giữa khẳng định và nguồn |
| Tính đầy đủ | Có phần nào của truy vấn bị bỏ sót không? | Danh sách kiểm tra các phần tử cần thiết |
| Sự liên quan | Có trả lời đúng câu hỏi được hỏi hay không? | Danh sách kiểm tra |
Ba chỉ số đầu tiên thường bị gộp thành một con số nhiều hơn mức cần thiết. Một phản hồi có thể hoàn toàn bám rễ vào một tài liệu đã lỗi thời. Vì vậy, nó có thể bám rễ nhưng không đúng trong bối cảnh hiện tại. Một phản hồi có thể đúng nhưng không bám rễ, điều này cực kỳ khó sử dụng trong một quy trình có quản lý vì người xem xét không thể xác minh nó. Trong công việc tín dụng và tuân thủ, tính bám rễ thường là ràng buộc quan trọng nhất, vì khả năng kiểm chứng chính là biện pháp kiểm soát.
Nhóm chỉ số thứ hai: Đầu ra có khả dụng và an toàn trong một quy trình có quản lý không?
| Chỉ số | Nó hỏi điều gì | Cách chấm điểm |
|---|---|---|
| Tuân thủ chỉ dẫn | Mọi ràng buộc tường minh (ví dụ: định dạng, độ dài, tiết mục, loại trừ) có được tôn trọng? | Danh sách kiểm tra |
| Tuân thủ định dạng | Đầu ra có phân tích cú pháp được thành kịch bản mà quy trình hạ nguồn mong đợi? | Đạt/Không đạt so với schema |
| Độ dài | Độ dài có tương xứng với nhiệm vụ? | Thang đo cho sự dài dòng không cần thiết |
| Chất lượng viết | Phong cách viết có rõ ràng, có cấu trúc tốt? | Thang đo |
| Sự phù hợp của việc từ chối | Nó có từ chối những gì cần từ chối? | Hai bộ tình huống: nên-từ-chối và nên-trả-lời |
| Sai lệch trong đầu ra | Chất lượng có thay đổi theo các thuộc tính được bảo vệ (giới tính, dân tộc...)? | So sánh cặp khớp nhau (matched-pair comparison) |
| Sự ổn định | Cùng một đầu vào, câu trả lời có khác nhau về bản chất? | Đo độ tương đồng ngữ nghĩa trên nhiều lần sinh khác nhau |
Kiểm tra độ mạnh mẽ (Robustness)
Thay đổi đầu vào theo các cách vẫn giữ nghĩa và kiểm tra xem đầu ra có thay đổi không:
- Văn bản nguồn: Thay thế từ đồng nghĩa, cố tình gõ sai chính tả, định dạng lại.
- Diễn đạt truy vấn: Cùng một câu hỏi nhưng hỏi bằng ba cách khác nhau.
- Bằng chứng được cung cấp: Đảo thứ tự các đoạn văn, chèn một đoạn không liên quan, bỏ bớt một đoạn.
Đảo thứ tự bằng chứng là một trong những bài kiểm tra giá trị cao nhất. Nếu câu trả lời thay đổi trong khi bằng chứng vẫn vậy, chúng ta đã tìm ra một điểm yếu thực sự.
Xác định chỗ hỏng, không chỉ là tần suất hỏng
Điểm số tổng hợp che giấu sự thất bại cục bộ. Ta có thể nhúng (embed) quần thể đầu vào, phân cụm (clustering) và chấm điểm theo từng cụm. Các đoạn yếu thường mang tính gắn kết về ngữ nghĩa - ví dụ như một loại tài liệu, một sản phẩm, hoặc một phong cách diễn đạt. Khi đã xác định được, ta có thể giới hạn phạm vi sử dụng hoặc khắc phục chúng.
Phát hiện Hallucination trên quy mô lớn: Ba phương pháp đã được kiểm chứng
Các phương pháp phát hiện ảo giác trong mô hình ngôn ngữ
Có ba cách tiếp cận chính được sử dụng để phát hiện hallucination: sử dụng một mô hình LLM khác làm giám khảo (LLM-as-a-judge) để chấm điểm tính nhất quán; kỹ thuật lấy mẫu nội bộ (self-check) như SelfCheckGPT để so sánh các lần sinh khác nhau nhằm tìm ra các tuyên bố mâu thuẫn; hoặc kiểm tra tính bám rễ của từng khẳng định vào nguồn tài liệu.
Kiểm định "người chấm điểm" (Judge the judge)
Hầu hết các quy trình sử dụng một mô hình ngôn ngữ thứ hai để chấm điểm dựa trên tiêu chí. Người chấm điểm đó cũng là một mô hình sinh ra đầu ra phục vụ cho quyết định kiểm soát.
| Bài