Input format là gì? Cách trình bày prompt để LLM trả lời đúng

Tối ưu input format (định dạng đầu vào) không phải là thủ thuật trình bày cho đẹp mắt. Với tư cách kỹ sư hệ thống, bạn nên coi mỗi prompt là một gói tin (packet) gửi tới bộ xử lý token: cách bạn đóng gói dữ liệu ảnh hưởng trực tiếp đến xác suất phân phối token và đến chuyện mạch logic nào bên trong mô hình được kích hoạt. Một định dạng đầu vào lỏng lẻo sẽ làm tăng độ nhiễu, trong khi định dạng chuẩn giúp mô hình phân tách chính xác đâu là "vùng header" chỉ dẫn và đâu là "payload" dữ liệu.

Trong môi trường sản xuất, cách bạn tổ chức định dạng đầu vào quyết định trực tiếp độ chính xác (accuracy) và tính nhất quán (consistency) của hệ thống mô hình ngôn ngữ lớn (LLM). Nếu bạn không kiểm soát được định dạng đầu vào, mô hình sẽ phản ứng cực kỳ nhạy cảm với những biến đổi ngẫu nhiên, dẫn đến kết quả đầu ra không thể dự đoán.

Minh hoạ một prompt được đóng gói thành các khối cấu trúc rõ ràng đặt cạnh một khối văn bản thô không phân tách, cho thấy input format quyết định cách mô hình đọc dữ liệu

Input format là gì?

Input format là cách sắp xếp các thành phần của một gói tin prompt theo một cú pháp nhất định để mô hình ngôn ngữ lớn xử lý tối ưu.

Một định dạng đầu vào đạt chuẩn phải bóc tách rõ ràng 4 thành phần:

Chỉ dẫn (Instruction): Nhiệm vụ cụ thể hệ thống cần thực thi.
Ngữ cảnh (Context): Metadata hoặc dữ liệu bổ trợ để điều hướng mô hình.
Dữ liệu đầu vào (Input Data): Đối tượng dữ liệu cụ thể cần xử lý.
Chỉ báo đầu ra (Output Indicator): Schema hoặc định dạng kết quả mong muốn.

Sơ đồ bốn thành phần của một prompt: chỉ dẫn, ngữ cảnh, dữ liệu đầu vào và chỉ báo đầu ra, mỗi thành phần nằm trong một vùng riêng biệt

Điều bạn phải phân biệt cho rõ là nội dung (content) với cấu trúc (structure): nội dung là "what", còn cấu trúc là "how". Với mô hình ngôn ngữ lớn, cấu trúc chính là tín hiệu điều hướng. Khi bạn dùng các dấu phân tách (delimiters) chuẩn, bạn đang dựng ranh giới giữa các vùng dữ liệu, nhờ đó mô hình dồn tài nguyên tính toán vào đúng phần chỉ dẫn thay vì lạc trong những khối văn bản thô dài dằng dặc. Nghe thì hiển nhiên, nhưng đây đúng là chỗ phần lớn prompt hỏng: người viết chăm chút từng chữ trong phần nội dung rồi bỏ mặc phần cấu trúc.

Vì sao cách trình bày lại đổi kết quả?

Số liệu thực nghiệm nói rất thẳng: mô hình ngôn ngữ lớn nhạy cảm với định dạng đến mức khó chịu. Hiệu suất GPT-3.5 có thể biến động tới 40% trong các tác vụ dịch mã nguồn, chỉ vì bạn đổi cách trình bày. Và trên một môn trong benchmark MMLU (bộ bài kiểm tra kiến thức đa lĩnh vực), việc chuyển từ định dạng Markdown sang JSON đã giúp GPT-3.5-turbo-16k tăng độ chính xác tương đối tới 42%. Cùng một câu hỏi, cùng một mô hình, khác nhau mỗi bộ dấu ngoặc.

Biểu đồ cùng một nội dung prompt được trình bày bằng bốn định dạng văn bản thuần, Markdown, JSON và YAML cho ra bốn mức độ chính xác khác nhau

Người ta gọi hiện tượng này là "Sensitivity" (độ nhạy): cùng một nội dung, nhưng các cấu trúc dữ liệu khác nhau sẽ kích hoạt khả năng truy xuất thông tin khác nhau. Tuy nhiên, các dòng mô hình lớn như GPT-4 thường có độ Robustness (tính bền bỉ) cao hơn hẳn. Chỉ số CMD (Coefficient of Mean Deviation, hệ số sai lệch trung bình) của GPT-4-1106-preview luôn duy trì dưới mức 0,036 trên mọi benchmark, nghĩa là nó ít bị thay đổi định dạng làm lung lay hơn các dòng mô hình nhỏ.

Khi xây hệ thống, bạn cần tách bạch "Sensitivity" với "Consistency" (tính nhất quán), vì đó là hai chuyện khác nhau. Mô hình nhỏ vừa nhạy cảm với định dạng vừa thiếu nhất quán, trong khi mô hình lớn như GPT-4 giữ được kết quả đồng nhất giữa các định dạng khác nhau (thường đạt điểm Consistency trên 0,5 trong các bài thử nghiệm MMLU). Nói cách khác, một phần cái bạn nhận được khi trả tiền cho mô hình lớn là quyền bớt lo về định dạng.

Markdown, XML hay JSON: chọn dấu phân tách nào?

Chọn dấu phân tách (delimiters) chẳng khác gì chọn giao thức cho gói tin prompt. Ba lựa chọn, kèm bằng chứng kỹ thuật đi cùng:

So sánh ba dấu phân tách Markdown, XML và JSON theo mức tiêu tốn token và khả năng xử lý ngữ cảnh dài

Markdown: Định dạng mặc định được khuyến nghị cho GPT-4. Tiêu đề (H1-H4) cộng với in đậm giúp mô hình phân cấp thông tin hiệu quả mà vẫn tiết kiệm token.
XML: Đây là "vũ khí" cho các prompt có ngữ cảnh dài (long context). Các thẻ như <doc id="1">...</doc> cho phép bao bọc dữ liệu chặt chẽ và nhét thêm metadata vào các thuộc tính thẻ. Khi phải xử lý hàng trăm tài liệu cùng lúc, XML giúp mô hình duy trì sự tập trung tốt hơn.
JSON: Phù hợp cho các tác vụ lập trình và cho GPT-3.5. Tuy nhiên, JSON có nhược điểm là tốn nhiều token do các ký tự thoát (escaping characters) và dấu ngoặc. Khổ nỗi, JSON cực kỳ kém hiệu quả khi xử lý danh sách tài liệu dài trong long context, nếu so với XML hoặc định dạng ID: | TITLE: | CONTENT:.

Lời khuyên thực tế: GPT-3.5 ưu tiên JSON, còn với GPT-4, hãy chọn Markdown hoặc XML để đỡ phí cửa sổ ngữ cảnh.

Đặt hướng dẫn ở đâu trong prompt?

Chỉ dẫn (Instructions) nằm ở đâu trong gói tin prompt ảnh hưởng trực tiếp đến khả năng ghi nhớ của mô hình. Với các prompt dài, lên đến 1 triệu token, bạn phải áp dụng quy tắc "đầu và cuối": đặt chỉ dẫn ở cả hai đầu ngữ cảnh để giảm thiểu hiện tượng "lost in the middle" (quên dữ liệu ở giữa).

Sơ đồ vị trí chỉ dẫn trong một prompt dài: đặt ở đầu, bị quên ở giữa, và cách kẹp chỉ dẫn ở cả hai đầu ngữ cảnh

Nếu chỉ đặt được một nơi, hãy ưu tiên phía trên ngữ cảnh, vì đó là chỗ thiết lập "tâm thế" xử lý cho mô hình. Trong các quy trình tác nhân (agentic workflow), bạn cần bổ sung các lời nhắc (reminders) về tính Persistence (kiên trì), Tool-calling (gọi công cụ) và Planning (lập kế hoạch). Những lời nhắc này ngăn mô hình tự ý dừng lại giữa chừng hoặc đoán mò dữ liệu khi chưa đủ thông tin, nghe thì thừa nhưng bỏ đi là biết ngay.

Ví dụ trong prompt: định dạng quan trọng hơn nội dung

Trong kỹ thuật few-shot (đưa sẵn vài ví dụ mẫu vào prompt để mô hình bắt chước), cấu trúc của ví dụ còn quan trọng hơn cả chuyện nhãn (label) đúng hay sai. Giữ định dạng nhất quán giữa các ví dụ, mô hình vẫn nắm được logic tác vụ, ngay cả khi nhãn được gán ngẫu nhiên. Và chọn nhãn theo "phân phối đúng" (true distribution) của dữ liệu thực tế — tức là tần suất các nhãn trong bộ ví dụ phản ánh đúng tần suất thật ngoài đời — sẽ mang lại hiệu quả cao hơn nhiều so với việc chia đều số lượng mỗi nhãn.

Minh hoạ bộ ví dụ few-shot giữ định dạng nhất quán nhưng nhãn gán ngẫu nhiên vẫn cho kết quả tốt hơn prompt không có ví dụ nào

Ví dụ định dạng cho tác vụ NER (Named Entity Recognition, nhận dạng thực thể có tên) trong lĩnh vực tài chính:

markdown

### Ví dụ trích xuất:
 
- [Income] - CATEGORY: [increased by 10%] - VALUE: [ABC Corp] - ENTITY
- [Revenue] - CATEGORY: [flat] - VALUE: [XYZ Ltd] - ENTITY

Dấu gạch ngang cộng với ngoặc vuông tạo ra một mẫu (pattern) rõ ràng, và mô hình bóc tách thực thể theo mẫu đó chính xác hơn nhiều so với khi đọc văn bản thuần.

Cách chỉ định định dạng đầu ra

Để ép mô hình trả về kết quả có cấu trúc, bạn cần dùng "Output Indicator" kèm theo một schema rõ ràng. Nếu yêu cầu đầu ra là JSON, hãy tích hợp kỹ thuật Chain-of-Thought (CoT, chuỗi suy luận từng bước) vào ngay trong schema để ép mô hình suy luận trước khi kết luận.

Ví dụ schema JSON kết hợp CoT:

json

{
  "thought": "Phân tích logic các bước...",
  "result": "Kết quả cuối cùng dựa trên suy luận"
}

Đặt tên biến (key) cho rõ và mô tả schema cho chi tiết, bạn sẽ bớt phải nhận về những đoạn hội thoại thừa hoặc thứ định dạng mà không parser nào đọc nổi.

Những sai lầm thường gặp khi định dạng prompt

Lỗi lười biếng (laziness): Thường gặp ở GPT-4-32k khi bạn dùng JSON quá phức tạp. Mô hình có thể tạo Chain-of-Thought bằng văn bản thuần nhưng lại không tiếp tục tạo mã nguồn thực tế. Hãy đơn giản hóa cấu trúc ngay khi thấy mô hình bắt đầu "nhảy bước".
Lỗi chuyển đổi (transferability): Đừng giả định định dạng tối ưu cho GPT-3.5 (như JSON) sẽ hoạt động tốt nhất trên GPT-4 (thường ưu tiên Markdown/XML). Mỗi dòng mô hình có "khẩu vị" token khác nhau.
Nhiễu token: Những ký tự trang trí như dải dấu sao ********** hoặc chữ in hoa rải khắp nơi đều làm lãng phí token và gây nhiễu cho bộ giải mã. Delimiters chức năng (Markdown/XML) là đủ, phần trang trí còn lại chỉ tổ tốn token.

Bắt đầu từ đâu: khung prompt tối giản

Prompt engineering là một ngành khoa học thực nghiệm, không hơn không kém. Đừng tin vào cảm tính, hãy đo lường (evals) các biến thể định dạng trước khi triển khai. Khung tối giản tôi vẫn dùng để bắt đầu là:

Role → Instructions → Reasoning Steps → Output Format → Examples (true distribution) → Context.

Hãy bắt đầu bằng Markdown, vì nó cân bằng và tiết kiệm token. Và nhớ cho: một dấu đóng thẻ XML hay một header Markdown đặt đúng chỗ có thể cải thiện hiệu suất hệ thống hơn cả việc nâng mô hình lên đời to hơn.