Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Prompt debugging là cách tìm nguyên nhân một câu trả lời AI không đạt yêu cầu bằng cách giữ lại ca lỗi, nêu điều mong đợi, thay đổi từng phần nhỏ của prompt rồi kiểm lại. Mục tiêu không phải viết prompt thật kêu; mục tiêu là biết phần nào đã làm output lệch.

Đọc xong, bạn sẽ hiểu:

  • Cách ghi một test case để không sửa prompt theo cảm giác.
  • Bốn chỗ thường làm output hỏng: nhiệm vụ, context, khuôn đầu ra và tiêu chí.
  • Cách thử một thay đổi nhỏ rồi giữ hoặc bỏ nó bằng rubric.

1. Prompt debugging bắt đầu từ ca lỗi cụ thể

a. Đừng viết lại prompt từ đầu

Bạn hỏi AI: “Tóm tắt phản hồi khách hàng này.” Nó trả lời rất trơn tru nhưng lại bỏ mất việc khách đang không đăng nhập được. Nhiều người sẽ thêm thật nhiều câu mệnh lệnh, đổi vai trò, rồi đổi luôn format. Làm vậy có thể tình cờ tốt hơn, nhưng bạn không biết vì sao.

Debug nghĩa là tìm nguyên nhân của một kết quả sai bằng cách kiểm từng phần. Trước hết, giữ nguyên ca lỗi: prompt đã gửi, đoạn dữ liệu đã đưa, output nhận được và điều bạn muốn nhận. Nó giống giữ hóa đơn trước khi gọi nơi bán hàng: không có hóa đơn thì khó chỉ ra sai ở dòng nào.

b. Viết điều mong đợi có thể kiểm

“Tóm tắt hay hơn” không đủ để kiểm. Với ca giả lập trên, điều mong đợi có thể là:

  • Nêu đúng ba vấn đề: không đăng nhập, bị trừ tiền hai lần, chờ phản hồi quá lâu.
  • Không thêm nguyên nhân chưa có trong phản hồi.
  • Trả ra ba bullet, mỗi bullet tối đa 20 từ.

Danh sách này là rubric: tiêu chí chấm output đạt hay chưa. Rubric không làm AI biết thêm dữ kiện. Nó giúp bạn và hệ thống nhìn cùng một mục tiêu.

Hình 1 — Giữ lại ca lỗi giúp lần sửa sau có chỗ đối chiếu.

c. Sai output chưa chắc do prompt

Nếu đoạn phản hồi ban đầu không nói khách bị trừ tiền hai lần, AI không có cơ sở để tự biết. Ép “hãy chính xác hơn” không biến dữ liệu thiếu thành dữ liệu có thật. Khi thiếu nguồn, lựa chọn đúng là bổ sung nguồn đáng tin hoặc ghi rõ chưa đủ thông tin để kết luận.

Đây là chỗ cần dừng. AI có thể viết câu nghe tự tin, nhưng câu nghe tự tin không phải bằng chứng.

2. Bốn nơi output thường hỏng

a. Nhiệm vụ chưa nói rõ việc phải làm

“Phân tích phản hồi” có thể là tóm tắt, phân loại, đề xuất câu trả lời hoặc tìm lỗi. Hãy bắt đầu bằng động từ cụ thể: “Liệt kê ba vấn đề được nêu trực tiếp.” Đừng vừa muốn tóm tắt, vừa muốn phán đoán nguyên nhân, vừa muốn viết email trong một lượt nếu bạn chưa có rubric cho từng việc.

b. Context thiếu, thừa hoặc lẫn nguồn

Context là thông tin model được nhận để làm nhiệm vụ. Context thiếu làm output phải đoán. Context quá dài hoặc lẫn ghi chú cũ làm ý quan trọng bị chìm. Hãy đưa đúng phần cần xử lý, ghi rõ nguồn nào là chính, và không dán dữ liệu khách hàng thật hoặc thông tin riêng tư vào chatbot công khai.

c. Khuôn đầu ra không đủ chặt

Ở bài trước, bạn đã thấy JSON chỉ hữu ích khi có key và giá trị mong muốn. Câu “trả JSON” vẫn mơ hồ. Với người đọc, Markdown ba bullet dễ xem. Với chương trình, bạn có thể yêu cầu ba trường issue, evidence, confidence, và nói rõ: nếu không có bằng chứng thì trả null, không đoán.

d. Tiêu chí đúng chưa tồn tại

Một output có thể đúng nội dung nhưng quá dài; cũng có thể đúng format nhưng bịa một chi tiết. Vì vậy, tách tiêu chí thành: đủ ý, không thêm ý, đúng format và trong giới hạn độ dài. Các nhà cung cấp model đều khuyến nghị dùng eval — chạy các test case theo tiêu chí lặp lại — khi cần đo hành vi ổn định hơn qua các lần thay đổi. OpenAI Evals

Hình 2 — Gọi đúng chỗ hỏng trước khi sửa câu chữ.

3. Sửa một biến mỗi lượt

a. Viết giả thuyết trước khi sửa

Ví dụ: “Output bỏ ý không đăng nhập vì prompt không yêu cầu giữ mọi vấn đề được nêu trực tiếp.” Đây là giả thuyết có thể thử. Thay đúng một dòng: “Liệt kê mọi vấn đề được nêu trực tiếp; không gộp các vấn đề khác nhau.”

Sau đó chạy lại cùng input và chấm bằng rubric cũ. Nếu đủ ba ý nhưng xuất hiện suy đoán mới, sửa tiếp tiêu chí “không thêm nguyên nhân”. Đừng đồng thời đổi model, thêm năm ví dụ và chuyển JSON; nếu output đổi, bạn sẽ không biết biến nào tạo ra thay đổi.

Nó giống chỉnh lò nướng: vừa đổi nhiệt, thời gian và khuôn thì bánh hỏng cũng không biết lỗi do đâu.

b. So bản cũ với bản mới

Lưu Prompt A, Prompt B và kết quả tương ứng. Regression là lỗi cũ quay lại sau một thay đổi. Nếu Prompt B giữ được ý đăng nhập nhưng bỗng mất ý trừ tiền hai lần, B chưa thắng A.

Hành vi prompt có thể đổi khi model hoặc phiên bản thay đổi. Với tác vụ quan trọng, lưu test case, rubric, model/version và output mẫu; đừng chỉ dựa vào một lần chạy đẹp. OpenAI về tính thay đổi hành vi model

c. Khi nào không nên sửa prompt nữa

Dừng và kiểm lại khi:

  • Dữ liệu đầu vào mâu thuẫn hoặc thiếu nguồn.
  • Rubric không nói rõ thế nào là đạt.
  • Nhiệm vụ cần quyết định có hậu quả cho khách hàng, tiền, pháp lý hoặc sức khỏe.
  • Ba lần sửa nhỏ vẫn cho kết quả lẫn lộn.

Lúc đó, thu hẹp nhiệm vụ, nhờ người có trách nhiệm xem lại dữ liệu, hoặc xây test case tốt hơn. Prompt không thay thế kiểm tra của con người.

4. Checklist debug prompt gọn mà đủ

a. Sáu bước mỗi lần gặp output lệch

  1. Lưu input, prompt, output và ngày chạy.
  2. Viết điều mong đợi thành 3-5 dòng có thể chấm.
  3. Gọi tên một nơi nghi hỏng: nhiệm vụ, context, format hoặc tiêu chí.
  4. Nêu một giả thuyết ngắn.
  5. Chỉ đổi một phần nhỏ rồi chạy lại cùng input.
  6. So rubric, giữ thay đổi có ích và ghi lỗi cũ chưa được phép quay lại.

Không có câu “prompt hoàn hảo”. Có prompt phù hợp với một nhiệm vụ và test case hiện có. Khi nhiệm vụ đổi, prompt cần kiểm lại.

Hình 3 — Một thay đổi mỗi lượt tạo bằng chứng rõ hơn.

b. Mẫu đối chiếu đã điền

Tiêu chí Prompt A Prompt B
Đủ ba vấn đề Bỏ “không đăng nhập” Đủ ba vấn đề
Không thêm nguyên nhân Đạt Đạt
Ba bullet, tối đa 20 từ Đạt Đạt

Mẫu này không chứng minh B đúng cho mọi dữ liệu. Nó chỉ nói B tốt hơn A trên ca lỗi đang kiểm.

5. Bài tập 15 phút: debug bản tóm tắt giả lập

a. Chuẩn bị dữ liệu không nhạy cảm

Dùng chatbot miễn phí và đoạn giả lập: “Tôi không vào được tài khoản từ sáng. Thẻ cũng bị trừ hai lần. Tôi đã gửi form hôm qua nhưng chưa ai trả lời.” Đừng dùng email, số điện thoại hay phản hồi thật của khách hàng.

b. Chạy hai lượt có kiểm soát

Lượt A: “Tóm tắt phản hồi.” Ghi output. Lượt B chỉ thêm: “Liệt kê mọi vấn đề được nêu trực tiếp thành ba bullet; không suy đoán nguyên nhân.” Chấm cả hai bằng bảng ở mục 4.

Nếu B vẫn bỏ ý, đừng thêm một đoạn prompt dài. Hãy kiểm lại liệu input có đủ rõ không, rồi thử một giả thuyết khác. Bài tập nhằm luyện cách quan sát, không phải tìm câu thần chú.

Mẫu đối chiếu

Tiêu chí Lượt A Lượt B
Đủ ba vấn đề Bỏ lỗi đăng nhập Đủ ba vấn đề
Không đoán nguyên nhân Đạt Đạt
Ba bullet ngắn Đạt Đạt

6. Tổng kết

a. Năm ý chính

  • Prompt debugging bắt đầu bằng một ca lỗi có input, output và điều mong đợi rõ ràng.
  • Rubric biến chữ “hay hơn” thành tiêu chí có thể kiểm.
  • Lỗi thường nằm ở nhiệm vụ, context, khuôn đầu ra hoặc tiêu chí đúng.
  • Sửa một biến mỗi lượt mới biết thay đổi nào thực sự giúp.
  • Khi dữ liệu thiếu hoặc hậu quả lớn, dừng để bổ sung nguồn và kiểm tra bởi con người.

b. Câu hỏi tự kiểm tra

  • Vì sao không nên viết lại toàn bộ prompt khi chỉ có một output sai?
  • Bốn nơi nào cần kiểm khi câu trả lời lệch yêu cầu?
  • Nếu input không có dữ kiện cần kết luận, bạn nên làm gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Vì đổi nhiều thứ cùng lúc làm bạn không biết thay đổi nào tạo hiệu quả. → xem mục 1 và mục 3.

Xem gợi ý câu 2

Kiểm nhiệm vụ, context, khuôn đầu ra và tiêu chí đúng. → xem mục 2.

Xem gợi ý câu 3

Bổ sung nguồn đáng tin hoặc dừng, không ép AI đoán. → xem mục 1 và mục 3.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Debug Tìm nguyên nhân của kết quả sai bằng cách kiểm từng phần.
Test case Một tình huống cụ thể gồm input và kết quả mong đợi.
Context Thông tin model nhận để làm nhiệm vụ.
Rubric Danh sách tiêu chí chấm output đạt hay chưa.
Regression Lỗi cũ quay lại sau một thay đổi.
Eval Chạy test case theo cùng tiêu chí để đo output.

e. Nguồn tham khảo

Sau bài Structured Output, bạn đã có khuôn để kiểm đầu ra. Bài tiếp theo, Những lỗi Prompt phổ biến, sẽ gom các lỗi hay gặp trước khi đi tới framework 80/20.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Không dùng output AI một mình để ra quyết định tiền bạc hoặc thay thế kiểm tra chuyên môn.