Bốn thành phần và công thức RTF

Đã hiểu vì sao cần nói rõ, giờ ta cần một bộ khung để biết nói rõ những gì. Khung đầu tiên, đơn giản và dùng được ngay, là bốn thành phần cơ bản (basic components). Một prompt đầy đủ thường gồm bốn phần, không nhất thiết đủ cả bốn trong mọi tình huống, nhưng càng đủ thì kết quả càng đáng tin.

Hãy bắt đầu từ một cảnh quen thuộc. Đêm trước hạn nộp, bạn gõ vào ô chat: "làm đồ án quản lý thư viện". Mô hình trả về một dàn ý chung chung, không ngôn ngữ nào cụ thể, không biết bạn đang mắc ở đâu. Sau hai mươi phút bạn kết luận "AI cũng thường thôi" rồi tự làm. Chẩn đoán rất đơn giản: mô hình không dở, lời nhắc mới dở. Bạn đưa cho nó bốn chữ và chờ nó biết bạn học môn gì, dùng ngôn ngữ nào, thầy yêu cầu ra sao. Bài này cho bạn một bộ khung để chuyển cái nằm trong đầu thành chữ trên màn hình, một cách có hệ thống.

Thử ngay: prompt yếu và prompt mạnh cho cùng một việc

Trước khi vào bộ khung, hãy nhìn khoảng cách nó tạo ra trên một tình huống cụ thể: nhờ AI giải thích con trỏ trong C. Đây là chỗ sinh viên hay bí, và cũng là chỗ một prompt cẩu thả cho kết quả vô dụng. Bấm từng nút bên dưới để thấy prompt mạnh đã nói rõ thêm những gì mà prompt yếu để mô hình phải đoán.

Prompt yếu

giải thích con trỏ

Thiếu gần như mọi thứ: con trỏ ngôn ngữ nào, người đọc trình độ nào, ngắn hay sâu, có cần ví dụ không.

Prompt mạnh

# role
Bạn là trợ giảng môn Lập trình C, giảng cho sinh viên năm nhất
lần đầu gặp khái niệm con trỏ. Giọng kiên nhẫn, tránh thuật ngữ
tiếng Anh nâng cao; nếu buộc phải dùng thì giải thích ngay.

# task
Giải thích con trỏ trong C: nó lưu cái gì, vì sao cần nó, và sự
khác nhau giữa biến thường với con trỏ tới biến đó. Dùng phép so
sánh "địa chỉ nhà" để minh hoạ.

# format
Trả về theo thứ tự:
1) một đoạn 3 đến 4 câu giải thích ý chính;
2) một sơ đồ bộ nhớ đơn giản bằng chữ (ô nhớ + địa chỉ + giá trị);
3) một đoạn code C khoảng 8 dòng, chú thích trong code bằng tiếng Anh;
4) một lỗi thường gặp của người mới và cách tránh.

Thành phần:

So hai bản viết bằng số: đếm, khoảng cách sửa, độ trùng từ vựng

Chuẩn hoá chữ hoa và dấu câuHệ số ước lượng token2 ký tự mỗi token2,5 ký tự mỗi token3 ký tự mỗi token3,5 ký tự mỗi token4 ký tự mỗi token

khoảng cách 133 phép

Bản trước khi sửa✎ sửa đượcgiải thích con trỏBản sau khi sửa✎ sửa được# role Bạn là trợ giảng môn Lập trình C, giảng cho sinh viên năm nhất lần đầu gặp khái niệm con trỏ. Giọng kiên nhẫn, tránh thuật ngữ tiếng Anh nâng cao; nếu buộc phải dùng thì giải thích ngay. # task Giải thích con trỏ trong C: nó lưu cái gì, vì sao cần nó, và sự khác nhau giữa biến thường với con trỏ tới biến đó. Dùng phép so sánh "địa chỉ nhà" để minh hoạ. # format Trả về theo thứ tự: 1) một đoạn 3 đến 4 câu giải thích ý chính; 2) một sơ đồ bộ nhớ đơn giản bằng chữ (ô nhớ + địa chỉ + giá trị); 3) một đoạn code C khoảng 8 dòng, chú thích trong code bằng tiếng Anh; 4) một lỗi thường gặp của người mới và cách tránh.

1 · Đếm hai bản, và chênh lệch

Đại lượng	Bản trước	Bản sau	Chênh tuyệt đối	Chênh phần trăm
Ký tựtính theo điểm mã, sau khi gộp khoảng trắng	18	589	+571	+3.172%
Từtách theo khoảng trắng, tiếng Việt thì mỗi âm tiết là một từ	4	137	+133	+3.325%
Câucắt tại dấu . ! ? … hoặc chỗ xuống dòng	1	16	+15	+1.500%
Từ riêng biệtcỡ tập từ mà độ trùng bên dưới dùng	4	104	+100	+2.500%
Token (ước lượng)ceil(số ký tự / 3)	6	197	+191	+3.183%

Cột chênh phần trăm lấy bản trước làm gốc: (sau - trước) / trước. Khi bản trước bằng 0 thì phép chia không có kết quả, nên sim ghi không xác định chứ không in số 0. Dòng token là ước lượng theo quy tắc công khai ceil(ký tự / hệ số), không phải bộ tách token thật: mỗi mô hình tách khác nhau, nên hệ số là một núm sửa được ở thanh công cụ, và đổi hệ số làm hai con số token đổi theo.

2 · Khoảng cách chỉnh sửa ở mức từ

Số phép sửa ít nhất133thay 0, chèn 133, xoá 0, giữ nguyên 4

Chia cho bản dài hơn (137 từ)0,971133 / 137, bằng 0 khi và chỉ khi hai bản trùng khít

Hai bản có trùng khítkhông ✕so trên văn bản đã chuẩn hoá, nên bật công tắc chuẩn hoá có thể biến hai bản khác nhau thành trùng khít

Dãy phép biến đổi (137 bước, đọc từ trái sang phải)giữ nguyên 4thay 0chèn 133xoá 0

+ role+ bạn+ là+ trợ+ giảng+ môn+ lập+ trình+ c+ giảng+ cho+ sinh+ viên+ năm+ nhất+ lần+ đầu+ gặp+ khái+ niệm+ con+ trỏ+ giọng+ kiên+ nhẫn+ tránh+ thuật+ ngữ+ tiếng+ anh+ nâng+ cao+ nếu+ buộc+ phải+ dùng+ thì+ giải+ thích+ ngay+ taskgiảithích+ con+ trỏ+ trong+ c+ nó+ lưu+ cái+ gì+ vì+ sao+ cần+ nó+ và+ sự+ khác+ nhau+ giữa+ biến+ thường+ vớicontrỏ+ tới+ biến+ đó+ dùng+ phép+ so+ sánh+ địa+ chỉ+ nhà+ để+ minh+ hoạ+ format+ trả+ về+ theo+ thứ+ tự+ 1+ một+ đoạn+ 3+ đến+ 4+ câu+ giải+ thích+ ý+ chính+ 2+ một+ sơ+ đồ+ bộ+ nhớ+ đơn+ giản+ bằng+ chữ+ ô+ nhớ+ địa+ chỉ+ giá+ trị+ 3+ một+ đoạn+ code+ c+ khoảng+ 8+ dòng+ chú+ thích+ trong+ code+ bằng+ tiếng+ anh+ 4+ một+ lỗi+ thường+ gặp+ của+ người+ mới+ và+ cách+ tránh

Bảng quy hoạch động (5 × 138 = 690 ô). Hàng là bản trước, cột là bản sau.

	ε	role	bạn	là	trợ	giảng	môn	lập	trình	c	giảng	cho	sinh	viên	năm	nhất	lần	đầu	gặp	khái	niệm	con	trỏ	giọng	kiên	nhẫn	tránh	thuật	ngữ	tiếng	anh	nâng	cao	nếu	buộc	phải	dùng	thì	giải	thích	ngay	task	giải	thích	con	trỏ	trong	c	nó	lưu	cái	gì	vì	sao	cần	nó	và	sự	khác	nhau	giữa	biến	thường	với	con	trỏ	tới	biến	đó	dùng	phép	so	sánh	địa	chỉ	nhà	để	minh	hoạ	format	trả	về	theo	thứ	tự	1	một	đoạn	3	đến	4	câu	giải	thích	ý	chính	2	một	sơ	đồ	bộ	nhớ	đơn	giản	bằng	chữ	ô	nhớ	địa	chỉ	giá	trị	3	một	đoạn	code	c	khoảng	8	dòng	chú	thích	trong	code	bằng	tiếng	anh	4	một	lỗi	thường	gặp	của	người	mới	và	cách	tránh
ε	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	39	40	41	42	43	44	45	46	47	48	49	50	51	52	53	54	55	56	57	58	59	60	61	62	63	64	65	66	67	68	69	70	71	72	73	74	75	76	77	78	79	80	81	82	83	84	85	86	87	88	89	90	91	92	93	94	95	96	97	98	99	100	101	102	103	104	105	106	107	108	109	110	111	112	113	114	115	116	117	118	119	120	121	122	123	124	125	126	127	128	129	130	131	132	133	134	135	136	137
giải	1	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	37	38	39	40	41	42	43	44	45	46	47	48	49	50	51	52	53	54	55	56	57	58	59	60	61	62	63	64	65	66	67	68	69	70	71	72	73	74	75	76	77	78	79	80	81	82	83	84	85	86	87	88	89	90	91	92	93	94	95	96	97	98	99	100	101	102	103	104	105	106	107	108	109	110	111	112	113	114	115	116	117	118	119	120	121	122	123	124	125	126	127	128	129	130	131	132	133	134	135	136
thích	2	2	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	37	38	39	40	41	42	43	44	45	46	47	48	49	50	51	52	53	54	55	56	57	58	59	60	61	62	63	64	65	66	67	68	69	70	71	72	73	74	75	76	77	78	79	80	81	82	83	84	85	86	87	88	89	90	91	92	93	94	95	96	97	98	99	100	101	102	103	104	105	106	107	108	109	110	111	112	113	114	115	116	117	118	119	120	121	122	123	124	125	126	127	128	129	130	131	132	133	134	135
con	3	3	3	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	38	39	40	41	41	42	43	44	45	46	47	48	49	50	51	52	53	54	55	56	57	58	59	60	61	62	63	64	65	66	67	68	69	70	71	72	73	74	75	76	77	78	79	80	81	82	83	84	85	86	87	88	89	90	91	92	93	94	95	96	97	98	99	100	101	102	103	104	105	106	107	108	109	110	111	112	113	114	115	116	117	118	119	120	121	122	123	124	125	126	127	128	129	130	131	132	133	134
trỏ	4	4	4	4	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38	39	40	41	42	41	42	43	44	45	46	47	48	49	50	51	52	53	54	55	56	57	58	59	60	61	62	63	64	65	66	67	68	69	70	71	72	73	74	75	76	77	78	79	80	81	82	83	84	85	86	87	88	89	90	91	92	93	94	95	96	97	98	99	100	101	102	103	104	105	106	107	108	109	110	111	112	113	114	115	116	117	118	119	120	121	122	123	124	125	126	127	128	129	130	131	132	133

Ô (4, 137) = 133 · so trỏ của bản trước với tránh của bản sau

• Thay (đường chéo): ô (3, 136) + 1 = 134
• Chèn (từ bên trái): ô (4, 136) + 1 = 133
• Xoá (từ bên trên): ô (3, 137) + 1 = 135

Khi hai ứng viên bằng nhau, sim ưu tiên đường chéo, rồi xoá, rồi chèn. Quy ước phá hoà đổi dãy phép sửa được kể lại, không đổi khoảng cách.

3 · Độ trùng từ vựng kiểu Jaccard

Trên tập từ đơn

số từ có ở cả hai bản, chia cho số từ xuất hiện ở ít nhất một bản

0,038 (3,8%)

giao 4 trên hợp 104, tức 4 / 104

chỉ ở bản trước 0

chỉ ở bản sau 100 12348anhbiếnbuộcbạnbằngbộccaochochínhchúchỉchữcodecáchcáicâucầncủacòn 76 nữa

Trên tập cặp từ liền nhau

mỗi phần tử là hai từ đứng cạnh nhau, nên trật tự từ có ảnh hưởng

0,023 (2,3%)

giao 3 trên hợp 129, tức 3 / 129

chỉ ở bản trước 0

chỉ ở bản sau 126 1 một2 một3 một3 đến4 câu4 một8 dònganh 4anh nângbiến thườngbiến đóbuộc phảibạn làbằng chữbằng tiếngbộ nhớc giảngc khoảngc nócao nếucho sinhchính 2chú thíchchỉ giácòn 102 nữa

Hai con số này thường lệch nhau, và chỗ lệch mới là bài học. Cùng một tập từ nhưng xếp lại trật tự thì độ trùng từ đơn không đổi trong khi độ trùng cặp từ tụt: bấm cặp mẫu Đổi trật tự từ để thấy 1 đứng cạnh 9/11. Chiều ngược lại cũng xảy ra thật: cặp mẫu Ca ngược trực giác cho 6/7 ở từ đơn nhưng 8/9 ở cặp từ, vì từ lặp làm tập từ đơn co lại nhiều hơn tập cặp từ. Vì vậy sim không khẳng định con nào luôn nhỏ hơn con nào. Cả hai đều là phép đếm trên tập hợp, nên một từ xuất hiện năm lần cũng chỉ tính một lần.

4 · Văn bản sau chuẩn hoá, tức đúng thứ mọi con số trên đang đếm

Công tắc đang bật. Bật thì sim hạ chữ hoa thành chữ thường và bỏ dấu câu, tắt thì giữ nguyên. Cả hai chế độ đều gộp mọi khoảng trắng liền nhau thành một dấu cách và đều chuẩn hoá Unicode về dạng NFC, nên chữ có dấu gõ kiểu tổ hợp và kiểu dựng sẵn được đếm như nhau. Sim không bao giờ bỏ dấu thanh của tiếng Việt: chuẩn hoá vẫn giữ nguyên chữ tôi thành tôi, không biến nó thành toi, vì bỏ dấu thanh sẽ trộn lẫn những từ khác nghĩa hẳn.

Bản trước · 18 ký tự · 4 từgiải thích con trỏ

Bản sau · 589 ký tự · 137 từrole bạn là trợ giảng môn lập trình c giảng cho sinh viên năm nhất lần đầu gặp khái niệm con trỏ giọng kiên nhẫn tránh thuật ngữ tiếng anh nâng cao nếu buộc phải dùng thì giải thích ngay task giải thích con trỏ trong c nó lưu cái gì vì sao cần nó và sự khác nhau giữa biến thường với con trỏ tới biến đó dùng phép so sánh địa chỉ nhà để minh hoạ format trả về theo thứ tự 1 một đoạn 3 đến 4 câu giải thích ý chính 2 một sơ đồ bộ nhớ đơn giản bằng chữ ô nhớ địa chỉ giá trị 3 một đoạn code c khoảng 8 dòng chú thích trong code bằng tiếng anh 4 một lỗi thường gặp của người mới và cách tránh

Sáu cặp trên là văn bản minh hoạ do người soạn bài viết ra để chốt từng mốc số học, không phải ngữ liệu công bố hay số liệu đo từ mô hình thật.

Sửa cả hai ô văn bản rồi nhìn mọi con số tính lại. Sim đo khác biệt giữa hai bản: nó không chấm bản nào hay hơn, vì đó là nhận định chứ không phải phép tính. Bấm Đổi trật tự từ để thấy độ trùng từ đơn đứng nguyên ở 1 trong khi độ trùng cặp từ tụt xuống 9/11, và bấm Ca ngược trực giác để thấy độ trùng cặp từ có thể CAO hơn độ trùng từ đơn, nên đừng nhớ theo kiểu cặp từ luôn khắt khe hơn.

Khối tính ngay dưới khung so sánh đo khác biệt giữa hai bản bằng số. Nó cố tình không chấm bản nào hay hơn: đó là nhận định, không phải phép tính, và không cổng kiểm nào canh được một nhận định. Ở trạng thái mở bài, với công tắc chuẩn hoá đang bật, sim đếm được bản trước 18 ký tự và 4 từ, bản sau 589 ký tự và 137 từ; cột chênh phần trăm ghi số từ tăng +3.325%. Khoảng cách chỉnh sửa theo từ là 133 phép, gồm 133 phép chèn, 0 phép thay và 0 phép xoá: bốn từ của bản yếu còn nguyên trong bản mạnh, phần chênh lệch toàn là chữ thêm vào. Độ trùng từ đơn 4/104, còn độ trùng cặp từ 3/129.

Cùng một mô hình, cùng chủ đề, nhưng lời nhắc thứ hai khoá chặt vai trò, trình độ người đọc, phép so sánh cụ thể và cấu trúc đầu ra. Kết quả gần như chắc chắn dùng được ngay, không phải hỏi đi hỏi lại.

Bạn để ý: prompt mạnh không hề "thông minh" hơn, nó chỉ nói rõ hơn. Toàn bộ phần thêm vào đều là những điều bạn vốn đã ngầm mong đợi; điểm khác biệt là bạn đã viết chúng ra thay vì bắt mô hình đoán.

Bốn thành phần cơ bản

1. Chỉ dẫn (instruction): việc bạn muốn mô hình làm. Đây là phần bắt buộc.
2. Ngữ cảnh (context): thông tin nền giúp mô hình trả lời đúng tình huống của bạn (bạn là ai, dùng để làm gì, ràng buộc gì).
3. Dữ liệu vào (input data): đối tượng cụ thể cần xử lý (đoạn code, thông báo lỗi, văn bản cần tóm tắt).
4. Chỉ báo định dạng đầu ra (output indicator): bạn muốn câu trả lời trông như thế nào (gạch đầu dòng, bảng, đoạn văn ngắn, đoạn code có chú thích).

Bốn mảnh này ghép lại thành một lời nhắc hoàn chỉnh rồi đi qua mô hình để ra kết quả. Hãy xem chúng hoạt động trên một việc rất quen thuộc: nhờ AI tóm tắt một đoạn mô tả thuật toán.

# instruction
Tóm tắt đoạn mô tả thuật toán dưới đây.

# context
Người đọc là sinh viên năm hai mới học cấu trúc dữ liệu,
chưa quen thuật ngữ tiếng Anh nâng cao.

# input data
"""
Thuật toán sắp xếp nổi bọt duyệt qua mảng nhiều lượt, mỗi lượt
so sánh từng cặp phần tử kề nhau và đổi chỗ nếu chúng sai thứ tự,
cho tới khi không còn cặp nào cần đổi.
"""

# output indicator
Trả về 3 gạch đầu dòng ngắn, mỗi dòng tối đa 20 từ,
bằng tiếng Việt đơn giản.

Bốn nhãn trong ví dụ chỉ để bạn thấy ranh giới giữa các phần. Khi đã quen, bạn không cần ghi rõ nhãn; chỉ cần đảm bảo bốn loại thông tin đó đều có mặt.

Hai phần hay bị bỏ quên nhất

Đó là ngữ cảnh và chỉ báo định dạng.

• Thiếu ngữ cảnh: mô hình trả lời cho "người chung chung".
• Thiếu định dạng: nhận về đoạn văn dài, lại mất công cắt gọt.

Thêm hai phần này gần như luôn cải thiện kết quả.

Đi sâu từng thành phần

Chỉ dẫn hay bị viết hỏng theo một kiểu kín đáo: mơ hồ mà tưởng là đã rõ. "Về sắp xếp nổi bọt" không phải chỉ dẫn, đó là chủ đề. "Nói về sắp xếp nổi bọt" có động từ, nhưng không giới hạn gì, bạn sẽ nhận về một bài lan man. "So sánh sắp xếp nổi bọt với sắp xếp chèn theo số phép so sánh và số phép đổi chỗ, trên mảng đã gần sắp xếp" mới là chỉ dẫn: một động từ rõ, một phạm vi rõ, một điều kiện rõ. Mẹo tự kiểm: đọc lại và hỏi "có bao nhiêu cách hiểu?". Nếu nhiều hơn một, hãy chốt lại.

Ngữ cảnh trả lời câu hỏi "việc này làm cho ai". Cùng yêu cầu "giải thích đệ quy", câu trả lời phải rất khác nhau tùy bạn là sinh viên năm nhất chưa biết ngăn xếp hay bạn đang ôn phỏng vấn. Mô hình không đoán được bạn thuộc nhóm nào nên nó rơi vào mức trung bình, tức là không hợp với ai cả. Ngữ cảnh nên gồm trình độ, mục đích, ràng buộc bắt buộc (đề cấm đệ quy, chỉ được dùng thư viện chuẩn), và cái bạn đã thử mà thất bại.

Dữ liệu vào là phần hay bị bỏ nhất: sinh viên tả lỗi bằng lời ("hàm của em chạy sai") thay vì dán hàm và thông báo lỗi. Khi dán, hãy rào dữ liệu bằng ranh giới rõ để mô hình không nhầm nội dung dữ liệu thành mệnh lệnh.

Chỉ báo định dạng rẻ nhất để viết mà tiết kiệm nhiều công nhất. Một dòng "trả về bảng ba cột: tên hàm, việc nó làm, độ phức tạp" giúp bạn khỏi ngồi cắt gọt một đoạn văn dài. Nên nêu cả hình thức, độ dài lẫn ngôn ngữ, vì cả ba đều là chỗ mô hình hay tự quyết.

Khi nào cần thành phần nào

• Việc nhanh, quen thuộc, tự kiểm được ngay (đổi định dạng, sửa chính tả): chỉ dẫn là đủ.
• Việc có một đối tượng cụ thể (gỡ lỗi, tóm tắt, viết lại): bắt buộc thêm dữ liệu vào.
• Việc mà đúng sai phụ thuộc người đọc hoặc ràng buộc môn học: bắt buộc thêm ngữ cảnh.
• Kết quả dán thẳng vào báo cáo, slide hoặc code: bắt buộc thêm chỉ báo định dạng.

Thiếu thành phần nào thì hỏng theo kiểu nào

Biết bốn thành phần là một chuyện, nhận ra mình đang thiếu cái nào lại là chuyện khác. May là mỗi thành phần khi vắng mặt đều để lại một dấu vết riêng.

Thiếu chỉ dẫn thì câu trả lời lan man theo chủ đề. Bạn gõ "vòng lặp trong C" và nhận về một bài tổng quan có đủ mọi thứ trừ cái bạn cần: đọc xong thấy đúng hết mà chẳng dùng được gì. Bạn đưa một chủ đề chứ không đưa một việc, nên mô hình tự chọn việc, và nó chọn cái phổ biến nhất.

Thiếu ngữ cảnh thì câu trả lời đúng nhưng lệch người đọc và lệch ràng buộc: mô hình dùng thuật ngữ bạn chưa học, gợi ý thư viện mà đề bài cấm, hoặc bày lại đúng cách bạn vừa thử và đã thất bại. Đây là loại thiếu tốn thời gian nhất, vì phải đọc hết rồi mới biết không dùng được.

Thiếu dữ liệu vào thì mô hình phải đoán đối tượng. Dấu vết dễ nhận nhất là câu phòng thủ kiểu "nếu code của bạn có dạng như sau", theo sau là một đoạn code nó tự nghĩ ra rồi phân tích chính đoạn ấy. Nó đang gỡ lỗi một chương trình tưởng tượng.

Thiếu chỉ báo định dạng thì bạn nhận đúng nội dung nhưng sai bao bì: một đoạn văn dài có mở bài kết bài, trong khi bạn chỉ cần ba dòng dán thẳng vào slide. Thiệt hại nằm ở công cắt gọt, mà công đó phải trả lại mỗi lần dùng.

Bốn dấu vết này biến việc sửa prompt từ mò mẫm thành có phương pháp: đọc câu trả lời hỏng, nhận dạng dấu vết, bổ sung đúng thành phần đang thiếu, chạy lại.

Thứ tự đặt các thành phần

Không có luật cứng, nhưng một thứ tự chạy tốt trong đa số trường hợp là: vai trò và ngữ cảnh trước, chỉ dẫn kế tiếp, dữ liệu vào ở giữa, chỉ báo định dạng ở cuối.

Lý do nằm ở cách mô hình sinh chữ. Nó đọc toàn bộ lời nhắc rồi mới viết, và những gì đặt ở đầu khoá giọng cho mọi thứ đọc sau đó: đặt "bạn đang giảng cho sinh viên năm nhất" ở dòng đầu thì cả phần dữ liệu phía dưới cũng được đọc dưới lăng kính ấy. Ngược lại, chỉ báo định dạng nên nằm sát cuối vì đó là thứ cuối cùng mô hình đọc trước khi viết, nên ít bị bỏ sót nhất.

Với lời nhắc dài, hãy rào dữ liệu vào bằng ranh giới rõ ràng, chẳng hạn ba dấu nháy, và nói rõ đó là dữ liệu chứ không phải mệnh lệnh: nếu đoạn bạn dán tình cờ có câu mệnh lệnh, mô hình rất dễ hiểu nhầm đó là yêu cầu của bạn. Với lời nhắc rất dài, nhắc lại yêu cầu then chốt ngay sau khối dữ liệu, vì một dòng nhắc lại rẻ hơn nhiều so với một lượt hỏi lại.

Công thức RTF: vai trò, nhiệm vụ, định dạng

Bốn thành phần là khung đầy đủ nhưng đôi khi hơi dài cho những việc nhanh. Có một công thức gọn hơn, dễ nhớ hơn, rất hợp để bắt đầu: công thức RTF, viết tắt của ba từ tiếng Anh Role, Task, Format.

• Vai trò (Role): bảo mô hình "đóng vai" ai. Ví dụ: một giảng viên lập trình kiên nhẫn, một người rà soát code khó tính.
• Nhiệm vụ (Task): nói rõ việc cần làm và làm cho ai, kèm ràng buộc nếu có.
• Định dạng (Format): nêu hình thức đầu ra mong muốn.

Vì sao gán vai trò lại hữu ích? Nhớ lại trò đoán chữ tiếp theo. Khi bạn mở đầu bằng "Bạn là một giảng viên lập trình kiên nhẫn", bạn đang kéo mô hình về vùng văn bản mang giọng giảng dạy, chậm rãi, có ví dụ. Vai trò không phải phép thuật; nó là một cách ngắn gọn để đặt giọng và mức độ chi tiết cho toàn bộ câu trả lời.

RTF và bốn thành phần không mâu thuẫn nhau. RTF là một cách sắp gọn: "vai trò" gói phần lớn ngữ cảnh, "nhiệm vụ" chính là chỉ dẫn cộng dữ liệu vào, "định dạng" chính là chỉ báo đầu ra. Bạn dùng RTF cho yêu cầu nhanh, dùng bốn thành phần khi việc phức tạp và cần tách bạch dữ liệu.

Ví dụ thứ hai: nhờ AI gỡ một lỗi

Ví dụ con trỏ ở trên là việc giải thích. Hãy thử việc bạn làm nhiều nhất: gỡ lỗi. Đa số sinh viên gửi đi một lời nhắc kiểu "code em bị lỗi, xem giúp với", trong khi mô hình không có code, không có lỗi, không biết ngôn ngữ. Đây là bản đủ bốn thành phần.

# chỉ dẫn
Tìm nguyên nhân khiến hàm dưới đây lặp vô hạn và chỉ ra dòng gây lỗi.
Đừng viết lại cả chương trình.

# ngữ cảnh
Tôi là sinh viên năm nhất, môn Lập trình C, đề bài cấm dùng thư viện
ngoài. Tôi đã thử đổi điều kiện while thành i <= n nhưng vẫn treo.

# dữ liệu vào
"""
int tong(int n) {
    int i = 1, s = 0;
    while (i <= n) {
        s += i;
    }
    return s;
}
"""

# định dạng
Trả về đúng ba phần:
1) một câu nêu nguyên nhân;
2) dòng code cần sửa và bản sửa;
3) một mẹo để lần sau tự phát hiện loại lỗi này.

Mỗi thành phần mua về cho bạn một thứ. Chỉ dẫn "đừng viết lại cả chương trình" chặn thói quen quăng ra một bản code mới toanh mà bạn không hiểu. Ngữ cảnh "đề cấm thư viện ngoài" chặn những gợi ý bạn không được phép dùng, còn "tôi đã thử đổi điều kiện while" chặn việc mô hình gợi ý lại đúng cái bạn vừa thử. Dữ liệu vào cho nó thứ duy nhất có thể phân tích.

Điểm mấu chốt: bản mạnh không dài hơn vì màu mè. Mỗi câu thêm vào đều loại bỏ một cách hiểu sai. Viết prompt tốt về bản chất là thu hẹp không gian câu trả lời cho tới khi chỉ còn lại thứ bạn thật sự cần.

Nói cái muốn, đừng chỉ nói cái không muốn

Có một chi tiết nhỏ nhưng đổi kết quả rất nhiều: ràng buộc phủ định thường yếu hơn ràng buộc khẳng định. Câu "đừng viết dài dòng" hoạt động kém hơn hẳn câu "viết tối đa năm câu"; "đừng dùng thuật ngữ khó" kém hơn "chỉ dùng từ mà sinh viên năm nhất đã học".

Vì sao? Mô hình sinh chữ bằng cách nối tiếp những gì đang có, mà một câu cấm vẫn phải nêu ra chính cái bị cấm. Khi bạn viết "đừng nhắc tới đệ quy", chữ "đệ quy" nằm chình ình trong ngữ cảnh và kéo mô hình về đúng vùng văn bản nói về đệ quy. Câu cấm chỉ ra vùng cần tránh nhưng không chỉ cho mô hình biết đi đâu, trong khi nó bắt buộc phải đi đâu đó. Ràng buộc khẳng định vừa loại bỏ cái sai vừa chỉ luôn cái đúng.

Vậy nên hãy tập phản xạ dịch: mỗi khi định viết một câu cấm, hỏi "nếu không làm thế thì làm gì?" rồi viết câu trả lời đó ra. "Đừng viết code dài" dịch thành "chỉ đưa phần cần sửa, tối đa mười dòng". Câu cấm không vô dụng, và vài câu rất đáng giữ, chẳng hạn "không suy đoán thông tin ngoài tài liệu tôi cung cấp", nhưng nó nên là lớp rào bổ sung chứ không phải toàn bộ mô tả thứ bạn muốn.

Cho ví dụ mẫu: cách nâng chất lượng nhanh nhất

Khi yêu cầu khó tả bằng lời, có một cách rất mạnh: đưa vài ví dụ mẫu. Kỹ thuật này tiếng Anh gọi là few-shot, tức cho mô hình xem một vài cặp đầu vào và đầu ra mong muốn trước khi giao việc thật.

Chuyển mỗi dòng nhật ký lỗi thành một dòng tóm tắt cho báo cáo.
Làm theo đúng mẫu dưới đây.

Ví dụ 1
Vào: segmentation fault tại dòng 42 khi mảng rỗng
Ra: Truy cập mảng rỗng, cần kiểm tra kích thước trước khi đọc.

Ví dụ 2
Vào: vòng lặp while không bao giờ thoát khi n âm
Ra: Điều kiện dừng sai với n âm, cần chặn đầu vào âm.

Bây giờ xử lý dòng sau:
Vào: chia cho biến d chưa được gán giá trị
Ra:

Vì sao cách này hiệu quả? Vì mô hình đang chơi trò nối tiếp văn bản: khi ngữ cảnh đã có hai cặp theo đúng một khuôn, tiếp nối tự nhiên nhất của cặp thứ ba là một dòng cùng khuôn ấy, cùng độ dài, cùng giọng, cùng cách mở đầu. Bạn đã dùng chính cơ chế đoán chữ để ép định dạng.

Ví dụ mẫu tốn token nên đừng lạm dụng cho việc đơn giản; hai tới ba ví dụ thường là đủ. Điều tối kỵ là các ví dụ không nhất quán với nhau: nếu ví dụ một dài một dòng còn ví dụ hai dài năm dòng, bạn vừa dạy mô hình rằng độ dài không quan trọng, và nó sẽ tự do chọn.

Nêu tiêu chí thành công

Còn một thứ ít người dùng mà lợi ích rất lớn: nói cho mô hình biết thế nào là làm xong tốt. Đây không phải định dạng, cũng không phải chỉ dẫn, mà là thước đo để tự chấm.

Một yêu cầu tóm tắt có thể dừng ở "tóm tắt bài này thành ba gạch đầu dòng", hoặc thêm một dòng: "bản tóm tắt được coi là đạt nếu người chưa đọc bài gốc vẫn nêu được vấn đề, cách giải quyết và kết quả". Bản thứ hai cho mô hình một đích để nhắm, và nó sẽ tự loại những gạch đầu dòng chỉ nhắc lại tiêu đề. Với việc viết code, tiêu chí có thể là "chạy đúng với mảng rỗng và mảng một phần tử".

Mẹo thực dụng: tiêu chí thành công chính là cách bạn sẽ kiểm tra kết quả. Viết ra được thì dán luôn vào prompt; không viết ra được thì đó là dấu hiệu chính bạn cũng chưa rõ mình muốn gì, và không lời nhắc nào cứu được điều đó.

Lỗi thường gặp khi áp dụng bốn thành phần

• Nhồi vai trò cho oai. "Chuyên gia hàng đầu thế giới với ba mươi năm kinh nghiệm" không làm mô hình giỏi hơn. Vai trò chỉ có tác dụng khi nó khoá được giọng văn và mức độ chi tiết.
• Tả dữ liệu thay vì dán dữ liệu. "Code em đại khái là một vòng lặp cộng dồn" là vô dụng. Hãy dán code thật và nguyên văn thông báo lỗi.
• Ràng buộc mâu thuẫn. "Giải thích thật sâu" đi cùng "tối đa ba dòng" thì mô hình buộc phải hy sinh một trong hai, và nó sẽ chọn thay bạn.
• Định dạng mơ hồ. "Trả lời ngắn gọn" là mơ hồ. "Tối đa năm gạch đầu dòng" là rõ.

Tư duy nền: giao việc rõ như cho người mới

Tất cả những gì ở trên quy về một thói quen tư duy duy nhất. Nếu chỉ mang theo một điều khỏi buổi học này, hãy mang theo điều này: viết prompt như giao việc cho người mới vào nhóm, rất giỏi nhưng không biết bối cảnh riêng của bạn và không hỏi lại. Cái gì bạn không nói rõ, người đó sẽ tự đoán, mà đoán thì dễ sai.

Tư duy này dẫn tới ba câu hỏi tự kiểm bạn nên đặt ra mỗi khi viết prompt:

• Một người lạ đọc đúng lời nhắc này (không biết gì thêm về tôi) có làm đúng việc tôi cần không?
• Tôi đã đưa hết dữ liệu cần thiết vào lời nhắc chưa, hay còn để mô hình phải đoán?
• Tôi đã nói rõ muốn câu trả lời trông như thế nào chưa?

Bài tập nhỏ

Bài tập: thiếu thành phần nào?

Với mỗi lời nhắc dưới đây, hãy chỉ ra thành phần còn thiếu và hậu quả. (a) "Tóm tắt bài báo này thành ba gạch đầu dòng cho sinh viên năm nhất." (b) "Bạn là chuyên gia bảo mật. Đoạn code sau có lỗ hổng gì?" kèm code dán vào. (c) "Giải thích cây nhị phân tìm kiếm cho sinh viên năm hai, có ví dụ."

Lời giải. (a) Thiếu dữ liệu vào: người viết nói "bài báo này" nhưng không dán bài báo, mô hình sẽ hỏi lại hoặc bịa ra một bài. (b) Thiếu chỉ báo định dạng: bạn sẽ nhận về một bài phân tích dài lê thê; nên yêu cầu một bảng gồm lỗ hổng, dòng code, mức nghiêm trọng, cách sửa. (c) Thiếu chỉ báo định dạng và một phần ngữ cảnh: không rõ giải thích để thi hay để hiểu, dài bao nhiêu, có cần code hay không.

Bài tập: dịch câu cấm thành câu khẳng định

Một bạn viết lời nhắc sau để nhờ AI ôn tập: "Giải thích cây nhị phân tìm kiếm. Đừng viết dài dòng. Đừng dùng thuật ngữ khó. Đừng đưa code phức tạp. Đừng lan man sang cây cân bằng." Nhiệm vụ: chỉ ra vấn đề của lối viết này, rồi viết lại thành một lời nhắc dùng ràng buộc khẳng định, có đủ bốn thành phần và có tiêu chí thành công.

Lời giải. Vấn đề: cả bốn câu đều là ràng buộc phủ định, nêu ra bốn vùng cần tránh mà không chỉ cho mô hình biết phải đi đâu; tệ hơn, cụm "cây cân bằng" nằm ngay trong ngữ cảnh nên vẫn kéo mô hình về phía chủ đề đó. Lời nhắc cũng thiếu ngữ cảnh người đọc và thiếu chỉ báo định dạng; "dài dòng" và "thuật ngữ khó" đều không đo được. Bản viết lại, dịch từng câu cấm thành một yêu cầu khẳng định:

# vai trò và ngữ cảnh
Bạn là trợ giảng môn Cấu trúc dữ liệu. Người đọc là sinh viên năm
hai đã biết mảng và con trỏ, chưa học cây cân bằng.

# nhiệm vụ
Giải thích cây nhị phân tìm kiếm: quy tắc sắp xếp các nút, và cách
tìm một khoá. Chỉ nói về cây nhị phân tìm kiếm cơ bản.

# định dạng
Tối đa tám câu, cộng một sơ đồ cây bằng chữ có bảy nút, cộng một hàm
tìm kiếm trong C tối đa mười dòng, chú thích trong code bằng tiếng Anh.
Mọi thuật ngữ tiếng Anh dùng lần đầu phải kèm giải thích trong ngoặc.

# tiêu chí thành công
Đạt nếu một bạn chưa từng học cây vẫn nói được vì sao tìm kiếm trên
cây này nhanh hơn duyệt mảng tuần tự.

Chú ý cách dịch: "đừng dài dòng" thành "tối đa tám câu"; "đừng thuật ngữ khó" thành "thuật ngữ dùng lần đầu phải kèm giải thích"; "đừng code phức tạp" thành "hàm tối đa mười dòng"; "đừng lan man sang cây cân bằng" thành "chỉ nói về cây nhị phân tìm kiếm cơ bản", đồng thời đưa việc chưa học cây cân bằng vào phần ngữ cảnh cho đúng chỗ. Mỗi câu mơ hồ đã thành một con số hoặc một mệnh lệnh kiểm được.

Câu hỏi tự kiểm

Kiểm tra nhanh: bốn thành phần và RTF0/4 đúngchưa trả lời

1. 1Vì sao "viết tối đa năm câu" thường hiệu quả hơn "đừng viết dài dòng"?
2. 2Câu trả lời có dấu vết "nếu code của bạn có dạng như sau" rồi tự bịa ra một đoạn code để phân tích là dấu hiệu thiếu thành phần nào?
3. 3Gán vai trò (Role) cho mô hình có tác dụng gì?
4. 4Tiêu chí thành công trong prompt là gì?

Tóm tắt

Cả bài chỉ nói một điều: mô hình không đọc được ý bạn, nó chỉ đọc được chữ bạn gõ, nên chất lượng câu trả lời bị chặn trên bởi lượng thông tin bạn chịu viết ra. Bốn thành phần là danh sách kiểm để không bỏ sót, RTF là bản rút gọn cho việc nhanh. Trên nền đó là ba kỹ thuật rẻ mà nâng chất lượng rõ rệt: xếp vai trò và ngữ cảnh lên đầu, dữ liệu vào ở giữa có rào ngăn cách, định dạng xuống cuối; dịch mọi câu cấm thành câu khẳng định đo được; và khi việc khó tả bằng lời thì đưa hai tới ba ví dụ mẫu nhất quán. Cuối cùng, thêm một dòng tiêu chí thành công, nó vừa cho mô hình đích để nhắm vừa buộc chính bạn làm rõ mình đang muốn gì.

Ghi nhớ cuối bài

• Bốn thành phần: chỉ dẫn + ngữ cảnh + dữ liệu vào + chỉ báo định dạng. Chỉ dẫn là bắt buộc; hai phần hay bị quên nhất là ngữ cảnh và định dạng.
• RTF (vai trò, nhiệm vụ, định dạng) là bản gọn cho việc nhanh; dùng bốn thành phần khi việc phức tạp và có dữ liệu cần tách bạch.
• Vai trò không phải phép thuật, nó chỉ khoá giọng văn và mức độ chi tiết.
• Ràng buộc khẳng định mạnh hơn ràng buộc phủ định: nói cái muốn, đừng chỉ nói cái không muốn.
• Việc khó tả bằng lời thì đưa hai tới ba ví dụ mẫu nhất quán, và thêm một dòng tiêu chí thành công để mô hình có đích nhắm.
• Mỗi câu thêm vào prompt nên loại bỏ một cách hiểu sai. Nếu không, nó là chữ thừa.