Những thử nghiệm và sai sót khi thêm tính năng fact-check bằng AI vào một cộng đồng chính trị

Xin chào.
Tôi là lập trình viên từng giới thiệu khoảng 6 tháng trước về 'Uhheung', một dịch vụ tham gia của công dân giúp xem các dự luật dễ dàng hơn và để lại ý kiến.

Lần này, để thử giảm tin giả và các cuộc tranh luận tiêu hao trong cộng đồng, chúng tôi đã đưa vào tính năng fact-check bằng AI; tôi muốn chia sẻ những băn khoăn và các thử nghiệm kỹ thuật trong quá trình đó.

Ban đầu, cách tiếp cận rất đơn giản. Chúng tôi đưa văn bản mục tiêu vào và viết prompt kiểu "hãy kiểm chứng xem bài này có đúng sự thật không". Nhưng khi đưa lên dịch vụ thực tế, hàng loạt vấn đề ngoài dự đoán đã xuất hiện.

AI cố fact-check cả những 'ý kiến' đơn thuần của cá nhân như thể đó là sự thật, và dù không có căn cứ vẫn đưa ra kết luận nghe có vẻ hợp lý. Hơn nữa, nếu tác giả chỉnh sửa nội dung sau khi fact-check xong, sẽ xảy ra tình huống oái oăm là kết quả trở nên không còn khớp trước sau.

Cuối cùng, chúng tôi bỏ toàn bộ cấu trúc ban đầu và hiện vận hành với pipeline đã được chỉnh sửa khá nhiều như dưới đây.

1. Lọc đối tượng cần kiểm chứng (ý kiến vs sự thật)

Thay vì kiểm chứng toàn bộ bài viết cùng lúc, trước tiên chúng tôi chỉ trích xuất những 'khẳng định sự thật' có thể kiểm chứng một cách khách quan. Tức là bỏ qua các phán đoán giá trị như "chính sách này là tệ nhất", và chỉ nhắm tới những câu như "dự luật này tăng thuế 20%".
Để nắm bắt ngữ cảnh chính xác, chúng tôi không chỉ xem văn bản mục tiêu, mà còn gom cả bài viết gốc, bình luận cha, thậm chí cả ảnh đính kèm theo dạng multimodal để cung cấp context cho AI.

2. Buộc AI trả lời "không biết"

Đây là một trong những phần chúng tôi chú trọng nhất. Để ngăn hallucination đặc trưng của LLM, với những vấn đề thiếu căn cứ đáng tin cậy để kiểm chứng chéo hoặc không thể xác nhận, chúng tôi kiểm soát prompt rất chặt để AI không cố đưa ra kết luận mà phản hồi là 'không thể biết', 'tạm hoãn phán đoán'.

3. Lưu snapshot nguyên văn và cung cấp nguồn minh bạch

Để ngăn vấn đề tác giả sửa bài, chúng tôi giữ nguyên dữ liệu gốc tại thời điểm yêu cầu fact-check (snapshot). Khi người dùng khác xem kết quả, họ có thể kiểm tra minh bạch rằng "việc kiểm chứng dựa trên văn bản/hình ảnh nào, ở thời điểm nào" và "đã tham khảo những nguồn nào".

4. Xử lý traffic và tài nguyên

Vì quá trình gom toàn bộ ngữ cảnh và kiểm chứng như vậy khá nặng, chúng tôi cần quản lý hàng đợi người dùng. Do đó, mọi yêu cầu đều được đưa vào hàng đợi bất đồng bộ bằng Redis Cluster + BullMQ và được worker nền xử lý tuần tự.
Xét đến chi phí và tốc độ, chúng tôi dùng Gemini 3.5 Flash làm model chính, đồng thời áp dụng cấu trúc fallback sang Gemini 3.1 Pro khi tỷ lệ lỗi tăng hoặc suy luận phức tạp thất bại.
(Để ngăn các yêu cầu bừa bãi, chúng tôi cũng đặt giới hạn: miễn phí 1 lần mỗi ngày, sau đó trừ điểm trong ứng dụng.)

Những bài toán vẫn đang giải

Dù đã xây dựng logic phòng vệ theo cách của mình, vẫn còn nhiều trường hợp khó xử lý. Các trường hợp khác nhau về thời điểm chuẩn của thống kê, phát ngôn có ẩn dụ hoặc diễn giải đặc trưng của chính trị gia, hoặc bài viết dài trộn lẫn khéo léo giữa sự thật và giả dối thì vẫn khó xử lý hoàn hảo.

Bạn có thể trực tiếp thử trong ứng dụng Uhheung.
Nếu có bí quyết prompt để bắt hallucination tốt hơn trong loại logic kiểm chứng này, hoặc ý tưởng UX/UI giúp người dùng chấp nhận tốt hơn các kết quả mơ hồ, xin hãy thoải mái góp ý. Cảm ơn bạn đã đọc bài viết dài này!

Google Play: https://play.google.com/store/apps/details?id=kr.uhheung.app
App Store: https://apps.apple.com/kr/app/%EC%96%B4%ED%9D%A5/id6751951353