Vũ Mạnh Tuấn
← Tất cả bài viết
AI9 phút đọc

Series Bên trong một LLM · Bài 4/5

Ảo giác, trí nhớ và vì sao mô hình cần công cụ

Tham số là trí nhớ dài hạn đã mờ, cửa sổ ngữ cảnh là trí nhớ làm việc. Hiểu chỗ này rồi mình mới biết khi nào nên đưa tài liệu vào thay vì hỏi chay.

Cảnh này chắc ai demo sản phẩm AI cũng gặp một lần. Khách hỏi về một cái tên lạ hoắc, mô hình trả lời trơn tru như đúng rồi, còn thêm vài chi tiết nghe rất hợp lý.

Năm phút sau cả phòng phát hiện nó bịa. Không ai cười nổi.

Nó bịa vì nó lịch sự quá mức

Nghe hơi buồn cười nhưng đúng là vậy.

Trong dữ liệu huấn luyện, câu trả lời mẫu của con người thường vừa đúng vừa có giọng tự tin. Mô hình học đúng cái giọng đó. Tới lúc gặp câu ngoài khả năng, nó vẫn giữ nguyên phong độ tự tin, rồi đoán.

Nhớ lại: ở chế độ mặc định, nó chỉ là bộ máy rút thăm token kế tiếp. Nó không tự đi tra tài liệu. Mà trong dữ liệu, câu kiểu "Ai là X" thường có câu trả lời mạch lạc, nên nó cứ mạch lạc tiếp, kể cả khi không biết gì.

Cách dạy nó nói "mình không biết"

Cách làm là thêm vào dữ liệu huấn luyện những trường hợp mà câu trả lời đúng chính là lời từ chối.

Nhưng làm sao biết lúc nào nó không biết để gắn nhãn? Người ta kiểm tra bằng thực nghiệm:

  1. Lấy một đoạn văn, sinh ra vài câu hỏi chi tiết dựa trên chính đoạn đó
  2. Hỏi mô hình nhiều lần
  3. Trả lời khớp và nhất quán thì tạm coi là nó biết
  4. Trả lời lung tung thì thêm một hội thoại mẫu vào dữ liệu, với câu trả lời là "mình không biết"

Lặp lại cho nhiều chủ đề, mô hình dần học được mối liên hệ giữa cảm giác bất định bên trong và hành vi từ chối bên ngoài.

Ví dụ gần nghề: bạn làm chatbot chăm sóc khách. Chính sách hoàn tiền vừa cập nhật mà chưa nạp vào, nó sẽ trả lời theo quán tính chính sách cũ. Dạy nó rằng không thấy chính sách trong ngữ cảnh thì nói "mình không có thông tin này" sẽ an toàn hơn nhiều.

Phần dưới mình dựa vào chương về ảo giác và trí nhớ trong bài giảng của Andrej Karpathy. Video đầy đủ ở cuối bài.

Hai loại trí nhớ, đừng lẫn lộn

Đây là ý mình thấy hữu dụng nhất trong cả bài giảng.

Bản chấtVí dụDùng khi nào
Trong tham sốKý ức dài hạn, đã mờ, gom từ thứ nó đọc rất lâu trướcKiến thức phổ thôngCâu hỏi chung chung, không đòi chi tiết cập nhật
Cửa sổ ngữ cảnhTrí nhớ làm việc, rõ ràng, ngay trước mắtBạn dán nguyên văn PRD, điều khoản, số liệuCần chính xác thì đưa tài liệu vào đây

Hệ quả rất thực tế: muốn nó trả lời đúng về một tài liệu thì đưa tài liệu đó vào prompt. Giống người thôi, đọc lại ngay trước khi tóm tắt vẫn hơn nhớ mang máng.

Hai ví dụ đời thường:

  • Tóm tắt chương 3 của PRD. Chỉ bảo "tóm tắt chương 3" thì nó dựa vào ký ức mập mờ về các PRD từng thấy, ra kết quả chung chung. Dán nguyên văn chương 3 vào thì chất lượng khác hẳn.
  • Trả lời chính sách hoàn tiền. Đừng hỏi trống không. Dán đoạn chính sách vào rồi bảo nó giải thích trên chính văn bản đó kèm dẫn chứng. Nó không cần nhớ, chỉ cần trích.
Hai nguồn mô hình dựa vào để trả lờimang máng, dễ bịarõ ràng, kiểm chứng đượcTham số mô hìnhtrí nhớ dài hạn, đã mờthứ đọc được lúc pretrainingNgữ cảnh và công cụtrí nhớ làm việc, ngay trước mắtCâu trả lời
Muốn câu trả lời chính xác về một tài liệu thì đưa tài liệu vào ngữ cảnh, đừng trông vào trí nhớ trong tham số.

Vì sao mô hình cần công cụ

Công cụ giải hai chuyện cùng lúc:

  1. Chuyển thông tin từ trí nhớ mờ sang trí nhớ làm việc
  2. Chuyển việc tính toán sang thứ tính đúng

Cơ chế đại khái thế này: thay vì sinh thẳng câu trả lời, mô hình sinh ra mấy token đặc biệt để yêu cầu một thao tác, ví dụ tìm kiếm. Hệ thống thấy vậy thì tạm dừng, chạy lệnh, lấy kết quả nhét lại vào cửa sổ ngữ cảnh. Rồi mô hình viết tiếp, giờ đã có dữ liệu vừa tra ngay trước mắt.

Để nó biết dùng đúng lúc, người ta huấn luyện bằng các hội thoại mẫu cho thấy khi nào nên dùng, đặt truy vấn ra sao, trích dẫn thế nào.

Chạy code cũng là một công cụ. Cần tính toán thì thay vì nhẩm, nó viết vài dòng mã, hệ thống chạy rồi trả kết quả về. Phần dễ lỗi được chuyển từ mạng nơ ron sang bộ thông dịch, vốn đáng tin hơn nhiều.

Ví dụ: tính phí vận chuyển theo bảng nhiều bậc. Bảo nó dùng code, nó viết vài dòng để nội suy và cộng phí. Bạn còn đọc lại được đoạn mã, nên con số cuối đáng tin hơn hẳn.

Nó không có tự nhận thức

Hỏi "bạn là ai, ai xây ra bạn" nghe vui nhưng không có mấy ý nghĩa.

Mỗi phiên trò chuyện là một lần khởi động mới: xử lý token rồi kết thúc. Không có bản ngã nào tồn tại liên tục. Không lập trình trước thì nó sẽ đoán danh tính của mình dựa vào thói quen trong dữ liệu, và bịa là chuyện bình thường.

Hai cách định danh có kiểm soát:

  • Chèn sẵn mấy hội thoại huấn luyện kiểu "Hãy giới thiệu về bạn", với câu trả lời đúng là phần mô tả bạn muốn nó lặp lại
  • Thêm một thông điệp hệ thống ở đầu cuộc trò chuyện: "bạn là trợ lý X, nhiệm vụ Y, giới hạn kiến thức Z"

Cả hai đều là quy ước mình đặt ra, không phải nó tự soi vào bên trong.

Nó cần token để suy nghĩ

Mỗi token sinh ra chỉ đi qua một lượng tính toán hữu hạn. Không thể đòi nó làm xong cả bài toán phức tạp trong đúng một lần nhảy.

Nên ép nó ra đáp số ngay ở token đầu tiên là rất rủi ro. Cho nó sinh các bước trung gian thì an toàn hơn nhiều. Đây là lý do kỹ thuật, không phải mẹo tâm lý.

Cùng một bài, hai cách hỏi:

Cách 1, ép đáp số ngay:
Em mua 3 quả táo và 2 quả cam. Mỗi quả cam giá 2. Tổng cộng 13.
Hãy trả lời ngay giá mỗi quả táo, chỉ một con số.

Cách 2, cho phép suy nghĩ:
Em mua 3 quả táo và 2 quả cam. Mỗi quả cam giá 2. Tổng cộng 13.
Hãy giải từng bước rồi kết luận giá mỗi quả táo.
  • Cách 1: nó phải nhồi toàn bộ phép suy luận vào đúng lúc sinh ra con số. Số nhỏ thì có thể trúng, phức tạp thêm chút là sai.
  • Cách 2: nó tách ra từng bước. Tính tiền cam, trừ ra tiền táo, chia cho số táo. Mỗi bước một ít tính toán, tổng thể đáng tin hơn.

Hệ quả thú vị: nó đếm rất kém khi bị ép ra số ngay. Đếm ký tự, đếm dấu chấm, đếm mục trong danh sách đều vậy. Cho nó dùng công cụ đi. Đếm là việc của công cụ, không phải của mạng nơ ron.

Cùng một bài toán, hai cách hỏi cho hai lượng tính toán khác nhauBắt đáp số ngaymọi phép tính dồn vào một bướcđáp sốdễ saiCho trình bàytừng bướcbước 1bước 2bước 3bước 4đáp sốđúng hơn hẳn
Mỗi token sinh ra chỉ mang theo một lượng tính toán hữu hạn. Trải lời giải ra nhiều bước là cách chia nhỏ gánh nặng đó.

Đưa ba ý này vào thiết kế sản phẩm

  • Luôn đưa nguồn chính xác vào ngữ cảnh. RAG, file đính kèm, trích đoạn. Đừng trông vào trí nhớ tham số khi cần chính xác.
  • Cho phép nó từ chối. Không biết thì nói không biết, đừng ép trả lời bằng mọi giá.
  • Bật công cụ và khuyến khích dùng. Tìm kiếm khi thiếu thông tin, viết code khi cần tính, ghi lại kết quả để kiểm chứng được.
  • Viết prompt để nó được suy nghĩ qua nhiều token. Bài toán logic hay số học thì bắt trình bày từng bước.
  • Luôn có thông điệp hệ thống mô tả danh tính, phạm vi, giới hạn. Đừng để nó tự bịa về chính nó ở chỗ quan trọng.

Hai ví dụ đóng gói:

  • Hỗ trợ khách ngành du lịch: khách hỏi "tour X hủy trước 7 ngày có hoàn tiền không". Prompt tốt sẽ kèm trích đoạn điều khoản, bắt mô hình trích dẫn đúng dòng quyết định. Thiếu điều khoản thì cho nó tìm nội bộ. Vẫn không có thì trả lời "mình không có thông tin này" rồi tạo ticket chuyển người thật.
  • Ứng dụng quản trị bán hàng: quản lý hỏi biên lợi nhuận tháng trước của nhóm A. Cho nó chạy code trên bảng doanh thu và chi phí, xuất ra phép tính chi tiết. Đừng bắt nó nhẩm.

Tóm lại

  • Ảo giác phần lớn đến từ việc mô hình bắt chước giọng tự tin. Dạy nó nói "mình không biết" đúng lúc là giảm hẳn.
  • Trí nhớ tham số thì mờ, trí nhớ trong ngữ cảnh thì rõ. Cần chính xác thì đưa tài liệu vào.
  • Công cụ vừa mang thông tin mới vào, vừa chuyển tính toán sang thứ đáng tin hơn
  • Nó không có tự nhận thức. Danh tính đến từ dữ liệu huấn luyện hoặc thông điệp hệ thống.
  • Mỗi token chỉ chứa được một ít tính toán. Cho nó trình bày từng bước, hoặc cho dùng công cụ.
  • LLM
  • Hallucination
  • AI