Prompt Engineering qua đo lường: Điều gì làm thay đổi đầu ra

Trước các phép đo, có một sự thật lặng lẽ giải thích một nửa những gì theo sau.

Model không có bộ nhớ. Giữa hai lần gọi, nó không giữ lại gì cả — không phải câu hỏi trước của bạn, không phải câu trả lời trước của chính nó, không phải tệp bạn đính kèm, cũng không phải việc bạn đã hỏi nó hai lần rồi. Mỗi lần gọi bắt đầu từ một cỗ máy trống, và điều duy nhất cỗ máy đó biết là chuỗi token bạn vừa đưa cho nó.

Thứ trông giống bộ nhớ trong giao diện chat là client của bạn gửi lại toàn bộ cuộc trò chuyện, từng lượt, từ đầu. Model đọc lại tất cả từ con số không, mỗi lần. Chương 13 đã đo chi phí của việc đọc lại đó trong một forward pass; Chương 16 biến nó thành một dòng trên hóa đơn. Điều quan trọng ở đây là hệ quả cho thiết kế: prompt không phải là một tin nhắn gửi tới một hệ thống có trạng thái. Nó chính là trạng thái.

Điều này loại bỏ cả một nhóm nhầm lẫn. "Model quên điều tôi đã nói" thường nghĩa là điều đó chưa bao giờ được gửi. "Nó bỏ qua chỉ dẫn trước đó của tôi" thường nghĩa là chỉ dẫn đã rơi khỏi cửa sổ khi lịch sử bị cắt ngắn. "Nó hành xử khác trong production" thường nghĩa là production lắp ráp một prompt khác với prompt bạn đã test. Không cái nào trong số này là vấn đề của model, và không cái nào được sửa bằng cách diễn đạt lại.

Khẳng định "prompt này tốt hơn" là một khẳng định về một phân phối, và bạn không thể nhìn thấy phân phối bằng cách nhìn vào một output. Thứ bạn cần rất nhàm chán: các ca có đáp án đã biết, N biến thể, và một khoảng.

harness là năm mươi dòng TypeScript có cùng hình dạng với client từ Chương 14 — một request, một deadline, một chút concurrency, một bảng đếm. Nó xuất hiện lại trong Chương 19 để đánh giá một retriever và trong Chương 29 dưới dạng golden set.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

Con số trả về không phải là kết quả. Đây mới là kết quả:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

Chương 4 đã đưa ra lập luận và chương này hiện thực hóa nó. Đúng mười bảy trên hai mươi là 85 %, và khoảng 95 % của nó chạy từ 64 % đến 95 %. Một biến thể đạt 13 trên 20 — 65 %, thứ có cảm giác rõ ràng tệ hơn — có khoảng từ 43 % đến 82 %. Hai khoảng đó chồng lấn gần như toàn bộ chiều dài của chúng. Hai mươi ca không thể phân biệt một prompt tốt với một prompt trung bình, và phần lớn lời khuyên prompt được xuất bản đã được xác thực trên ít ca hơn thế.

Sáu mươi ca, là mức chương này dùng, vẫn chưa nhiều. Nó đủ để thấy các hiệu ứng lớn và đủ trung thực để thừa nhận khi không thấy được các hiệu ứng nhỏ — và bên dưới nó sẽ thừa nhận điều đó vài lần.

Ba khối — luật R, ticket T, chỉ dẫn I — được nối vào một user message. Tất cả sáu hoán vị, nội dung giống hệt theo byte, mỗi hoán vị sáu mươi ca.

Tốt nhất đến tệ nhất chênh 28,3 điểm, và các khoảng không chồng lấn, nên đây không phải câu chuyện về noise. Vì mọi nhánh đều được chấm trên cùng sáu mươi item, câu hỏi sắc hơn là câu hỏi ghép cặp: trong các ca mà hai nhánh bất đồng, tỷ lệ lệch đến mức nào? Đi từ thứ tự tệ nhất sang tốt nhất đã lật 21 ca thành đúng và 4 ca thành sai — xác suất ghép cặp exact 0,0009.³

Hãy đọc bảng theo hình dạng của nó thay vì người thắng. Hai hàng tốt nhất đều kết thúc bằng ticket; hai hàng tệ nhất đều chôn chỉ dẫn ở giữa hoặc kéo nó sau dữ liệu. Đó là cùng hiện tượng Liu et al. đặt tên Lost in the Middle: vật liệu ở rìa prompt được dùng đáng tin cậy hơn vật liệu ở trung tâm.⁴ Chương 16 định giá cửa sổ và Chương 24 đo hiệu ứng đúng cách ở độ dài lớn, nơi phần giữa sụp như đã mô tả và sự hồi phục ở tận cuối không xuất hiện lại. Ở đây quy tắc thực dụng tự rơi ra: tác vụ ở trên cùng, dữ liệu ở dưới cùng, không đặt gì quan trọng ở giữa.

Giờ hãy chuyển cùng từ ngữ giữa các lượt. Chương 11 đã xác lập rằng chat template không phải đồ trang trí quanh model mà là một phần của nó — <|im_start|>system và <|im_start|>user là các token thật mà model đã thấy hàng triệu lần trong fine-tuning, đúng ở các vị trí đó. Vì vậy việc chỉ dẫn của bạn nằm bên nào của các marker đó hẳn phải quan trọng, và đúng là có:

Chuyển luật và chỉ dẫn qua ranh giới template mang lại 21,7 điểm — 19 ca được, 6 ca mất, xác suất ghép cặp 0,0146 — mà không đổi một ký tự nào. Đây là câu trả lời cụ thể cho system prompt so với user prompt: chúng không phải hai cách nói cùng một điều. Chúng là hai vị trí token khác nhau trong một cấu trúc mà model đã được train trên đó, và vị trí system là nơi các chỉ dẫn áp dụng cho toàn bộ cuộc trò chuyện nên nằm.

Cũng hãy để ý hàng thứ ba. Lặp lại chỉ dẫn sau ticket — một mẹo được khuyến nghị rộng rãi — đạt điểm thấp hơn so với nói một lần. Trên model này, với tác vụ này, nói hai lần tệ hơn nói một lần.

Cùng prompt, vị trí tốt nhất, sáu mươi ca. Điều duy nhất thay đổi là thứ bao quanh văn bản ticket.

Chênh mười tám điểm chỉ từ dấu câu. Nhưng nhìn hai khoảng cực trị: [73,9, 91,9] và [54,1, 77,3]. Chúng chồng lấn. Theo cách đọc thô — so sánh error bar, nếu chúng chạm nhau thì không nói gì — bảng này chẳng chứng minh gì cả.

Cách đọc thô ở đây là sai, và hiểu vì sao còn đáng giá hơn bảng. Mỗi biến thể được chấm trên cùng sáu mươi ticket, nên hai phép đo không phải mẫu độc lập; chúng được ghép cặp. Phần lớn độ rộng của mỗi khoảng đến từ một nguồn bất định mà cả hai nhánh cùng chia sẻ — liệu sáu mươi ticket này có đại diện không — và nguồn đó triệt tiêu khi bạn so sánh chúng với nhau. Hỏi câu hỏi ghép cặp thay vào đó và câu trả lời sắc nét: đi từ dấu ngoặc kép sang thẻ XML đã lật 12 ca thành đúng và 1 ca thành sai, xác suất ghép cặp 0,0034. Đó là khác biệt thật.

Rồi cùng bài test ấy làm xẹp tiêu đề. Thẻ XML thắng nhãn Ticket: trơn 8,3 điểm, là con số một bài blog sẽ đưa lên tiêu đề. Ghép cặp: 6 được, 1 mất, xác suất 0,1250. Chưa được xác lập. Bảy ca là nền móng của cải thiện nổi tiếng đó.

Vậy có hai câu hỏi với hai dụng cụ khác nhau, và trộn chúng lại là cách lời khuyên prompt sai theo cả hai hướng cùng lúc:

Phát hiện tổng quát — rằng model nhạy mạnh và khó đoán với các lựa chọn định dạng không mang nội dung ngữ nghĩa — không mới. Sclar et al. chỉ thay separator, khoảng trắng và chữ hoa/thường trên hàng chục tác vụ và tìm thấy các khoảng chênh accuracy đủ rộng để đảo ngược xếp hạng model đã công bố.⁵ Hệ quả thực dụng không phải là "dùng thẻ XML". Mà là định dạng là một hyperparameter, quét nó không tốn gì, và mọi so sánh hai model cố định một định dạng đang so sánh định dạng cũng nhiều như so sánh model.

In-context learning — cho model xem các ví dụ đã làm trong prompt và để nó khái quát từ chúng mà không cập nhật weight — là năng lực khiến GPT-3 nổi tiếng.⁶ Câu hỏi thực tế không bao giờ là nó có hiệu quả không. Mà là nên trả tiền cho bao nhiêu ví dụ.

Ví dụ được đưa vào dưới dạng các lượt trước thật, luân phiên user và assistant, vì đó là cấu trúc template đã được train trên. Mỗi k được chạy với năm lần rút ngẫu nhiên khác nhau từ một pool tách biệt gồm mười sáu ticket đã gắn nhãn:

Hai ví dụ mang lại bảy điểm. Sáu ví dụ tiếp theo không mang lại gì đo được — 83,7, rồi 81,7, rồi 83,7, một chuỗi lang thang trong chính noise của nó. Mười sáu ví dụ mang lại thêm năm điểm rưỡi. Đường cong không phải một cú leo mượt; nó là một bậc, một cao nguyên và một bậc.

Cột quan trọng nhất là cột cuối. Ở k = 8, tám ví dụ bạn tình cờ chọn đã làm accuracy dịch 10 điểm — lớn hơn toàn bộ mức tăng từ hai ví dụ lên tám. Và hàng cuối là phiên bản sắc nhất của điều đó: ở k = 16 pool đã cạn, nên cả năm lần chạy chứa chính xác cùng mười sáu ví dụ, chỉ khác thứ tự xuất hiện. Chỉ riêng thứ tự đã làm accuracy dịch 8,3 điểm.

Đó là kết quả Lu et al. đã báo cáo và nó tồn tại ở mọi nơi người ta tìm nó: thứ tự ví dụ là một hyperparameter thật với hiệu ứng ngang cỡ số lượng ví dụ.⁷ Vì vậy lời khuyên trung thực về few-shot prompting không phải là một con số. Nó là:

Giờ đến folklore. Mỗi câu dưới đây là một câu đơn được thêm vào đầu system prompt vốn còn lại giống hệt, trên cùng sáu mươi ca.

Bốn trong năm câu không làm gì cả. Không phải "làm một chút"; mà là không có gì sáu mươi ca ghép cặp nhìn thấy được. Persona chuyên gia và lời hối lộ đều đạt điểm thấp hơn baseline không đụng tới, và ngay cả các mức giảm đó cũng trượt bài test ghép cặp — chúng là noise chỉ xuống dốc.

Hàng thứ ba là hàng đáng ngồi lại với nó. "This is very important to my career" tạo ra chính xác cùng accuracy, 46 trên 60 — và mười trong sáu mươi câu trả lời đã đổi, năm theo mỗi hướng. Thống kê tóm tắt giống hệt còn hành vi thì không. Nếu đánh giá của bạn là một con số đơn trên một tập nhỏ, một thay đổi viết lại một phần sáu output có thể trông như một thay đổi không làm gì, và bạn sẽ ship nó với niềm tin rằng nó miễn phí.

Rồi đến lời đe dọa, câu duy nhất làm kim dịch chuyển và dịch 35 điểm xuống, lật 24 ca từ đúng sang sai. Đó không phải artefact làm tròn; đó là một hành vi model khác. Bài học không phải là "đừng bao giờ đe dọa model". Mà là framing cảm xúc không trơ. Nó dịch phân phối, đôi khi rất mạnh, theo hướng không ai dự đoán được chỉ bằng cách đọc câu — chính vì thế nó phải được đo thay vì suy luận.

Một lưu ý chương này nợ bạn: năm câu này được test trên một model nhỏ và một tác vụ. Một vài câu có hỗ trợ đã công bố ở nơi khác — "take a deep breath" đến từ một paper đã tìm kiếm các chỉ dẫn đạt điểm cao thay vì tự bịa ra chúng, một khẳng định khác và tốt hơn so với phiên bản lan truyền sau đó.⁸ Điều khái quát không phải các câu. Mà là danh sách sống sót trong blog post và danh sách sống sót qua đo lường là hai danh sách khác nhau, và cách duy nhất để biết bạn đang cầm danh sách nào là chạy bench.

Một quy tắc ai cũng lặp lại — hãy nói điều bạn muốn, không phải điều bạn không muốn — với sự vắng mặt quen thuộc của một con số. Đây là con số. Cùng yêu cầu định dạng, viết ba cách, với model generate tự do để có thể quan sát compliance:

Ba lệnh cấm làm tệ hơn một chỉ dẫn, và khiến model viết nhiều text hơn năm lần — trái ngược chính xác với cả ba lệnh cùng lúc. Thêm lại câu khẳng định cứu nó lên 68 %.

Cơ chế không bí ẩn khi bạn nhớ Chương 8. Model chọn token tiếp theo từ một phân phối được điều kiện hóa trên mọi thứ trước đó, và một lệnh cấm đưa thứ bị cấm vào phần điều kiện hóa đó. Không có toán tử cho phủ định; chỉ có một context trong đó một từ giờ đã xuất hiện.

Điều này có thể đo trực tiếp. Lấy prompt baseline và thêm một dòng: Do not use the shipping queue for software problems. Rồi chỉ nhìn vào bốn mươi lăm ticket không phải shipping ticket:

Gọi tên một hàng đợi để loại trừ nó khiến model chọn nó thường xuyên hơn ba lần, gần như nhân ba probability mass gán cho nó, và làm mất 25 điểm accuracy tổng thể — 16 ca mất so với 1 ca được, xác suất ghép cặp 0,0003.

Đừng nghĩ về con voi, đã được đo. Cách viết lại luôn giống nhau: thay lệnh cấm bằng quy tắc khẳng định khiến lệnh cấm trở nên không cần thiết. Không phải "đừng dùng shipping cho vấn đề phần mềm" mà là "chỉ dùng shipping khi có bưu kiện vật lý liên quan".

Chương 12 đã xây dựng chain of thought đúng cách — trước hết như một kỹ thuật prompting,⁹¹⁰ rồi như thứ được train vào bằng phần thưởng kiểm chứng được — và kết thúc bằng một cảnh báo hoãn lại tới chương này: bảo model nghĩ từng bước ngừng giúp khi model tự suy luận, và có thể gây hại. Đây là cảnh báo đó với một bảng bên dưới, trên một tác vụ rất dễ giả định rằng nghĩ nhiều hơn hẳn tốt hơn.

Cả hai nhánh được đọc bằng cùng dụng cụ ở cùng vị trí. Khác biệt duy nhất là liệu một chain of thought do model tự viết có nằm trong context trước hay không.

Accuracy giảm và chi phí tăng, và quy tắc của chính chương này áp dụng cho chính kết quả của chương này: mức giảm là 7 ca được so với 10 ca mất, xác suất ghép cặp 0,629, chưa được xác lập. Điều được xác lập là nó tạo ra chín mươi tám token output thêm mỗi lần gọi và không mua được gì đo được. Bất định hoàn toàn nằm ở phía lợi ích. Hóa đơn là chắc chắn.

Một chain thất bại có tính hướng dẫn hơn một chain thành công. Khi được yêu cầu suy luận về "Your Slack integration stopped posting messages after Tuesday", model viết:

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

Đó là lời khuyên troubleshooting có năng lực, và nó không phải tác vụ. Khi được yêu cầu nghĩ, model trôi vào thể loại mà "think step by step about this support ticket" giống nhất trong dữ liệu train của nó — rồi trả lời một câu hỏi phân loại bằng năm trăm ký tự suy luận không liên quan trong chính context của nó. Chain of thought giúp ở các bài toán có trạng thái trung gian đáng tính: số học, tra cứu nhiều bước, thỏa mãn ràng buộc. Route một câu vào một trong bốn bucket không có trạng thái trung gian. Không có gì để chain nắm giữ, nên tất cả những gì nó làm là thêm text nghe hợp lý mà quyết định cuối cùng phải sống sót qua đó.

Hai hệ quả thực dụng. Thứ nhất, với một model được train để suy luận — các model RLVR của Chương 12 — chỉ dẫn này còn tệ hơn dư thừa: nó có thể thay chain dài mà model lẽ ra tạo ra bằng một chain ngắn, mang hình dạng prompt. Và sampling nhiều chain rồi bỏ phiếu, là điều self-consistency làm,¹¹ không thể cứu một tác vụ chẳng có gì để bất đồng: nó nhân chi phí với số mẫu để phá các thế hòa vốn không tồn tại. Chương 12 đã đo đánh đổi đó ở nơi nó có áp dụng. Thứ hai, hãy để ý chính scaffold so sánh đã tốn gì. Ép câu trả lời vào một dòng Final queue: làm nhánh không suy luận rơi từ 76,7 % xuống 61,7 %. Mười lăm điểm, trả để làm hai nhánh có thể so sánh. Cấu trúc tồn tại để tiện cho bạn cũng không miễn phí.

Một phép đo cuối, vì đây là câu hỏi ai cũng hỏi sau kết quả bất ngờ đầu tiên. Sáu mươi prompt, greedy decoding, chạy lặp lại:

• Cùng một lần gọi lặp lại khi mọi thứ được giữ cố định trả về các xác suất giống hệt theo bit. Deterministic.
• Cùng một lần gọi được batched với các hàng xóm khác nhau — batch size 1, 4, 12, 30 và 60 — trả về xác suất khác nhau tối đa 0,0128. Nhãn được chọn không bao giờ đổi, trong 0 trên 60 ca.

Nhãn sống sót vì nó có khoảng trống: trên sáu mươi ca, khoảng cách hẹp nhất giữa hai hàng đợi đứng đầu là 0,0459, gấp ba lần rưỡi mức drift. Sự ổn định không phải thuộc tính của thuật toán. Nó là một margin, và margin sẽ cạn. Chương 17 là nơi lý do số học nằm và nơi các núm sampling làm rộng và hẹp các khoảng đó được tháo ra. Lý do đặt nó ở đây là nó giới hạn ý nghĩa của mọi phép đo prompt: bench đo một hệ thống chỉ tái lập được trong một dung sai, và chênh lệch hai điểm giữa các biến thể nằm trong dung sai đó vào một ngày xấu.

Mọi thứ bên trên là con người chọn một biến thể và máy chấm nó. Bước tiếp theo hiển nhiên là để máy chọn cả các biến thể.

APE làm đúng điều đó: một model đề xuất các chỉ dẫn ứng viên, chúng được chấm trên ví dụ held-out, và các chỉ dẫn tốt nhất sống sót.⁸ Các chỉ dẫn nó tìm được thường là những câu không con người nào sẽ viết, và đó chính là điểm mấu chốt — tìm kiếm diễn ra trên thứ đạt điểm, không phải thứ nghe chuyên nghiệp.

DSPy đi xa hơn và là ý tưởng hữu ích hơn cho một product.¹² Bạn khai báo mỗi bước của một pipeline nhận gì và trả gì, và framework biên dịch điều đó thành prompt, chọn demonstrations và tối ưu hóa chỉ dẫn theo metric của bạn. Đổi model thì bạn recompile thay vì viết lại. prompt ngừng là source code ai đó tinh chỉnh bằng tay và trở thành một artefact được tạo ra theo metric, đúng như lẽ ra nó phải là từ đầu.

Cả hai không loại bỏ nhu cầu về bench. Cả hai biến nó thành thứ duy nhất bạn cần, vì một optimiser không có metric thì không tối ưu gì cả.

Điều còn lại là kỷ luật. Prompt thuộc về version control, trong các file, cạnh code gửi chúng — không phải trong một dòng database ai đó sửa vào thứ Ba. Chúng cần một version identifier được lưu cùng mọi output mà chúng tạo ra, nếu không đến ngày có regression bạn không thể biết điều gì đã đổi. Chúng cần bench trong continuous integration, vì prompt là phần duy nhất trong hệ thống của bạn mà vendor có thể âm thầm làm vô hiệu bằng cách deploy model mới. Và chúng cần các ca: không phải một trăm ca thông minh, chỉ là hai mươi ca nhàm chán đã hỏng quý trước, giữ mãi. Bench là deliverable. prompt là by-product của nó.

Mọi thứ trong chương này được đo bằng accuracy. Mỗi biến thể trong số đó cũng có một cái giá.

System prompt mua được 21,7 điểm được gửi trong mọi lần gọi, mãi mãi. Hai ví dụ mua được bảy điểm được gửi trong mọi lần gọi, mãi mãi. Mười sáu ví dụ mua được mười hai điểm được gửi trong mọi lần gọi, mãi mãi, và chúng dài xấp xỉ mười lần câu hỏi user thực sự hỏi. Chain of thought không mua được gì tạo ra chín mươi tám token thêm mỗi request, và output token là loại đắt.

Không gì trong số đó hiện ra trong bảng accuracy, và tất cả đều hiện trên hóa đơn.

Chương 16 nói về đơn vị mà các quyết định đó thực sự được định danh. token như một đơn vị tính tiền, context window như một ngân sách thay vì bộ nhớ, vì sao một cuộc trò chuyện bốn mươi lượt tốn hơn rất nhiều so với bốn mươi lần lượt đầu, prompt caching trả tiền cho gì và không trả tiền cho gì, và vì sao thứ tự prompt của bạn quyết định cache có hit hay không — hóa ra đó là lý do thứ hai, hoàn toàn kinh tế, để đặt vật liệu ổn định trước và vật liệu biến đổi sau.

Bench và mọi bảng được tạo với Qwen/Qwen2.5-0.5B-Instruct dưới greedy decoding, nên chúng tái lập chính xác. Tài liệu Hugging Face về chat templates là tham chiếu cho việc các template marker của Chương 11 thực sự expand thành gì, và cho thực tế rằng một model ship sai template là lỗi thật và lặp lại. Với hiệu ứng vị trí và định dạng ở quy mô production thay vì quy mô phòng thí nghiệm, các trích dẫn ở trên là nguồn chính; các hướng dẫn prompting của vendor hữu ích nhờ ví dụ của chúng và nên được đọc với nhận thức rằng không hướng dẫn nào công bố một khoảng.