Tôi vận hành một bản sao kỹ thuật số (digital twin) trên trang web của mình. Nó trả lời các câu hỏi về cuộc sống và kỹ năng của tôi. Tôi đã đặt ra cho nó một quy tắc nghiêm ngặt: không bao giờ được bịa đặt. Nếu ai đó hỏi về một kỹ năng mà tôi không có, nó phải thừa nhận là không biết. Trong nhiều tháng, tôi tin rằng hệ thống đang hoạt động tốt. Tôi đã kiểm tra thủ công đây đó, và các câu trả lời trông có vẻ rất ổn. Sau đó, tôi xây dựng một hệ thống đánh giá (evaluation harness) bài bản. Những con số thực sự gây sốc. Trong số 35 câu hỏi, có 9 câu chứa những lời nói dối trắng trợn. Trong số 8 câu hỏi được thiết kế để không thể trả lời được, mô hình chỉ từ chối 4 câu. Prompt chống ảo giác của tôi thất bại khoảng một phần tư số lần. Tôi đã đang cung cấp một sản phẩm nói dối người dùng của mình.
Một thiết lập truy xuất cực kỳ đơn giản
Tôi không triển khai Pinecone hay bất kỳ cơ sở dữ liệu vector nặng nề nào. Toàn bộ thiết lập chỉ nằm trên một tệp JSON thuần túy. Mã của tôi chia hồ sơ của tôi thành các phần riêng biệt. Khi một câu hỏi đến, hệ thống tính toán độ tương đồng cosine giữa truy vấn và từng đoạn văn bản, chọn ra các kết quả khớp nhất, và đưa chúng vào prompt dưới dạng ngữ cảnh. Sau đó, mô hình sẽ tạo ra câu trả lời dựa trên những gì nó thấy trong cửa sổ ngữ cảnh đó.
Đối với một trang web cá nhân nhỏ phục vụ một tập hợp các sự thật hạn hẹp, cách tiếp cận này nhanh và gần như không tốn kém gì. Không có vòng lặp mạng đến một kho lưu trữ vector từ xa, không có chi phí lập chỉ mục (indexing overhead), và không có sự điều phối phức tạp. Bạn đọc tệp, chấm điểm các đoạn văn, xây dựng prompt, và xong. Nhưng sự đơn giản ở phía backend không đảm bảo sự trung thực ở đầu ra. Một quy trình (pipeline) nhẹ vẫn có thể gây ra những vấn đề nghiêm trọng khi mô hình quyết định "tự ứng biến". Khoảng cách giữa "đây là ngữ cảnh" và "đây là những gì tôi sẽ nói về nó" chính là nơi các ảo giác tồn tại. Bạn có thể đưa cho mô hình một đoạn văn về lịch sử làm việc của mình nhưng vẫn nhận lại một lời bịa đặt đầy tự tin về một ngôn ngữ lập trình mà bạn chưa bao giờ chạm tới.
Những con số làm tôi mất niềm tin
Trong nhiều tháng, tôi coi việc kiểm tra thủ công ngẫu nhiên là đủ bao phủ. Tôi sẽ mở khung chat, hỏi một câu hỏi mà tôi đã biết câu trả lời, và gật đầu khi phản hồi trông có vẻ đúng. Đó là chiến lược kiểm thử của tôi. Nó tạo cảm giác kỹ lưỡng vì chính tôi đang sử dụng giao diện đó. Nhưng thực tế không phải vậy.
Khi cuối cùng tôi viết được một hệ thống đánh giá có thể chạy một cách có hệ thống, bức tranh đã thay đổi. Bộ thử nghiệm đã gửi 35 câu hỏi đến bản sao kỹ thuật số. Chín câu trả lời chứa đựng những lời nói dối. Tôi cũng đưa vào tám câu hỏi không có câu trả lời nào trong hồ sơ của mình. Mô hình lẽ ra phải từ chối tất cả. Nhưng nó chỉ từ chối bốn câu. Prompt chống ảo giác được tôi trau chuốt kỹ lưỡng, cái mà bao gồm những ngôn từ tuyệt đối về việc không bao giờ được bịa đặt, đã thất bại khoảng 25% số lần. Một trên bốn. Đó không phải là một sai số làm tròn. Đó là một sản phẩm lỗi.
Đừng kiểm thử bằng những câu hỏi "thân thiện"
Bạn không thể tìm thấy lỗi bằng cách chỉ đơn giản là sử dụng sản phẩm của chính mình. Bạn tìm thấy chúng bằng cách cố gắng phá vỡ nó. Các bài kiểm tra thủ công của tôi quá "thân thiện". Tôi chỉ hỏi những câu hỏi mà tôi biết chính xác câu trả lời, điều đó có nghĩa là tôi đang vô thức dẫn dắt mô hình vào vùng an toàn. Tôi chưa bao giờ thăm dò các giới hạn. Tôi chưa bao giờ hỏi về những kỹ năng mà tôi ước mình có, hoặc về những trải nghiệm chưa bao giờ xảy ra.
Kiểm thử thực sự đòi hỏi ý đồ đối kháng (adversarial intent). Bạn phải soạn thảo những câu hỏi được thiết kế để khiến AI thất bại. Bạn muốn nó vấp ngã trong phòng thí nghiệm để nó không vấp ngã trước mặt khách truy cập. Một bộ thử nghiệm chỉ xác nhận những gì bạn đã tin tưởng thì chỉ là một bản demo được tô vẽ. Nếu bạn không chủ động tạo ra các trường hợp biên (edge cases) và các câu hỏi bẫy, bạn không phải đang kiểm thử. Bạn đang hy vọng.
Hai sai lầm quan trọng
Prompting không phải là một sự đảm bảo. Một chỉ dẫn dài, chi tiết bảo AI đừng ảo giác chỉ là một lời gợi ý được ngụy trang dưới dạng mệnh lệnh. Mô hình có thể tuân theo hầu hết thời gian, nhưng nó sẽ phớt lờ chỉ dẫn ngay khoảnh khắc áp lực thống kê đẩy nó đi hướng khác. Temperature, xác suất token và hình thái của dữ liệu huấn luyện đều có trọng số lớn hơn một câu trong system prompt của bạn. Bạn phải đo lường sự tuân thủ bằng dữ liệu, chứ không phải bằng hy vọng. Một chỉ dẫn mạnh mẽ không phải là một sự thật đã được xác minh. Nó là một yêu cầu, và các yêu cầu có thể bị từ chối. Nếu toàn bộ chiến lược an toàn của bạn chỉ dựa vào việc viết prompt một cách cứng rắn, bạn đã xây dựng một rào chắn bằng giấy ăn. Bạn cần một hệ thống đánh giá để đếm xem mô hình tuân thủ bao nhiêu lần, trong điều kiện nào, và tại sao nó thất bại khi nó thất bại. Những con số không quan tâm đến tông giọng của bạn.
Vòng lặp đánh giá đã có sai sót. Đây là một cái bẫy tinh vi suýt chút nữa đã khiến tôi mắc sai lầm. Công cụ kiểm thử ban đầu của tôi đã thực hiện quy trình truy xuất hai lần. Lần chạy đầu tiên lấy ngữ cảnh để đối chiếu với dữ liệu chuẩn (ground truth). Lần chạy thứ hai lấy ngữ cảnh để phục vụ cho việc tạo câu trả lời thực tế. Trên thực tế, điều này có nghĩa là các phân đoạn (chunks) mà bộ đánh giá nhìn thấy có thể khác với các phân đoạn mà mô hình nhìn thấy. Bộ đánh giá đang chấm điểm câu trả lời dựa trên dữ liệu mà AI có thể chưa bao giờ nhận được. Một quy trình đánh giá chấm điểm dựa trên đầu vào sai lệch còn tệ hơn cả việc không đánh giá. Nó mang lại cho bạn một cảm giác an tâm giả tạo. Bạn nhìn vào điểm số, thấy tỷ lệ vượt qua cao và bắt đầu chủ quan. Trong khi đó, người dùng của bạn đang