Trả lời ngắn: Structured output (đầu ra có cấu trúc) là câu trả lời được đặt vào một khuôn đã định để người hoặc chương trình dùng tiếp một cách ổn định. Markdown hợp để người đọc; JSON hợp để chương trình đọc dữ liệu; XML hợp khi nơi nhận yêu cầu thẻ. Chọn format theo nơi nhận, rồi kiểm trước khi dùng.

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

  • Chọn Markdown, JSON hoặc XML theo người nhận thay vì theo trào lưu.
  • Phân biệt JSON đúng cú pháp với dữ liệu thật sự đạt yêu cầu.
  • Viết yêu cầu có key, giá trị cho phép và điểm dừng khi output lỗi.

Lưu ý giáo dục: AI có thể dùng sai key, thiếu dữ liệu hoặc bịa nội dung dù format trông rất đẹp. Đừng đưa dữ liệu khách hàng, token API hay thông tin nhạy cảm vào bài tập; với việc quan trọng, hãy kiểm bằng quy tắc và dữ liệu gốc trước khi tự động xử lý.

1. Structured Output: cùng một ý, đúng khuôn để dùng tiếp

a. Nó là hợp đồng, không phải lớp trang trí

Bạn hỏi AI: “Phân loại phản hồi này: Đơn hàng trễ, cần hỗ trợ gấp.” Nếu câu trả lời là một đoạn văn có lời chào, người đọc vẫn hiểu. Nhưng một chương trình muốn tự chuyển phản hồi đó cho đúng nhóm sẽ không biết đoạn nào là chủ đề, đoạn nào là mức khẩn.

Structured output giải quyết chuyện đó bằng một hợp đồng: hai bên thống nhất trước output có những phần nào, tên gì và được viết ra sao. Người nhận có thể là con người, một bảng tính, một form hay đoạn chương trình sau đó.

Hãy hình dung phiếu giao hàng: câu chữ hoa mỹ không thay được ô mã đơn bị thiếu. Cấu trúc giúp nơi nhận bớt phải đoán, nhưng một JSON đúng khuôn vẫn có thể phân loại sai. Nó làm dữ liệu dễ dùng và dễ kiểm hơn, không tự chứng minh nội dung đúng.

Hình 1 — Cấu trúc là hợp đồng để nơi nhận dùng tiếp, không phải huy chương cho một format nào.

b. Hỏi đúng câu trước khi chọn format

Trước khi viết prompt, hãy hỏi: “Ai hoặc cái gì đọc câu trả lời tiếp theo?” Nếu là người cần quét nhanh, ưu tiên dễ đọc. Nếu là một luồng tự động, ưu tiên trường rõ ràng. Nếu một cổng nhận đã quy định XML, tôn trọng đúng cổng đó.

Đoán chắc: AI trả đúng mẫu JSON là có thể dùng ngay.

Có điều kiện: chỉ dùng sau khi parse, kiểm schema và kiểm các quy tắc nghiệp vụ quan trọng.

2. Markdown, JSON, XML: chọn theo người nhận

a. Ba format làm ba việc khác nhau

Markdown là cách đánh dấu văn bản để người đọc dễ quét. Nó hợp với ghi chú và hướng dẫn.

JSON là văn bản dữ liệu gồm các cặp tên–giá trị theo cú pháp chặt. Nó hợp khi chương trình cần lấy chính xác trường như topic hoặc urgency để lọc, lưu hay chuyển bước.

XML cũng là văn bản có cấu trúc, nhưng dùng thẻ mở/đóng như <topic>...</topic>. Dùng XML khi hệ thống hoặc tiêu chuẩn bên nhận yêu cầu nó. Đặc tả XML của W3C mô tả XML là một ngôn ngữ markup có cấu trúc.

Format Hợp với ai Điểm mạnh Cần cẩn thận
Markdown Người đọc Dễ quét, dễ sửa Máy phải suy đoán nếu cần tách trường
JSON Chương trình Key rõ, dễ parse Cú pháp chặt; cần schema và kiểm logic
XML Hệ thống yêu cầu thẻ Cấu trúc lồng nhau rõ Nhiều ký tự; phải đóng/mở thẻ đúng

b. Cùng một ý, ba cách đóng gói

Với phản hồi giả Đơn hàng trễ, cần hỗ trợ gấp, Markdown có thể là:

**Chủ đề:** Giao hàng
**Mức khẩn:** Cao
**Phản hồi:** Tôi sẽ kiểm tra đơn.

JSON cho chương trình có thể là:

{
  "topic": "GIAO_HANG",
  "urgency": "HIGH",
  "reply": "Tôi sẽ kiểm tra đơn."
}

XML cho nơi nhận đã yêu cầu thẻ có thể là:

<feedback>
  <topic>GIAO_HANG</topic>
  <urgency>HIGH</urgency>
</feedback>

Không có format “xịn” cho mọi việc: Markdown cho người đọc, JSON cho chương trình cần tách key, XML khi quy ước bên nhận đã chọn XML.

3. JSON hợp lệ chưa chắc dữ liệu dùng được

a. Đầu tiên là cú pháp

Cú pháp là cách viết hợp lệ của một format. JSON dùng dấu nháy kép cho tên và chuỗi; không có comment hoặc dấu phẩy thừa. MDN cũng lưu ý JSON là format dữ liệu dạng text với các hạn chế này (MDN).

Ví dụ này không phải JSON hợp lệ vì dùng nháy đơn:

{'topic':'GIAO_HANG'}

Ví dụ dưới đây có thể parse được, nghĩa là chương trình parse — đọc văn bản thành dữ liệu — không bị vấp cú pháp:

{
  "topic": "GIAO_HANG",
  "urgency": "CAO",
  "reply": "OK"
}

Nhưng nó vẫn có thể không dùng được nếu hệ thống chỉ nhận LOW, MEDIUM hoặc HIGH, chứ không nhận CAO.

b. Schema kiểm cái khuôn; luật công việc kiểm ý nghĩa

Schema là bộ luật mô tả trường bắt buộc, kiểu dữ liệu và giá trị cho phép. Ở đây nó yêu cầu topic, urgency, reply; urgency thuộc một danh sách cố định. JSON Schema cũng nhấn mạnh schema cần validator để được áp dụng.

Vậy validation (kiểm luật) có thể chặn ba lỗi thường gặp:

  1. Thiếu urgency.
  2. Dùng topic_name khi hợp đồng ghi topic.
  3. Điền giá trị ngoài danh sách, như CAO thay vì HIGH.

Schema không tự biết “GIAO_HANG” có đúng hay reply có lộ thông tin cá nhân không. Đó là business rule (quy tắc nghiệp vụ) cần kiểm thêm sau schema.

Hình 2 — JSON hợp lệ chỉ cho biết mở được hộp; schema và quy tắc nghiệp vụ mới kiểm xem hàng trong hộp có dùng được không.

4. Viết yêu cầu cấu trúc rõ rồi kiểm ở điểm dừng

a. Nói rõ tên trường, lựa chọn và lúc phải dừng

Đừng chỉ viết “Trả JSON”. Hãy nói AI cần trả field nào, giá trị nào được phép và phải làm gì khi không đủ dữ liệu.

Chỉ trả một JSON object.
Key: topic, urgency, reply.
urgency: LOW, MEDIUM hoặc HIGH.
Nếu thiếu dữ liệu, dùng NEEDS_REVIEW.
Không thêm lời chào ngoài JSON.

Đây là prompt rõ hơn vì người nhận có hợp đồng cụ thể, đồng thời tạo điểm dừng: thiếu dữ liệu thì không giả vờ đoán. Với việc thật, hãy quy định ai xử lý NEEDS_REVIEW.

b. Prompt tốt không thay vòng kiểm

Luồng tối thiểu: yêu cầu rõ → AI tạo output → parse → validation theo schema → kiểm quy tắc nghiệp vụ → dùng hoặc retry. Parse lỗi, thiếu key hay sai enum thì dừng; đừng đẩy nó sang bước sau.

Các API hiện nay có thể hỗ trợ ràng buộc mạnh hơn prompt thuần. Ví dụ, Structured Outputs của OpenAI được thiết kế để output theo JSON Schema bạn cung cấp. Đây là cách tốt để giảm lỗi format trong một tích hợp phù hợp, nhưng vẫn không thay bước kiểm dữ liệu thực tế, quyền riêng tư và quy tắc công việc.

c. Retry không phải “cứ thử đến khi được”

Khi output lỗi, retry cần thông tin cụ thể: “Thiếu key urgency; chỉ trả JSON object với ba key quy định.” Giới hạn số lần thử và đưa về người kiểm khi lỗi lặp lại.

Hình 3 — Parse và validation là cổng trước khi dùng output; lỗi format cần dừng hoặc retry có lý do.

5. Bài tập 15 phút: biến phản hồi thành dữ liệu có thể chấm

a. Làm hai phiên bản với dữ liệu giả

Dùng chatbot miễn phí và chỉ dùng câu giả: Đơn hàng trễ, cần hỗ trợ gấp. Không dán chat khách thật, email, số điện thoại hay token API.

Trong chat đầu, yêu cầu Markdown gồm chủ đề, mức khẩn và câu trả lời ngắn. Trong chat hai, dùng prompt ở mục 4 với topic, urgency, reply; quy ước kết quả là GIAO_HANG, HIGH, và reply không rỗng. Đây là dữ liệu tự xây để luyện cấu trúc.

b. Chấm bằng một rubric nhỏ

Rubric là bộ tiêu chí chấm cùng một chuẩn. Mỗi tiêu chí dưới đây được một điểm:

  • Chỉ có một JSON object, không có lời chào ở ngoài.
  • Có đủ topic, urgency, reply.
  • topic là GIAO_HANG.
  • urgency là HIGH, không phải CAO.
  • reply có nội dung và không thêm dữ liệu cá nhân.

Mẫu đối chiếu

Trường hợp Kết quả cần có Quyết định
Feedback gốc Ba key, GIAO_HANG, HIGH Pass nếu parse và đủ rule
Thiếu urgency Không đủ hợp đồng Dừng, yêu cầu sửa
Lời chào ngoài JSON Không parse object thuần Dừng, yêu cầu chỉ JSON

c. Tự tạo ba lỗi có chủ đích

Hãy thử topic_name, thiếu urgency, và lời chào “Chắc chắn rồi!”. Mỗi lỗi bị chặn ở parse, schema hay business rule? Không có validator, bạn vẫn chấm tay bằng rubric; khi tích hợp thật, hãy đưa luật vào code hoặc công cụ kiểm.

6. Tổng kết: đầu ra rõ để người và hệ thống bớt đoán

a. Năm ý chính

  • Structured output là hợp đồng về cách nơi nhận đọc và dùng câu trả lời.
  • Chọn Markdown cho người đọc, JSON cho dữ liệu chương trình cần tách, XML khi nơi nhận đã yêu cầu thẻ.
  • JSON đúng cú pháp chưa đủ; cần schema cho key/kiểu/giá trị và business rule cho ý nghĩa thực tế.
  • Prompt nên nêu field, giá trị cho phép, dữ liệu thiếu và điểm dừng.
  • Luôn parse, validate rồi mới dùng; lỗi thì retry có lý do hoặc chuyển người kiểm.

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

  • Structured output khác câu trả lời viết tự do ở đâu?
  • Khi nào Markdown hợp hơn JSON?
  • Vì sao JSON parse được vẫn có thể bị từ chối?
  • Schema kiểm được điều gì và chưa kiểm được điều gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Nó có khuôn đã định để người hoặc chương trình dùng tiếp ổn định; văn tự do buộc nơi nhận phải suy đoán. Xem mục 1.

Xem gợi ý câu 2

Khi người nhận chính cần đọc và quét nội dung, không phải một chương trình cần tách key. Xem mục 2.

Xem gợi ý câu 3

Nó có thể thiếu key, sai enum hoặc vi phạm quy tắc nghiệp vụ dù cú pháp không lỗi. Xem mục 3.

Xem gợi ý câu 4

Schema kiểm trường, kiểu và giá trị cho phép; nó không tự xác nhận phân loại hay nội dung có đúng thực tế. Xem mục 3.

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

Thuật ngữ Giải thích ngắn
Structured output Đầu ra theo khuôn đã định trước
Markdown Văn bản có đánh dấu để người đọc dễ quét
JSON Văn bản dữ liệu key-value theo cú pháp chặt
XML Văn bản có cấu trúc bằng thẻ mở/đóng
Schema Luật về trường, kiểu và giá trị cho phép
Parse Đọc văn bản thành dữ liệu chương trình dùng được
Validation Kiểm dữ liệu có thỏa luật đã định
Business rule Điều kiện riêng của công việc cần kiểm thêm
Rubric Bộ tiêu chí chấm theo cùng chuẩn

e. Nguồn tham khảo

Sau bài Chain of Thought và reasoning, bạn đã biết cần yêu cầu phần nào có thể kiểm. Bài tiếp theo, Prompt Debugging, sẽ giúp bạn tìm vì sao prompt cho ra output sai hoặc lệch khuôn thay vì chỉ viết lại từ đầu.

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. Mọi quyết định thực tế đều cần dữ liệu và bước kiểm phù hợp.