Cung cấp ngữ cảnh
Ba kỹ thuật buổi trước tác động vào cách mô hình suy luận. Phần này sang nửa còn lại: tác động vào ngữ cảnh và dữ liệu, buộc câu trả lời bám một nguồn cho trước hoặc nén thông tin lại cho cô đọng. Ta đi qua Data-Driven, Chain-of-Density, RAG cơ bản và prompt đa phương thức (đưa ảnh vào).
Vì sao mô hình không biết bối cảnh của bạn
Hãy bắt đầu từ một cảnh rất quen. Bạn hỏi trợ lý AI: "em nộp đồ án muộn hai ngày thì bị trừ bao nhiêu điểm?". Câu trả lời hiện ra rất trôi chảy, nói rằng thường bị trừ mười phần trăm mỗi ngày muộn. Bạn tin, rồi khi nộp mới biết môn đó không trừ điểm mà từ chối nhận bài luôn. Mô hình không nói dối bạn, nó chỉ trả lời một câu hỏi mà nó không có cách nào biết đáp án: quy định của một môn cụ thể, ở một trường cụ thể, trong một học kỳ cụ thể.
Đây là điểm mù cấu trúc chứ không phải lỗi nhất thời. Mô hình học từ một khối văn bản thu thập tới một thời điểm nào đó rồi dừng, và trong khối ấy không có đề cương môn của bạn, không có file dữ liệu đồ án bạn chạy tối qua, không có đoạn mã bạn đang gỡ lỗi. Mọi thứ riêng tư, mới, hoặc cục bộ đều nằm ngoài tầm với của nó. Hỏi về những thứ đó mà không đưa kèm gì, tức là bạn đang mời mô hình đoán, và nó sẽ đoán rất tự tin.
Chỗ này có một điểm nhiều bạn hiểu sai. Giọng văn chắc nịch không phải chỉ báo cho độ đúng: câu bịa và câu đúng được viết ra bằng cùng một giọng như nhau. Bạn hỏi thêm "chắc không?" mà nhận về "tôi rất chắc" thì cũng chẳng chứng minh được gì, vì nó đang sinh tiếp văn bản chứ không tra cứu lại kho sự thật nào cả. Liên quan trực tiếp là một phân biệt đáng nhớ: với lỗi nội tại, tức lỗi phát hiện được chỉ bằng cách đọc lại chính lập luận đó (một phép cộng sai, một bước mâu thuẫn với bước trước), mô hình tự rà khá tốt. Nhưng với lỗi cần nguồn ngoài, tự kiểm gần như vô ích: nó không thể tự biết hạn nộp là ngày 20 chứ không phải 25, rằng hàm thư viện kia đã đổi tên, rằng bài báo nó vừa trích dẫn không hề tồn tại. Muốn bắt loại lỗi này thì phải có dữ liệu thật. Cung cấp ngữ cảnh chính là cách bạn đặt dữ liệu thật vào tay mô hình trước khi nó kịp đoán.
Bốn loại ngữ cảnh nên đưa vào prompt
Ngữ cảnh gồm những gì? Trong việc học, có bốn loại phục vụ bốn mục đích khác nhau, và một prompt tốt thường có ít nhất hai trong bốn.
Dữ liệu vào là nguyên liệu để mô hình xử lý: đoạn quy chế, bảng kết quả thực nghiệm, thông báo lỗi, đoạn mã cần gỡ. Đây là loại dễ nhận ra nhất mà cũng bị quên nhiều nhất, vì trong đầu bạn nó quá hiển nhiên nên bạn tưởng mô hình cũng thấy.
Ràng buộc là giới hạn của bài toán mà bạn biết còn mô hình thì không: chỉ được dùng thư viện chuẩn, báo cáo không quá ba trang, nhóm đã chốt dùng Python, dữ liệu chỉ có 500 mẫu nên đừng đề xuất mạng nơ ron sâu. Thiếu ràng buộc, mô hình sẽ trả lời hoàn hảo cho một bài toán khác với bài toán bạn đang có.
Ví dụ mẫu cho thấy đầu ra bạn muốn trông thế nào. Đây chính là few-shot, nhưng nhìn dưới lăng kính ngữ cảnh thì rõ hơn: ví dụ là cách truyền đạt một tiêu chuẩn ngầm mà bạn không diễn tả nổi bằng lời. Khó mô tả "văn phong báo cáo của khoa mình", nhưng dán hai đoạn mẫu là mô hình bắt được ngay.
Tài liệu tham chiếu là nguồn chân lý để mô hình tra cứu và trích dẫn: quy chế, tài liệu thư viện lập trình, đề cương môn. Khác biệt với dữ liệu vào tuy tinh tế nhưng quan trọng: dữ liệu vào là thứ bạn muốn mô hình biến đổi, còn tài liệu tham chiếu là thứ bạn muốn mô hình tuân theo. Khi cả hai cùng có mặt, hãy tách bằng nhãn rõ ràng.
Trước khi gõ câu hỏi, tự hỏi: nếu tôi nhờ một người bạn cùng lớp làm việc này, tôi phải kể cho bạn ấy nghe những gì? Bạn ấy cần thấy tài liệu nào, biết ràng buộc nào, xem mẫu nào? Danh sách vừa liệt kê trong đầu chính là ngữ cảnh cần dán vào prompt. Mô hình còn ít bối cảnh hơn người bạn cùng lớp ấy nhiều, vì nó thậm chí không biết bạn đang học trường nào.
Data-Driven: neo câu trả lời vào dữ liệu dán kèm
Một lý do lớn khiến mô hình "bịa" (hallucination) là vì bạn hỏi về thứ nó không có trong tay, nên nó đoán. Cách chữa: dán kèm dữ liệu thật và yêu cầu mô hình chỉ dựa vào dữ liệu đó. Đây là kỹ thuật Data-Driven: neo câu trả lời vào dữ liệu cụ thể bạn cung cấp.
Công thức. [Dữ liệu dán kèm] cộng [Câu hỏi] cộng "chỉ dựa trên dữ liệu trên; thiếu
thì nói không tìm thấy".
Đưa nguồn (đoạn văn, bảng, log, mã) vào prompt rồi buộc mô hình chỉ dùng nguồn đó. Lệnh "thiếu thì nói không biết" là chốt chặn để mô hình không bịa khi thiếu dữ liệu.
Buộc mô hình trích dẫn chỗ lấy thông tin ("ghi rõ câu hoặc dòng nào ủng hộ kết luận"). Bạn kiểm tra được, và mô hình khó bịa hơn vì phải chỉ ra bằng chứng.
Ví dụ hỏi đáp dựa trên một đoạn quy chế thi:
DỮ LIỆU (quy chế thi):
"Sinh viên vắng quá 20% số tiết của học phần sẽ không được dự
thi kết thúc học phần. Đơn xin hoãn thi nộp trước ngày thi ít
nhất 3 ngày làm việc."
CÂU HỎI: Em vắng 25% số tiết thì có được thi không? Muốn hoãn
thi thì nộp đơn trước mấy ngày?
Chỉ trả lời dựa trên DỮ LIỆU trên. Trích đúng câu làm căn cứ.
Nếu dữ liệu không nói, hãy ghi "không có thông tin".
Mô hình trả lời bám sát: vắng 25 phần trăm (quá 20 phần trăm) nên không được thi; hoãn thi nộp trước ít nhất 3 ngày làm việc, kèm trích nguyên văn. Không có chỗ cho phỏng đoán.
Gần với sinh viên hơn, hãy dán bảng kết quả đồ án và bắt mô hình đọc đúng số:
DỮ LIỆU (kết quả thực nghiệm đồ án, độ chính xác %):
Mô hình | Tập huấn luyện | Tập kiểm tra
KNN | 92.0 | 78.5
Cây quyết định | 99.5 | 75.0
Hồi quy logit | 85.0 | 83.2
Dựa CHỈ trên bảng trên, hãy:
1. Chỉ ra mô hình nào tổng quát hoá tốt nhất và vì sao.
2. Mô hình nào có dấu hiệu quá khớp (overfitting)? Căn cứ số nào?
3. Mọi nhận xét phải dẫn đúng con số trong bảng.
Mô hình sẽ chỉ ra hồi quy logit tổng quát hoá tốt nhất (kiểm tra 83.2, sát huấn luyện 85.0), còn cây quyết định quá khớp (huấn luyện 99.5 nhưng kiểm tra chỉ 75.0). Vì đã neo vào bảng, nhận xét không trôi nổi mà gắn với số liệu, đúng thứ bạn cần viết vào báo cáo đồ án.
Chain-of-Density: tóm tắt lặp tăng mật độ
Khi tóm tắt một bài báo dài, mô hình thường cho bản tóm tắt an toàn: đúng nhưng loãng, toàn câu chung chung, thiếu chi tiết đắt. Chain-of-Density (viết tắt CoD, "chuỗi mật độ") khắc phục bằng cách tóm tắt nhiều vòng: mỗi vòng giữ nguyên độ dài nhưng nhồi thêm chi tiết quan trọng, làm bản tóm tắt ngày càng đậm thông tin.
Công thức. Tóm tắt vòng 1 (loãng), rồi tìm 1 đến 3 chi tiết quan trọng còn thiếu, rồi viết lại cùng độ dài nhưng thêm chi tiết đó (bỏ chữ thừa lấy chỗ), rồi lặp vài vòng.
Chain-of-Density không làm bản tóm tắt ngắn dần qua mỗi vòng. Độ dài giữ nguyên; chỉ có mật độ thông tin tăng: thay cụm từ rỗng bằng dữ kiện cụ thể (tên phương pháp, con số, kết quả). Thường lặp 3 đến 5 vòng là đủ đậm.
Ví dụ quy trình tóm tắt một bản tin:
Tóm tắt bản tin dưới đây theo phương pháp Chain-of-Density,
làm 3 vòng. Mỗi vòng khoảng 3 câu, GIỮ NGUYÊN độ dài:
- Vòng 1: tóm tắt chung, được phép còn mơ hồ.
- Vòng 2: thêm 1-2 chi tiết quan trọng còn thiếu (tên, số liệu),
bỏ bớt từ rỗng để bù chỗ.
- Vòng 3: thêm tiếp chi tiết, ưu tiên con số và kết quả cụ thể.
In ra cả ba vòng để thấy mức độ đậm dần.
[Dán bản tin vào đây]
Bạn thấy rõ vòng 1 chung chung, vòng 3 đậm đặc dữ kiện mà vẫn cùng độ dài. Đó là sức mạnh của CoD. Gần với sinh viên hơn, hãy dùng nó tóm tắt một bài báo khoa học khi làm tổng quan tài liệu:
Đây là phần tóm tắt và kết luận của một bài báo về phát hiện
xâm nhập mạng bằng học sâu. Hãy tóm tắt theo Chain-of-Density,
3 vòng, mỗi vòng đúng 4 câu, cùng độ dài:
Vòng 1: nêu bài toán và hướng tiếp cận (được phép chung chung).
Vòng 2: thêm tên mô hình, tập dữ liệu dùng để thử.
Vòng 3: thêm chỉ số kết quả (độ chính xác, F1) và hạn chế bài báo.
Cuối cùng, chỉ in bản vòng 3 để em đưa vào phần tổng quan.
[Dán abstract cộng conclusion vào đây]
Chain-of-Density cho bản tóm tắt đậm nhưng vẫn có thể nhầm số liệu nếu bài gốc dài. Hãy kết hợp Data-Driven: dán đúng đoạn gốc, buộc mọi con số khớp nguồn, tự đối chiếu trước khi nộp.
RAG cơ bản: tìm trước rồi mới dán
Kỹ thuật Data-Driven có một giới hạn: bạn phải tự dán dữ liệu vào prompt. Nhưng nếu tài liệu quá lớn (cả quyển quy chế, một giáo trình dày, hàng trăm trang ghi chú) thì dán hết là không thể, vì cửa sổ ngữ cảnh của mô hình có hạn. Cách làm khôn hơn: tìm trước vài đoạn liên quan đến câu hỏi, rồi chỉ dán những đoạn đó kèm câu hỏi. Đó chính là ý tưởng của RAG.
RAG (retrieval augmented generation, "sinh có truy hồi") trả lời câu hỏi trên một kho tài liệu lớn theo bốn bước: (1) tách nhỏ tài liệu thành nhiều đoạn; (2) tìm vài đoạn liên quan nhất đến câu hỏi; (3) dán các đoạn đó vào prompt; (4) hỏi mô hình, buộc nó trả lời dựa trên các đoạn vừa dán.
Hiểu ở mức trực giác: thay vì bắt mô hình nhớ cả quyển sách, ta làm như tra mục lục. Chỉ những đoạn trúng chủ đề mới được đưa vào prompt, kèm một lệnh kiểu Data-Driven "chỉ trả lời dựa trên các đoạn trên". Nhờ vậy mô hình vừa bám nguồn vừa không bị ngộp vì tài liệu thừa.
Bạn có thể tự làm một vòng RAG bằng tay. Quy chế đào tạo dài vài chục trang, bạn chỉ cần biết quy định về điểm rèn luyện:
Bước 1 (tự làm, không cần AI): mở file quy chế, dùng Ctrl+F tìm
"điểm rèn luyện", chép ra 2-3 đoạn có nhắc tới nó.
Bước 2: dán đúng các đoạn đó vào prompt rồi hỏi:
DỮ LIỆU (các đoạn trích từ quy chế về điểm rèn luyện):
[dán 2-3 đoạn vừa tìm]
CÂU HỎI: Điểm rèn luyện loại khá cần tối thiểu bao nhiêu điểm?
Bị trừ điểm trong trường hợp nào?
Chỉ trả lời dựa trên các đoạn trên. Trích đúng câu làm căn cứ.
Nếu các đoạn không nói, hãy ghi "không có thông tin".
Đây là RAG làm bằng tay: phần "tìm đoạn liên quan" do bạn làm bằng Ctrl+F, phần "trả lời
bám nguồn" do mô hình làm theo lối Data-Driven. Các công cụ RAG thật tự động hoá bước tìm
kiếm trên cả kho tài liệu, nhưng tinh thần vẫn y hệt: tìm trước, dán sau, rồi hỏi.
RAG không phải phép màu, chỉ là Data-Driven có thêm bước tìm kiếm phía trước. Khi tài liệu nhỏ, cứ dán thẳng. Khi tài liệu quá lớn, hãy tìm vài đoạn liên quan rồi mới dán.
Đưa hình ảnh vào prompt: prompt đa phương thức
Nhiều mô hình ngày nay không chỉ đọc chữ mà còn nhìn được ảnh: ta gọi đó là mô hình multimodal (đa phương thức). Với sinh viên, đây là một mẹo rất tiện: thay vì gõ lại một thông báo lỗi dài dòng hay vẽ lại một sơ đồ, bạn chỉ cần chụp màn hình rồi gửi kèm câu hỏi.
Vài thứ rất hợp để chụp gửi mô hình: thông báo lỗi khi chạy chương trình, sơ đồ (lưu đồ, sơ đồ lớp, biểu đồ kết quả), đề bài chụp từ sách hay slide, một đoạn mã trong ảnh chụp màn hình. Mô hình sẽ đọc nội dung trong ảnh rồi trả lời.
Đừng gửi mỗi ảnh trống rồi mong mô hình tự hiểu. Luôn kèm một câu mô tả rõ bạn muốn gì. Ví dụ: "đọc thông báo lỗi trong ảnh này và giải thích nguyên nhân, rồi chỉ cách sửa", hay "đây là sơ đồ lớp của đồ án, hãy chỉ chỗ thiết kế chưa hợp lý". Ảnh cung cấp dữ liệu, còn câu chữ mới nói cho mô hình biết phải làm gì với dữ liệu đó.
Ngữ cảnh dài không đồng nghĩa với ngữ cảnh tốt
Hiểu xong giá trị của ngữ cảnh, phản xạ đầu tiên của nhiều bạn là dán thật nhiều: cả file mã, cả quyển quy chế, cứ đưa vào cho chắc. Đây là sai lầm phải nói thẳng, vì nó thường làm câu trả lời tệ đi chứ không tốt lên, vì ba lý do.
Thứ nhất là loãng tín hiệu: dán ba mươi trang mà chỉ nửa trang liên quan thì phần thừa không đứng yên vô hại, nó cạnh tranh sự chú ý và kéo câu trả lời về những chủ đề nổi bật trong đống tài liệu thừa. Thứ hai là nhiễu mâu thuẫn: tài liệu dài hay chứa nhiều phiên bản của cùng một quy định (bản cũ, bản sửa đổi, phụ lục ngoại lệ), dán tất mà không nói bản nào có hiệu lực là mời mô hình chọn bừa. Thứ ba là chi phí và độ trễ: mỗi lượt hỏi chậm hơn và tốn hơn, và khi bạn lặp một prompt hàng chục lần để thử nghiệm thì chỗ lãng phí này cộng dồn rất nhanh.
Nguyên tắc thực dụng: đủ và đúng, chứ không nhiều. Ngữ cảnh lý tưởng là tập nhỏ nhất đủ để một người thông minh nhưng chưa biết gì về bối cảnh của bạn trả lời đúng câu hỏi. Nếu bỏ một đoạn ra mà câu trả lời vẫn đúng, đoạn đó không cần có mặt.
Chọn phần nào của tài liệu để đưa vào
Quy trình bốn bước, không cần công cụ gì ngoài chức năng tìm kiếm trong trình đọc văn bản.
Bước một, viết câu hỏi trước rồi mới chọn ngữ cảnh. Nghe ngược đời nhưng đây là mấu chốt: khi chưa rõ mình hỏi gì, bạn không có tiêu chí nào để lọc nên sẽ dán tất. Câu hỏi rõ thì tiêu chí lọc hiện ra ngay.
Bước hai, rút từ khoá từ chính câu hỏi rồi tìm trong tài liệu. Hỏi về điểm rèn luyện thì từ khoá là "rèn luyện", "xếp loại", "trừ điểm". Mỗi lần tìm thấy, chép ra đoạn đó kèm câu trước và câu sau, vì một quy định hay bị chia đôi giữa hai câu.
Bước ba, giữ nguyên văn, đừng tóm tắt trước khi dán. Tự tóm tắt cho gọn là bạn đã cài một lớp diễn giải của mình vào nguồn; nếu bạn hiểu sai thì mô hình sẽ trả lời sai theo mà không cách nào phát hiện. Nguồn nguyên vẹn thì việc trích dẫn mới có nghĩa.
Bước bốn, gắn nhãn từng khối bằng những dòng viết hoa như DỮ LIỆU:, CÂU HỎI:,
RÀNG BUỘC:. Nhãn giúp mô hình không nhầm một câu trong tài liệu thành mệnh lệnh của bạn, và
giúp chính bạn rà xem còn thiếu khối nào.
Prompt yếu và prompt mạnh: phân tích hai ví dụ
Cặp thứ nhất, hỏi về quy định của môn học. Bản yếu:
Cho em hỏi nộp đồ án muộn có bị trừ điểm không?
Câu này thiếu tất cả bốn loại ngữ cảnh: không có tài liệu tham chiếu, không có dữ liệu vào, không có ràng buộc, không có mẫu. Mô hình buộc phải trả lời bằng một quy định trung bình hoá gom từ vô số trường học trên thế giới, và nó sẽ trả lời rất mượt. Bạn nhận về một con số nghe hợp lý mà không có giá trị nào cho trường hợp của bạn. Bản mạnh:
DỮ LIỆU (trích đề cương môn Trí tuệ nhân tạo, mục Đánh giá):
"Đồ án nộp sau hạn không được chấm. Trường hợp có lý do chính
đáng, sinh viên nộp đơn xin gia hạn trước hạn nộp ít nhất 2
ngày, kèm minh chứng."
CÂU HỎI: Em nộp muộn 2 ngày thì bị trừ bao nhiêu điểm? Có cách
nào cứu vãn không?
RÀNG BUỘC: Chỉ dựa trên DỮ LIỆU trên. Trích đúng câu làm căn cứ.
Nếu dữ liệu không nói, hãy ghi "không có thông tin".
Điểm đáng chú ý: câu hỏi của sinh viên ẩn chứa một giả định sai, rằng nộp muộn thì bị trừ điểm. Nhờ bị neo vào nguồn, mô hình sẽ bác luôn giả định đó và chỉ ra rằng đề cương không hề nói tới trừ điểm mà nói là không được chấm, đồng thời trích đúng câu quy định về gia hạn. Đây là giá trị mà một prompt tay không không bao giờ có: ngữ cảnh không chỉ giúp trả lời đúng, nó còn giúp sửa câu hỏi sai của bạn.
Cặp thứ hai, nhờ gỡ lỗi mã. Bản yếu:
Code của em bị lỗi, sửa giúp em với.
Không mã, không thông báo lỗi, không nói ngôn ngữ hay bối cảnh. Mô hình sẽ hỏi lại, hoặc tệ hơn là đoán ra một đoạn mã giả định rồi sửa cái đoạn nó tự bịa. Bản mạnh:
DỮ LIỆU (đoạn mã Python và thông báo lỗi khi chạy):
[dán đúng hàm gây lỗi, khoảng 20 dòng]
[dán nguyên văn traceback, không cắt bớt]
RÀNG BUỘC:
- Bài tập môn Cấu trúc dữ liệu, chỉ được dùng thư viện chuẩn.
- Không đổi chữ ký hàm vì bộ chấm tự động gọi đúng tên đó.
CÂU HỎI: Nguyên nhân lỗi là gì? Đề xuất bản sửa tối thiểu, chỉ
rõ dòng nào đổi. Nếu cần thêm thông tin để chắc chắn, hãy hỏi
lại thay vì đoán.
Hãy đếm: bản mạnh có dữ liệu vào (mã và traceback nguyên văn), có ràng buộc (thư viện chuẩn, giữ chữ ký hàm), có yêu cầu đầu ra rõ (bản sửa tối thiểu, chỉ rõ dòng), và có một van an toàn (hỏi lại thay vì đoán). Bốn thứ đó biến một lời cầu cứu mơ hồ thành một yêu cầu mà mô hình có thể làm đúng ngay lần đầu.
- Tóm tắt nguồn trước khi dán. Bạn vô tình cài lỗi hiểu của mình vào nguồn, rồi phần trích dẫn của mô hình sẽ trích lại chính cái lỗi ấy.
- Dán tất cho chắc. Ngữ cảnh thừa làm loãng tín hiệu và kéo câu trả lời lệch chủ đề.
- Quên van "không có thông tin". Không có câu này, mô hình gặp chỗ nguồn không nói sẽ điền vào bằng kiến thức chung, và bạn không phân biệt nổi đâu là nguồn đâu là suy đoán.
- Không tách nhãn dữ liệu và câu hỏi. Một câu mệnh lệnh nằm trong tài liệu có thể bị hiểu là yêu cầu của bạn.
- Coi lời tự tin của mô hình là bằng chứng. Hỏi "bạn chắc chứ" rồi nhận về "tôi rất chắc" thì không kiểm chứng được gì. Chỉ có đối chiếu với nguồn mới là kiểm chứng.
- Dán ảnh trống không kèm yêu cầu. Ảnh là dữ liệu, câu chữ mới là nhiệm vụ.
Kỹ thuật nào cho việc nào
Năm kỹ thuật của buổi này không loại trừ nhau; nhiều khi bạn kết hợp (ví dụ Data-Driven cộng Chain-of-Density để tóm tắt một nguồn cho trước). Bảng dưới giúp bạn chọn nhanh điểm khởi đầu.
| Kỹ thuật | Khi nào dùng | Ví dụ học tập |
|---|---|---|
| Chain-of-Thought | Bài nhiều bước, cần lập luận tuần tự | Giải bài quy hoạch động, suy luận logic, gỡ lỗi từng bước |
| Atom-of-Thoughts | Bài lớn gồm nhiều phần ít liên quan nhau | Chia nhỏ một đồ án, tách mô-đun, lập kế hoạch làm việc |
| Few-shot | Cần đúng định dạng, văn phong, cách phân loại | Sinh chú thích theo khuôn, phân loại, định dạng dữ liệu |
| Data-Driven | Câu trả lời phải bám một nguồn cụ thể | Hỏi đáp trên quy chế, đọc bảng kết quả đồ án, tra tài liệu |
| Chain-of-Density | Tóm tắt cô đọng, không mất ý chính | Tóm tắt bài báo, viết phần tổng quan, rút gọn báo cáo |
Một cách nhớ ngắn: nhiều bước thì dùng CoT; nhiều phần thì dùng AoT; cần đúng khuôn thì dùng Few-shot; phải bám nguồn thì dùng Data-Driven; phải cô đọng thì dùng Chain-of-Density. Nguyên tắc: bắt đầu bằng một kỹ thuật chính hợp với loại việc, chạy thử, rồi thêm kỹ thuật phụ nếu kết quả còn thiếu. Đừng nhồi cả năm kỹ thuật vào một prompt ngay từ đầu.
Luyện tập
Bài tập 1: chữa một prompt thiếu ngữ cảnh
Đề bài. Một bạn gõ prompt sau và than rằng câu trả lời chung chung, toàn lời khuyên sách vở, không dùng được cho báo cáo đồ án:
Mô hình của em chạy không tốt lắm, làm sao cải thiện độ chính xác?
Hãy chỉ ra prompt này thiếu những loại ngữ cảnh nào, rồi viết lại bản mạnh.
Lời giải. Prompt thiếu cả bốn loại: không dữ liệu vào (mô hình gì, độ chính xác bao nhiêu), không ràng buộc (được dùng thư viện nào), không tài liệu tham chiếu (yêu cầu của đề bài), không ví dụ mẫu. Thiếu hết thì mô hình chỉ còn cách nhả ra lời khuyên phổ quát kiểu "thêm dữ liệu, tinh chỉnh siêu tham số", đúng nhưng vô dụng. Bản viết lại:
DỮ LIỆU (kết quả hiện tại, độ chính xác %):
Mô hình | Huấn luyện | Kiểm tra
Cây quyết định | 99.1 | 71.4
Tập dữ liệu: 900 mẫu, 12 đặc trưng, 2 lớp, tỷ lệ lớp 50/50.
RÀNG BUỘC:
- Đồ án môn Học máy, chỉ được dùng scikit-learn.
- Phải giữ mô hình dạng cây để còn giải thích được.
CÂU HỎI: Dựa CHỈ trên số liệu trên, hãy chỉ ra vấn đề chính của
mô hình, căn cứ vào con số nào, và đề xuất 3 hướng xử lý phù hợp
với ràng buộc. Nếu cần thêm số liệu để kết luận, hãy nói rõ cần
số nào thay vì đoán.
Bản mới neo vào số thật, nên mô hình sẽ chỉ ra dấu hiệu quá khớp (huấn luyện 99.1 nhưng kiểm tra chỉ 71.4), và ba hướng xử lý sẽ nằm trong phạm vi cây và scikit-learn thay vì khuyên bạn đổi sang mạng nơ ron.
Bài tập 2: tự làm một vòng RAG bằng tay
Đề bài. Bạn cần biết trường có cho học cải thiện điểm hay không, điều kiện thế nào. Quy chế đào tạo dài 40 trang. Hãy mô tả các bước bạn làm và viết prompt cuối cùng.
Lời giải. Bước 1, viết câu hỏi trước: "được học cải thiện trong trường hợp nào, điểm nào được ghi vào bảng điểm?". Bước 2, rút từ khoá: "cải thiện", "học lại", "điểm cao nhất". Bước 3, mở file quy chế, tìm ba từ khoá đó, chép ra nguyên văn các đoạn có chứa chúng kèm câu trước và câu sau. Bước 4, dán các đoạn đã gắn nhãn kèm câu hỏi và van an toàn:
DỮ LIỆU (các đoạn trích nguyên văn từ quy chế đào tạo):
[đoạn 1 tìm theo từ khoá "cải thiện"]
[đoạn 2 tìm theo từ khoá "học lại"]
[đoạn 3 tìm theo từ khoá "điểm cao nhất"]
CÂU HỎI: Sinh viên được đăng ký học cải thiện trong trường hợp
nào? Nếu học cải thiện, điểm nào được dùng để tính điểm trung
bình tích luỹ?
RÀNG BUỘC: Chỉ trả lời dựa trên các đoạn trên. Mỗi kết luận phải
trích đúng câu làm căn cứ. Nếu các đoạn không nói tới, ghi rõ
"không có thông tin", đừng suy đoán theo quy chế trường khác.
Điểm cần rút ra: bạn vừa tự làm bước tìm của RAG bằng Ctrl+F, còn bước bám nguồn do mô
hình làm theo lối Data-Driven. Nếu bỏ van "không có thông tin", mô hình rất dễ điền vào chỗ
trống bằng quy định của một trường nào đó nó từng đọc, và bạn sẽ không phân biệt được.
Tự kiểm
- 1Vì sao yêu cầu mô hình "suy nghĩ từng bước" lại tăng độ chính xác cho bài nhiều bước?
- 2Atom-of-Thoughts khác Chain-of-Thought ở điểm nào?
- 3Đặc trưng đúng của Chain-of-Density là gì?
- 4Kỹ thuật Data-Driven dùng để làm gì?
- 5RAG về bản chất là gì?
Tóm tắt buổi
Mô hình không biết bối cảnh riêng của bạn, và giọng tự tin của nó không phải bằng chứng cho độ đúng. Nó tự bắt được lỗi nội tại nhưng mù trước lỗi cần nguồn ngoài, nên cách chữa gốc là đưa nguồn vào ngay từ đầu. Ngữ cảnh có bốn loại: dữ liệu vào để xử lý, ràng buộc để giới hạn bài toán, ví dụ mẫu để truyền tiêu chuẩn ngầm, tài liệu tham chiếu để mô hình tuân theo và trích dẫn. Data-Driven neo câu trả lời vào nguồn dán kèm cộng van "không có thông tin"; Chain-of-Density tăng mật độ tóm tắt qua nhiều vòng cùng độ dài; RAG chỉ là Data-Driven có thêm bước tìm đoạn liên quan phía trước; prompt đa phương thức cho phép thay việc gõ lại bằng một ảnh chụp kèm yêu cầu rõ ràng. Cuối cùng, ngữ cảnh phải đủ và đúng chứ không phải càng nhiều càng tốt: chọn đoạn theo câu hỏi, giữ nguyên văn, gắn nhãn từng khối.
Hết buổi 2. Bạn đã có năm kỹ thuật cốt lõi: ba để suy luận và hai để cung cấp ngữ cảnh, cộng RAG cơ bản và mẹo đưa ảnh vào prompt. Buổi sau ta gói chúng lại thành quy trình dựng prompt chuyên nghiệp.