Markdown tiết kiệm 90% token so với JSON trình bày đầy đủ, nhưng gần ngang JSON gọn

SerpApi vừa công bố một phép đo gây chú ý. Khi đưa kết quả Google Shopping vào mô hình, định dạng Markdown giảm token đầu vào trung bình 89,55% so với JSON. Con số này nghe như một chiến thắng áp đảo. Nhưng một phép đo độc lập cho thấy bức tranh đầy đủ hơn: nếu JSON được viết gọn lại, khoảng cách đó gần như biến mất.

Con số 90% đến từ đâu

Token là đơn vị mà mô hình dùng để đo độ dài văn bản đầu vào. Nhà cung cấp mô hình thường tính phí theo số token này. Vì vậy, cùng một tập kết quả tìm kiếm mà chiếm ít token hơn thì rẻ hơn, và còn chừa chỗ trong ngữ cảnh cho dữ liệu khác. Ngữ cảnh ở đây là toàn bộ văn bản mà mô hình đọc trong một lần gọi.

Nhóm SerpApi làm phép đo theo một cách chặt chẽ. Họ lấy 12 truy vấn Google Shopping. Với mỗi truy vấn, họ giữ nguyên thị trường, ngôn ngữ và thiết bị. Họ chỉ thay đổi một biến duy nhất là định dạng trả về: JSON hoặc Markdown. Sau đó, họ gửi cả hai bản trả về cho cùng một mô hình DeepSeek, và đọc số token đầu vào mà DeepSeek tự báo cáo. Họ tắt chế độ suy luận của mô hình, vì phép đo này chỉ quan tâm đến cách trình bày dữ liệu, không quan tâm đến chất lượng suy luận.

Kết quả trên 12 truy vấn là mức giảm trung bình 89,55%. Truy vấn tiết kiệm ít nhất giảm 86,59%. Truy vấn tiết kiệm nhiều nhất giảm 91,20%. Trang benchmark của chính SerpApi cho cùng một kết luận: kết quả Google Shopping giảm từ 361 nghìn token JSON xuống 38 nghìn token Markdown, tức khoảng 90%. Tuy nhiên, cùng trang đó cũng ghi mức tiết kiệm trung bình trên nhiều giao diện lập trình khác chỉ khoảng 50%. Con số 90% thuộc về Google Shopping, không phải con số chung cho mọi loại kết quả.

Vì sao JSON tốn nhiều token đến vậy

JSON là định dạng dữ liệu có cấu trúc mà chương trình máy tính đọc rất tốt. Mỗi trường dữ liệu đều có tên, giá trị, dấu ngoặc và dấu phẩy rõ ràng. Vấn đề xuất hiện khi cùng một kết quả lặp lại hàng chục lần. Mỗi sản phẩm đều lặp lại các tên trường như vị trí, tiêu đề, giá và đánh giá. Máy đọc không ngại chuyện này. Mô hình thì phải đọc qua từng ký tự lặp lại đó, và mỗi ký tự đều tính vào token.

Markdown là định dạng văn bản dùng bảng đơn giản. Tên trường chỉ xuất hiện một lần ở hàng tiêu đề của bảng. Các sản phẩm tiếp theo chỉ còn giá trị, xếp thành hàng. Cùng một thông tin, nhưng phần cấu trúc lặp lại đã biến mất. Ví dụ dưới đây dùng hai sản phẩm giày chạy bộ để thấy sự khác biệt.

{
  "shopping_results": [
    {
      "position": 1,
      "title": "Trail Runner X",
      "price": "$89",
      "rating": 4.7
    },
    {
      "position": 2,
      "title": "Aero Sprint",
      "price": "$74",
      "rating": 4.5
    }
  ]
}

## Shopping Results
| Position | Title | Price | Rating |
|---:|---|---:|---:|
| 1 | Trail Runner X | $89 | 4.7 |
| 2 | Aero Sprint | $74 | 4.5 |

Với hai sản phẩm, sự khác biệt còn nhỏ. Với 30 sản phẩm, các tên trường lặp lại 30 lần trong JSON, trong khi trong Markdown chúng chỉ xuất hiện một lần. Đó là lý do mức tiết kiệm tăng mạnh ở các tập kết quả có nhiều trường lặp lại và lồng nhau phức tạp.

Một phép đo độc lập nói gì khác

SerpKite, một dịch vụ kết quả tìm kiếm khác, đã đo một trang kết quả Google theo ba cách trình bày. Phép đo này chỉ dùng một mẫu rút gọn, gồm một hộp trả lời, ba kết quả tự nhiên, hai câu hỏi liên quan và ba tìm kiếm liên quan. Tác giả nói rõ đây là ước tính, không phải một benchmark đầy đủ. Token được ước tính theo tỷ lệ khoảng bốn ký tự cho một token, vì vậy con số tuyệt đối chỉ mang tính tham khảo. Điều đáng chú ý là tỷ lệ giữa các định dạng.

Định dạng	Token ước tính	So với JSON trình bày đầy đủ
JSON trình bày đầy đủ	668	Mốc so sánh
JSON thu gọn khoảng trắng	534	Giảm 20%
JSON gọn, rút ngắn tên trường và bỏ trường thừa	248	Giảm 63%
Markdown	240	Giảm 64%

Trên mẫu này, Markdown chỉ nhỉnh hơn JSON gọn một chút. Bài học không phải là Markdown kém hiệu quả. Bài học là điểm so sánh quyết định kết luận. So với JSON trình bày đầy đủ, Markdown thắng lớn. So với JSON đã được dọn dẹp, hai định dạng gần như ngang nhau. Bất kỳ ai công bố một tỷ lệ tiết kiệm cũng cần nói rõ mình đang so với loại JSON nào. Nếu không, con số 90% sẽ gây hiểu lầm rằng Markdown luôn tốt hơn JSON gấp mười lần, trong khi thực tế phụ thuộc vào cách JSON được viết.

Mẫu lớn hơn đã đổi kết luận phân tích

Phép đo thứ hai của SerpApi cho thấy định dạng không chỉ ảnh hưởng đến chi phí. Nó còn ảnh hưởng đến kết luận mà mô hình rút ra. Nhóm này đặt một câu hỏi bán hàng cụ thể: người bán giày chạy bộ nên tối ưu tiêu đề, giảm giá hay tăng đánh giá để lên cao hơn trong Google Shopping? Họ cố định ngân sách đầu vào ở mức 1.550 token, dùng cùng một mô hình và cùng một câu lệnh cho cả hai định dạng.

Với ngân sách đó, JSON chỉ chứa được 16 sản phẩm. Markdown chứa được cả 30 sản phẩm. Trong mẫu 16 sản phẩm của JSON, tín hiệu tiêu đề trông rất mờ nhạt. Tỷ lệ tiêu đề chứa từ khóa tìm kiếm ở nhóm đầu chỉ cao hơn nhóm cuối một chút. Mô hình kết luận rằng tiêu đề không phải lời giải thích rõ ràng cho thứ hạng.

Trong mẫu đầy đủ 30 sản phẩm của Markdown, bức tranh đổi khác. Tỷ lệ tiêu đề chứa từ khóa ở 10 vị trí đầu lên tới 47%. Ở 10 vị trí cuối, tỷ lệ này chỉ còn 17%. Mô hình vì thế đề xuất thử nghiệm thay đổi tiêu đề cho các sản phẩm ở vị trí thấp, bằng cách thêm cụm từ mô tả đúng loại giày và đối tượng sử dụng. Giá và số đánh giá không cho thấy mối liên hệ rõ ràng với thứ hạng trong ảnh chụp dữ liệu này.

Kết luận này cần được đọc đúng giới hạn của nó. Đây chỉ là một ảnh chụp tìm kiếm tại một thời điểm. Một ảnh chụp chỉ tạo ra giả thuyết, không chứng minh rằng thay đổi tiêu đề sẽ làm tăng thứ hạng. Điều phép đo chứng minh là một dạng khác: khi mô hình được thấy nhiều bằng chứng gốc hơn trong cùng một ngân sách, nó có thể đưa ra giả thuyết khác hẳn. Định dạng ở đây đóng vai trò như một chiếc cửa sổ. Cửa sổ càng rộng, mô hình càng thấy được nhiều dữ liệu để so sánh.

Khi nào dùng định dạng nào

Quy tắc chọn định dạng nên dựa vào người đọc kết quả tiếp theo, chứ không dựa vào khẩu hiệu chung.

Người đọc kết quả	Định dạng phù hợp	Lý do
Mô hình đọc trực tiếp để phân tích	Markdown	Bảng gọn, mô hình đọc như văn bản, giữ được liên kết kèm trích dẫn
Chương trình cần xử lý tiếp	JSON gọn hoặc chỉ lấy trường cần thiết	Giữ được cấu trúc trường, máy đọc chính xác, không cần phân tích văn bản
Chương trình cần hợp đồng dữ liệu chặt chẽ	JSON đầy đủ	Tên trường, kiểu dữ liệu và trạng thái đều rõ ràng, dễ kiểm tra
Hệ thống cần lưu trữ lâu dài	JSON đầy đủ	Đủ mọi trường gốc, không mất thông tin khi cần tra lại

Một pipeline thực tế có thể dùng cả hai. JSON giữ vai trò dữ liệu điều khiển: tham số công cụ, mã định danh, trạng thái và kết quả cần lưu. Markdown giữ vai trò dữ liệu cho mô hình đọc: kết quả tìm kiếm, tài liệu và bảng so sánh. Cũng như quy tắc cho agent cần được kiểm tra bằng mã thay vì tin bằng chữ, định dạng đầu vào cũng cần được đo bằng số token thật thay vì tin vào khẩu hiệu. SerpApi hỗ trợ cả ba cách lấy Markdown: thêm tham số định dạng, thêm đuôi vào đường dẫn, hoặc gửi tiêu đề yêu cầu định dạng văn bản. Kỹ thuật lấy dữ liệu không phải điểm khó. Điểm khó là quyết định trường nào mô hình thật sự cần, vì bỏ bớt trường thừa cũng tiết kiệm token không kém gì đổi định dạng.

Trước khi áp dụng con số của người khác, hãy tự đo trên dữ liệu của chính mình. Lấy một truy vấn thật từ hệ thống của bạn. Gửi cùng một kết quả cho mô hình dưới ba dạng: JSON trình bày đầy đủ, JSON gọn và Markdown. Đọc số token đầu vào mà mô hình báo cáo, thay vì ước tính từ kích thước tệp. So sánh xem mẫu lớn hơn có đổi kết luận phân tích hay không. Chỉ khi đó, tỷ lệ tiết kiệm mới là con số của hệ thống bạn, chứ không phải con số mượn từ một bài đo của người khác.

Giới hạn cần nhớ trước khi tin con số 90%

Cả bài đo trên DEV lẫn trang benchmark và kho mã demo đều đến từ SerpApi. Đây là phép đo của chính nhà cung cấp tính năng, không phải phép đo độc lập. Kho mã demo là công khai và ghi rõ phương pháp, nhưng tác giả vẫn là bên bán tính năng. Phép đo độc lập duy nhất trong bài này là mẫu nhỏ của SerpKite, và chính tác giả của nó cũng gọi đó là ước tính, không phải benchmark.

Phép đo của SerpApi cũng chỉ tính token đầu vào, trên một mô hình DeepSeek, cho kết quả Google Shopping. Tổng chi phí của một pipeline thật còn gồm token đầu ra, số lần gọi lại, bộ nhớ đệm, điều phối và các lần gọi giao diện khác. Giảm 90% token đầu vào cho một bước không đồng nghĩa với giảm 90% hóa đơn cuối tháng. Nói đúng giới hạn này không làm con số 90% trở nên vô nghĩa. Nó giúp con số đó đứng đúng chỗ: một lợi ích lớn cho một loại dữ liệu cụ thể, chứ không phải một quy luật chung cho mọi pipeline dùng mô hình.