Cập nhật lần cuối: 2026-09-05

Giới hạn ký tự Prompt AI: Hướng dẫn thực hành Prompt Engineering

Chất lượng đầu ra của AI phụ thuộc rất nhiều vào thiết kế prompt. Tuy nhiên, viết prompt dài hơn không tự động tạo ra kết quả tốt hơn. Hiểu giới hạn token của từng mô hình và tối đa hóa hiệu quả trong những ràng buộc đó chính là cốt lõi của prompt engineering. Hướng dẫn này đi sâu hơn các mẹo bề mặt, bao gồm cơ chế hoạt động của tokenizer, vấn đề Lost in the Middle và các mẫu prompt thực tế bạn có thể sử dụng ngay.

Cách Token hoạt động - Thuật toán BPE và mối quan hệ phi tuyến với số ký tự

Để thiết kế prompt hiệu quả, trước tiên bạn cần hiểu cách token được tạo ra. Các mô hình AI hiện đại sử dụng tokenizer dựa trên thuật toán BPE (Byte Pair Encoding). BPE hoạt động bằng cách liên tục ghép các cặp byte xuất hiện thường xuyên nhất trong dữ liệu huấn luyện để xây dựng bảng từ vựng.

Cơ chế này có nghĩa là mối quan hệ giữa số token và số ký tự là phi tuyến. Những từ ngắn, xuất hiện thường xuyên thường gói vừa trong một token duy nhất, trong khi những từ dài và ít xuất hiện trong dữ liệu huấn luyện bị chia thành nhiều token. Văn bản CJK còn phức tạp hơn nữa: một kanji hiếm chưa từng vào được bảng từ vựng sẽ bị phân rã xuống mức byte, nên một ký tự chiếm 3 byte trong UTF-8 có thể tiêu tốn tới 3 token chỉ riêng nó. Vì vậy cùng một số ký tự có thể tạo ra mức tiêu thụ token rất khác nhau tùy thuộc vào nội dung. Vì cách một từ bị chia do chính tokenizer của từng mô hình quyết định, trong thực tế việc nắm chắc rằng số ký tự không đo được số token có ích hơn là ghi nhớ từng giá trị cụ thể.

Tại sao ngôn ngữ CJK kém hiệu quả token hơn - Bối cảnh kỹ thuật

Văn bản CJK (tiếng Trung, tiếng Nhật, tiếng Hàn) kém hiệu quả token hơn tiếng Anh và tiêu thụ nhiều token hơn đáng kể để truyền đạt cùng một nội dung ngữ nghĩa. Ba yếu tố tạo nên sự chênh lệch này.

Thứ nhất, tokenizer BPE được huấn luyện trên kho ngữ liệu mà tiếng Anh chiếm ưu thế. Ngôn ngữ có nhiều dữ liệu huấn luyện hơn phát triển các phép ghép token hiệu quả hơn, cho phép tiếng Anh diễn đạt nhiều ý nghĩa hơn trên mỗi token. Thứ hai, tiếng Nhật sử dụng hệ thống đa chữ viết (kanji, hiragana, katakana và ký tự Latin), và sự đa dạng ký tự này làm giảm hiệu quả tokenization. Thứ ba, tiếng Nhật không có ranh giới từ bằng khoảng trắng, khiến tokenizer khó xác định điểm chia tối ưu hơn.

Để hiểu sâu hơn về cách mã hóa đa byte ảnh hưởng đến hiệu quả token, hãy xem hướng dẫn của chúng tôi về số ký tự so với số byte. Tuy nhiên, mọi tỷ lệ "token trên mỗi ký tự" cố định đều thay đổi mỗi khi một thế hệ tokenizer mới xuất hiện. Mang một tỷ lệ đã ghi nhớ từ mô hình này sang mô hình khác chính là cách các ước tính đi chệch hướng, nên khi chi phí hoặc một giới hạn cứng đang bị đặt cược, hãy đo văn bản của bạn bằng tokenizer của đúng mô hình mà bạn đang gọi.

Cách tư duy về cửa sổ ngữ cảnh và ước tính số ký tự

Số token mà một mô hình có thể tiếp nhận trong một lần, tức cửa sổ ngữ cảnh, trải trên một phạm vi rất rộng: tính đến năm 2026, nó chạy từ mức vài trăm nghìn token cho tới quy mô hàng triệu token. Những con số này bị viết lại theo mỗi thế hệ mô hình, nên ghi nhớ chúng theo từng mô hình là không thực tế. Đáng tin cậy hơn nhiều là đưa hẳn một bước vào quy trình của bạn: tra giới hạn hiện hành trong tài liệu chính thức của mô hình bạn sắp dùng, trước khi bắt đầu thiết kế prompt.

Điều tương tự cũng đúng với ước tính số ký tự. Ở cùng một số token, lượng văn bản vừa vào thay đổi rất nhiều theo loại văn bản: văn xuôi hội thoại nhồi được nhiều ký tự vào mỗi token hơn so với tài liệu kỹ thuật dày đặc thuật ngữ chuyên ngành. Áp một tỷ lệ chuyển đổi cố định sẽ làm lệch ước tính của bạn, nên với những prompt quan trọng, hãy xác minh độ dài bằng tokenizer thực tế của mô hình trước khi gửi.

Còn một điểm nữa rất dễ bị bỏ sót ở giai đoạn thiết kế. Cửa sổ ngữ cảnh khả dụng cho đầu vào của bạn và số token tối đa mà mô hình có thể tạo ra trong một phản hồi là hai ngân sách riêng biệt. Ngay cả khi phía đầu vào còn dư dả chỗ trống, một phản hồi vẫn có thể dừng giữa đường vì đã chạm trần đầu ra. Với những nhiệm vụ đòi hỏi văn bản dài, hãy kiểm tra giới hạn đầu ra trước và thiết kế prompt để tạo nội dung theo từng phần.

Vấn đề Lost in the Middle - Phân bổ Attention trong ngữ cảnh dài

Ngay cả các mô hình có cửa sổ ngữ cảnh lớn cũng không chú ý đều đến tất cả các phần của đầu vào. Nghiên cứu công bố năm 2023 ("Lost in the Middle") đã chứng minh rằng thông tin đặt ở giữa ngữ cảnh dài được tham chiếu kém tin cậy hơn so với thông tin ở đầu hoặc cuối.

Điều này có ảnh hưởng trực tiếp đến thiết kế prompt. Khi soạn một prompt 10.000 token, hãy đặt các hướng dẫn và ràng buộc quan trọng nhất ở đầu hoặc cuối. Sử dụng phần giữa cho thông tin bổ sung và dữ liệu tham khảo có mức ưu tiên thấp hơn.

Một biện pháp đối phó thực tế là "cấu trúc sandwich": khai báo các hướng dẫn quan trọng ở đầu, sau đó nhắc lại chúng ở cuối. Ngoài ra, nhồi đầu vào sát tới giới hạn cửa sổ ngữ cảnh có xu hướng làm giảm chất lượng đầu ra, nên hãy thiết kế với giả định rằng bạn luôn chừa khoảng dư so với giới hạn, và tóm tắt tài liệu tham khảo dài trước khi đưa vào.

Cấu trúc Prompt hiệu quả

1. Định nghĩa vai trò (20–50 từ): Chỉ định persona của AI - "Bạn là chuyên gia tài liệu pháp lý."
2. Mô tả nhiệm vụ (30–100 từ): Nêu rõ ràng những gì bạn cần thực hiện.
3. Ràng buộc (20–60 từ): Xác định định dạng đầu ra, độ dài, giọng điệu và hạn chế.
4. Dữ liệu đầu vào (thay đổi): Cung cấp văn bản hoặc tài liệu tham khảo cần xử lý.

Đối với hầu hết các nhiệm vụ, 100–250 từ prompt cho kết quả tốt. Nếu bạn cần hơn 300 từ, hãy cân nhắc chia nhỏ nhiệm vụ. Tuy nhiên, hướng dẫn này phụ thuộc vào độ phức tạp của nhiệm vụ. Các nhiệm vụ tạo code và phân tích dữ liệu có thể cần 400–800 từ prompt.

Thiết kế System Prompt và phân bổ Token

Khi sử dụng mô hình AI qua API, thiết kế system prompt trở nên quan trọng. System prompt được bao gồm trong mọi yêu cầu, nên độ dài của nó ảnh hưởng trực tiếp đến chi phí token ở quy mô lớn.

Câu trả lời thực tế là tự đặt ra trần độ dài cho system prompt của bạn và vận hành trong trần đó. Khi một prompt có nguy cơ vượt trần, hãy dừng việc cố viết mọi thứ vào ngay từ đầu và cân nhắc mô hình RAG (Retrieval-Augmented Generation) chỉ chèn đúng thông tin mà mỗi yêu cầu thực sự cần. Không có một cách phân bổ duy nhất đúng, nhưng giữ phần vai trò và hướng dẫn trong vài dòng, chi mạnh tay cho đặc tả định dạng đầu ra cùng các ràng buộc và hạn chế, rồi thu hẹp ví dụ few-shot xuống những trường hợp đại diện nhất sẽ giúp prompt luôn trong tầm kiểm soát. Vì đoạn văn bản này đi kèm theo mọi yêu cầu, đây cũng là chỗ mà việc cắt bớt một dòng được nhân lên nhiều lần.

Mẫu Prompt thực tế

Đây là mẫu prompt sẵn sàng sử dụng. Các phần biến được đánh dấu bằng {{...}}.

Mẫu nhiệm vụ đa năng (~80 từ):

You are an expert in {{domain}}.
Perform {{task description}} on the following input.

## Constraints
- Output format: {{format (e.g., bullet points, table, paragraphs)}}
- Length: {{limit}} words maximum
- Tone: {{tone (e.g., formal, casual)}}

## Input
{{input text}}

Lựa chọn thiết kế chính ở đây là cô đọng định nghĩa vai trò thành một dòng và làm rõ ràng các ràng buộc dưới dạng danh sách. Điều này hiệu quả token hơn so với văn xuôi và giảm nguy cơ AI bỏ qua các ràng buộc.

Kỹ thuật tối ưu hóa

• Loại bỏ các lời chào hỏi và mở đầu không cần thiết - đi thẳng vào hướng dẫn. Thay "Could you please kindly..." bằng "Do X" tiết kiệm hơn 10 từ mỗi prompt
• Sử dụng danh sách gạch đầu dòng và danh sách đánh số thay vì văn xuôi. Cùng một nội dung cần ít từ nối và từ bổ nghĩa hơn khi đã được cấu trúc hóa, nhờ đó loại bỏ được những token bị lãng phí
• Giới hạn ví dụ few-shot từ 1–3, chọn các trường hợp đại diện nhất
• Sử dụng biến và placeholder để tạo mẫu có thể tái sử dụng
• Viết ở dạng khẳng định ("Do X") thay vì phủ định ("Don't do Y")
• Tóm tắt tài liệu tham khảo dài trước khi đưa vào prompt

Vì việc sử dụng API được tính phí theo token, cắt bớt độ dài prompt chuyển hóa trực tiếp thành chi phí thấp hơn, và điều quan trọng là hiệu ứng này được nhân lên. Tiết kiệm 500 token mỗi yêu cầu, thì với 1 triệu yêu cầu mỗi tháng, sẽ có nửa tỷ token đầu vào đơn giản là không còn được gửi đi nữa. Giá theo token khác nhau tùy mô hình và nhà cung cấp, nhưng một khoản tiết kiệm trông có vẻ không đáng kể trên một yêu cầu đơn lẻ sẽ hiện rõ ngay trên hóa đơn khi bạn vận hành ở quy mô lớn.

Tương tác giữa Temperature và độ dài Prompt

Một yếu tố thường bị bỏ qua trong thiết kế prompt là sự tương tác giữa tham số temperature và độ dài prompt. Temperature kiểm soát tính ngẫu nhiên của đầu ra - giá trị gần 0 tạo đầu ra xác định, trong khi giá trị gần 1 tạo phản hồi đa dạng hơn.

Prompt ngắn kết hợp với temperature cao khuếch đại sự mơ hồ, khiến đầu ra biến đổi mạnh. Ngược lại, prompt chi tiết và có cấu trúc tốt vẫn ổn định ngay cả ở temperature tương đối cao. Như một hướng dẫn thực tế, hãy giữ temperature ở mức thấp khi prompt còn ngắn và mơ hồ, rồi nâng lên khi các hướng dẫn và ràng buộc đã trở nên cụ thể. Làm theo thứ tự đó giúp bạn dễ phân biệt hơn nhiều xem sự biến đổi trong đầu ra đến từ prompt hay từ temperature. Cũng lưu ý rằng tính đến năm 2026, một số mô hình không còn nhận tham số temperature nữa, nên hãy xác nhận trước xem mô hình bạn đang gọi có cung cấp tham số này hay không.

Phương pháp A/B Testing cho Prompt

Tối ưu prompt là quá trình lặp đi lặp lại, không phải nỗ lực một lần. Đây là quy trình A/B testing hiệu quả:

1. Xác định tiêu chí đánh giá: độ chính xác, tính nhất quán phong cách, tuân thủ hướng dẫn - chọn các chỉ số bạn có thể đo lường định lượng
2. Chuẩn bị test case: tập hợp 20–50 đầu vào đại diện, bao gồm các trường hợp biên (đầu vào rất ngắn, đầu vào nhiều thuật ngữ chuyên ngành, đầu vào đa ngôn ngữ)
3. Kiểm soát biến: chỉ thay đổi một yếu tố prompt tại một thời điểm. Sửa đổi cả định nghĩa vai trò và ràng buộc cùng lúc khiến không thể quy kết hiệu quả
4. Đánh giá thống kê: chạy ít nhất 30 lần thử cho mỗi biến thể và tính đến phương sai đầu ra trước khi tuyên bố người thắng

Lưu ý rằng ngay cả khi temperature đặt ở 0, đầu ra mô hình không hoàn toàn xác định. Cùng một prompt có thể tạo ra đầu ra hơi khác nhau giữa các lần chạy, khiến đánh giá thống kê qua nhiều lần thử là cần thiết.

Lỗi Prompt phổ biến và biện pháp khắc phục

• Lạm dụng hướng dẫn phủ định. "Don't do X" khó để mô hình tuân theo một cách đáng tin cậy, và chuyển nó thành hướng dẫn khẳng định sẽ cho đầu ra nhất quán hơn. Khi bạn thực sự cần cấm điều gì đó, việc nêu rõ hành vi thay thế ("làm Y thay vì X") khiến ràng buộc có nhiều khả năng được giữ hơn
• Dán toàn bộ tài liệu tham khảo. Điều này lãng phí không gian cửa sổ ngữ cảnh và do vấn đề Lost in the Middle, khiến mô hình bỏ qua thông tin quan trọng. Hãy tóm tắt trước, hoặc sử dụng RAG để chèn động chỉ các phần liên quan
• Nhầm lẫn số token với số ký tự. Hướng dẫn như "Viết trong 1.000 ký tự" tạo ra mức tiêu thụ token rất khác nhau giữa tiếng Nhật và tiếng Anh. Để kiểm soát độ dài đầu ra đáng tin cậy hơn, hãy chỉ định số đoạn văn hoặc số gạch đầu dòng thay vì số ký tự

Kết luận

Prompt engineering hiệu quả là truyền đạt hướng dẫn chính xác trong ngân sách token hạn chế. Hiểu cơ chế tokenizer BPE, tính đến sự khác biệt hiệu quả token theo ngôn ngữ và cấu trúc prompt có chủ đích là nền tảng. Kết hợp những điều này với biện pháp đối phó Lost in the Middle, nhận thức về tương tác temperature-độ dài và A/B testing lặp đi lặp lại để đạt được cả chất lượng đầu ra và hiệu quả chi phí. Sử dụng Bộ đếm ký tự để kiểm tra độ dài prompt trước khi gửi - nó cũng giúp ước tính mức sử dụng token.