Token là gì và vì sao chat AI càng dài càng tốn tiền
Anh em đi tìm prompt mẫu rất nhiều. Nhưng cái đơn vị nhỏ nhất mà AI làm việc trên đó thì gần như không ai ngồi tìm hiểu. Đơn vị đó là token. Token quyết định anh em trả bao nhiêu tiền, và token cũng quyết định câu trả lời có chính xác hay không. Bài này tôi viết lại đúng mạch video, cùng với mấy bảng số và hai mẫu prompt mà trong video tôi chưa đủ thời lượng để đưa hết.
Video gốc dài 27 phút. Bài viết bổ sung bảng giá đọc thẳng từ tài liệu hãng, con số đo tiếng Việt tốn hơn tiếng Anh bao nhiêu lần, và hai mẫu prompt chép về dùng luôn.
Bài này đi qua những gì?
- Vì sao đi tìm prompt mẫu mãi mà AI vẫn làm sai
- Token là gì, nhìn tận mắt trên công cụ demo
- Vì sao 10 ký tự lại ra 6 token, và bộ từ điển đó ở đâu ra
- Vì sao tiếng Việt tốn nhiều token hơn tiếng Anh
- Vì sao AI đếm sai chữ R trong quả dâu
- Vì sao chat càng dài càng chậm và càng tốn tiền
- Cache đỡ được bao nhiêu, hết hạn thì sao
- Hai nguyên tắc và hai mẫu prompt để tiêu ít token hơn
Vì sao đi tìm prompt mẫu mãi mà AI vẫn làm sai?
Bởi vì prompt là phần ngọn, còn cách AI cắt chữ thành token mới là phần gốc. Anh em lên mạng, lên diễn đàn, gom về một đống tip trick với prompt mẫu, kỳ vọng AI làm việc tốt hơn. Nhưng anh em chưa dành thời gian tìm hiểu bản chất nó hoạt động thế nào. Tôi thấy rất bất ngờ về chuyện đó.
Không hiểu gốc thì anh em gặp đúng bốn thứ sau:
- AI trả lời rất tự tin, mà kết quả cuối cùng lại sai
- Cứ làm đi làm lại, lòng vòng, không ra cái mình cần
- Chat một lúc là chạm giới hạn gói đăng ký hàng tháng
- Chat càng dài thì nó càng chậm
Bốn thứ này cùng một gốc cả. Chuyện này tôi rút ra từ 15 năm làm công nghệ, đứng đằng sau tối ưu database cho các ngân hàng, công ty chứng khoán và các tập đoàn. Muốn tối ưu database thì việc đầu tiên phải biết database làm việc với đơn vị nhỏ nhất là gì. Biết được đơn vị nhỏ nhất, mình mới hiểu cách nó vận hành. Hiểu cách vận hành rồi mới thiết kế được cho nó chạy ngon.
Với AI thì đơn vị nhỏ nhất đó là token. Được chưa ạ? Mọi thứ anh em gửi vào đều phải chuyển thành token thì nó mới tính toán được. Còn bức tranh rộng hơn về nguyên lý của Agentic AI thì tôi có chia sẻ trong bài Agentic AI, nguyên lý công nghệ và ba căn cứ.
Token là gì?
Token là mẩu chữ đã được cắt ra và đánh số, và đó là thứ duy nhất AI làm việc được. Bản chất nó không hiểu chữ. Nó chỉ tính toán trên số, nên nó phải quy chữ về số trước đã. Tính xong nó lại đổi số ngược về chữ để hiển thị lại cho mình đọc.
Anh em nhìn tận mắt cho dễ hình dung. Tôi gõ "Tôi là Huy" vào công cụ demo tokenizer.
[51, 9769, 72, 39015, 473, 4168], đó mới là thứ thật sự chui vào trong máy.Nhìn con số đó anh em thấy ngay hai điều. Một là số ký tự không bằng số token. Hai là mỗi mẩu được gán một con số. Con số ấy chỉ là số thứ tự trong một cuốn từ điển, chứ số to không hề nặng ký hơn số bé. Đừng nghĩ 39015 thì ghê gớm hơn 51.
Và vì mọi thứ chạy trên token, nên hãng tính tiền trên token. Gửi 6 token thì trả tiền của 6 token. Gửi 100 token thì trả nhiều hơn. Đơn giản thế thôi.
Vì sao 10 ký tự lại ra 6 token?
Vì bộ từ điển của nó không cắt theo ký tự, cũng không cắt theo từ, mà cắt theo cụm hay đi cùng nhau. Chỗ này tôi luôn tự đặt mình vào vai người phải thiết kế ra nó, rồi nghĩ xem có mấy đường đi. Hãy đi từ gốc, đừng đứng nhận kết quả rồi thắc mắc.
Có ba phương án hiện ra trong đầu.
| Phương án | Cách làm | Vì sao hỏng hoặc vì sao được chọn |
|---|---|---|
| Cắt theo ký tự | Quy định A là 1, B là 2, C là 3 | Bảng ký tự hữu hạn, nhưng ghép lại thành từ thì ra tổ hợp khổng lồ. Một đoạn văn thành chuỗi số dài dằng dặc. Quá phức tạp, không ăn thua |
| Cắt theo từ | Lấy nguyên cuốn từ điển, mỗi từ một số | Mai kia đẻ ra từ mới, tiếng lóng của các bạn trẻ thì sao? Từ mới không biểu diễn được là nó chết luôn. Không ổn |
| Cắt theo cụm hay đi cùng nhau | Rà toàn bộ dữ liệu, tìm những cặp liền kề xuất hiện nhiều nhất, gom lại thành một mẩu | Đây là đường được chọn. Từ mới vẫn tách nhỏ ra được, mà từ quen thì gói gọn một token |
Cái tư duy thứ ba này không mới. Nó là một thuật toán nén dữ liệu có từ năm 1994, do Philip Gage viết trên tạp chí The C Users Journal, tên là Byte Pair Encoding. Cách làm của nó đúng một câu: tìm cặp ký tự liền kề xuất hiện thường xuyên nhất trong dữ liệu, rồi thay cặp đó bằng một ký hiệu chưa dùng. Lặp đi lặp lại. Một thuật toán sinh ra để nén ổ đĩa, ba chục năm sau thành nền móng cho cách AI đọc chữ.
Anh em nhìn chữ strawberry cho cụ thể.
str rồi aw rồi berry. Ba mẩu này là ba cụm hay đi cùng nhau trong kho dữ liệu nó học.Đây là chỗ buồn cười. Nếu tôi thêm một dấu cách vào trước chữ strawberry thì nó lại chỉ còn một token. Vì trong kho văn bản mà máy học, chữ này gần như luôn xuất hiện sau một dấu cách, nên cả cụm "dấu cách cộng strawberry" mới là thứ nằm sẵn trong từ điển. Cùng một chữ, thêm đúng một dấu cách, tiền phải trả rơi xuống còn một phần ba.
Con số cũng vậy. Số 100 là một token, vì nó xuất hiện liên tục trong dữ liệu học. Thêm một số 0 thành 1000 thì lại thành hai token. Lạ thật, nhưng đúng là như thế.
Vì sao tiếng Việt tốn nhiều token hơn tiếng Anh?
Vì bộ từ điển kia được dựng chủ yếu trên tiếng Anh, nên chữ tiếng Việt không nằm sẵn thành cụm và bị băm nhỏ ra. Băm càng nhỏ thì càng nhiều token, mà càng nhiều token thì càng nhiều tiền. Anh em nhìn chữ "chuyên nghiệp" đây.
Chuyện này không phải cảm nhận của riêng tôi. Có một nghiên cứu đo hẳn hoi, của nhóm Petrov và cộng sự công bố tại NeurIPS 2023, đo trên 17 bộ tokenizer khác nhau. Với bộ tokenizer của ChatGPT và GPT-4, cùng một nội dung dịch ra các thứ tiếng, số token phình lên như sau.
| Ngôn ngữ | Số token so với tiếng Anh |
|---|---|
| Tiếng Anh | 1,00 |
| Tiếng Pháp | 1,60 |
| Tiếng Đức | 1,58 |
| Tiếng Việt | 2,45 |
| Tiếng Nhật | 2,30 |
| Tiếng Ả Rập | 3,04 |
| Tiếng Shan | 15,05 |
Tiếng Việt tốn gấp 2,45 lần tiếng Anh cho cùng một nội dung. Nghiên cứu đó nói rõ ba hệ quả đi kèm: trả tiền nhiều hơn, chờ lâu hơn, và nhét được ít nội dung hơn vào cùng một cửa sổ ngữ cảnh.
Nên có một việc rất rẻ mà anh em làm được ngay. Chỗ nào không bắt buộc phải ra tiếng Việt thì cho nó trả lời tiếng Anh. Tiền khác hẳn luôn.
Vì sao AI đếm sai chữ R trong quả dâu?
Vì nó không nhìn thấy chữ cái, nó chỉ nhìn thấy token. Đây là bài toán kinh điển mà trước đây người ta hay mang ra chê cười AI. Hỏi trong chữ strawberry có mấy chữ R, mắt thường đếm ra ba, mà máy trả lời hai.
Nhìn lại ảnh cắt bên trên là hiểu ngay. Chữ R thứ nhất nằm lẫn trong mẩu str. Hai chữ R còn lại nằm chung trong mẩu berry. Nó có nhìn thấy từng chữ cái đâu mà đếm. Nó đâu có đếm được.
Các mô hình đời sau đã xử lý được chuyện này rồi. Có nhiều đường để xử lý. Bắt nó tách rời từng ký tự ra trước, chèn dấu phân cách vào giữa, hoặc bắt nó suy luận trước rồi mới trả lời. Nhưng cái đường chắc nhất, và cũng là đường tôi dùng, là đừng bắt nó đếm. Bảo nó viết một câu lệnh đếm chuỗi rồi chạy câu lệnh đó ra kết quả. Một dòng code là xong, chính xác tuyệt đối.
Đây chính là nguyên tắc tôi sẽ nói kỹ ở mục cuối bài.
Vì sao chat càng dài càng chậm và càng tốn tiền?
Vì bản thân con AI không nhớ gì cả. Mỗi lượt anh em gõ một câu, nó phải đọc lại toàn bộ lịch sử hội thoại từ đầu thì mới hiểu mình đang nói chuyện gì.
Tôi làm một phép toán đơn giản cho anh em hình dung. Giả sử mỗi lượt anh em gửi lên 100 token, nó trả về 300 token. Một lượt là 400 token. Đến lượt thứ 10 thì chuyện gì xảy ra? Nó phải gộp toàn bộ 9 lượt trước, tức là 9 nhân 400, rồi cộng thêm 100 token của câu mới. Một câu chat cỏn con ở lượt thứ 10 lại kéo theo một lượng token khổng lồ.
Tất cả chỗ đó chui vào một chỗ gọi là cửa sổ ngữ cảnh. Anh em bật bảng thống kê lên là nhìn thấy nó chứa những gì.
Anh em nhìn cái bảng này rồi tự trả lời được một câu hỏi mà nhiều người hay hỏi tôi: cắm thêm MCP với skill vào có tốn không? Tốn, nhưng tốn ít. Ở đây MCP chiếm 1,1%, skill chiếm 1,0%. Thứ ăn hết chỗ là chính cuộc trò chuyện của mình, 32%. Anh em muốn đỡ tốn thì phải nhìn vào chỗ 32% kia, đừng ngồi cắt mấy phần trăm lẻ. Chuyện AI hay quên và cách cho nó nhớ được việc cũ tôi có phân tích riêng trong bài bộ nhớ AI Agent, vì sao AI hay quên.
Cache đỡ được bao nhiêu, và hết hạn thì sao?
Cache lưu lại phần đã gửi để lượt sau gọi rẻ hơn, nhưng nó có hạn dùng, và hết hạn là phải đọc lại từ đầu. Hãng cũng có sự công bằng nhất định. Cái gì mình đã gửi rồi thì họ giữ lại trên máy chủ của họ, lượt sau đọc lại chỗ đó tính rẻ hơn nhiều.
Anh em nhìn bảng giá chính hãng cho cụ thể.
Rút ra thành bảng cho dễ đọc, lấy dòng Claude Opus 5 và Claude Sonnet 5 làm ví dụ. Đơn vị là đô la trên một triệu token.
| Mô hình | Token đầu vào | Ghi cache 5 phút | Ghi cache 1 giờ | Đọc lại cache | Token đầu ra |
|---|---|---|---|---|---|
| Claude Fable 5 | 10 | 12,50 | 20 | 1 | 50 |
| Claude Opus 5 | 5 | 6,25 | 10 | 0,50 | 25 |
| Claude Sonnet 5 | 2 | 2,50 | 4 | 0,20 | 10 |
Bảng này nói ra ba điều mà anh em nên nhớ.
Thứ nhất, đầu ra đắt gấp 5 lần đầu vào. Cả ba dòng đều đúng tỷ lệ đó, 5 ăn 25, 2 ăn 10, 10 ăn 50. Nên câu trả lời càng dài dòng thì càng đắt. Chỗ này rẻ nhất mà lại hay bị bỏ qua nhất.
Thứ hai, giữ cache lâu thì phải trả thêm. Cache mặc định chỉ sống 5 phút. Muốn nó sống 1 tiếng thì tiền ghi nhảy từ 6,25 lên 10. Tài liệu hãng ghi rõ chỉ có hai mức thời gian đó.
Cách tôi cắt chi phí token cho cả một kênh YouTube chạy bằng AI thì tôi có chia sẻ riêng trong bài tối ưu chi phí token khi cho AI vận hành kênh YouTube.
Thứ ba, đọc lại cache thì cực rẻ. Với Opus 5, đọc lại chỉ 0,50 so với 5 của đầu vào thường, tức rẻ gấp 10 lần. Nhưng rẻ không có nghĩa là không mất tiền. Và để lâu quá không trao đổi, cache hết hạn, là nó phải đọc lại toàn bộ từ đầu.
Làm gì để tiêu ít token mà kết quả chính xác hơn?
Chọn đúng việc cho nó làm, và khoanh vùng dữ liệu trước khi gửi. Chính xác và đỡ tốn tiền nó đi liền với nhau, không phải hai việc khác nhau.
Nguyên tắc một, việc cần chính xác thì bắt nó viết code
Bản chất con AI không làm việc với số, cũng chẳng làm việc với chữ cái. Nó làm việc với token. Nên anh em vứt cho nó một loạt số liệu rồi bảo nó tính, thì nó đang đoán chứ không phải đang tính. Đoán thì có lúc trúng có lúc trượt.
Việc cần chính xác tuyệt đối thì bắt nó viết code hoặc script để chạy ra kết quả. Đếm, đối chiếu, xử lý mã, kiểm tra định dạng, tất cả đều thuộc nhóm này. Dùng tool nào cũng thế thôi, Claude hay Codex đều vậy. Còn phán đoán, diễn giải, viết lách thì để nó làm, đó mới là sở trường của nó. Cách giao việc dữ liệu cho AI tôi có chia sẻ kỹ hơn trong bài AI Agent làm việc với database.
Nguyên tắc hai, cắt phần thừa ở đầu ra
Đầu ra đắt gấp 5 lần đầu vào, nên đây là chỗ tiết kiệm nhanh nhất. Bảo thẳng nó trả lời ngắn gọn, không thưa gửi màu mè, chỉ đưa đúng số liệu và kết quả. Chỗ nào chấp nhận được tiếng Anh thì cho ra tiếng Anh.
Bước 1, khoanh vùng dữ liệu trước khi gửi
Đây là chỗ tôi muốn anh em đổi thói quen. Đừng vứt thẳng cả bảng dữ liệu cho nó rồi bắt làm ngay. Hãy chậm lại một bước. Mô tả bài toán, đưa cấu trúc, đưa vài dòng mẫu, nói tổng số dòng, rồi hỏi ngược lại nó cần gì.
Tôi có một bảng dữ liệu và cần làm việc này: [mô tả việc]
Tôi chưa gửi dữ liệu. Đây là cấu trúc của nó:
Tên các cột: [dán dòng tiêu đề]
Ba dòng mẫu: [dán 3 dòng]
Tổng số dòng: [số]
Dựa vào cấu trúc này, trả lời tôi:
[1] Cần đúng những cột nào? Cột nào bỏ được?
[2] Cần lấy mẫu bao nhiêu dòng, hay bắt buộc chạy trên toàn bộ?
[3] Có tên cột nào mơ hồ mà bạn cần tôi giải thích không?
Trả lời xong tôi mới gửi phần cần thiết.Vì sao tôi hỏi mấy câu đó? Vì tôi muốn loại tối đa dữ liệu thừa trước khi nó chui vào cửa sổ ngữ cảnh. Bỏ được cột nào là giảm token đầu vào chỗ đó. Mà bỏ dữ liệu thừa còn giảm luôn cái sự xao nhãng của nó, nên kết quả chính xác hơn.
Chỗ tổng số dòng đừng bỏ qua. Đây là kinh nghiệm từ các dự án dữ liệu trước đây của tôi, có hệ thống viễn thông lên tới vài tỷ bản ghi. Dữ liệu vài chục nghìn dòng thì giải thuật rất đơn giản. Dữ liệu vài trăm triệu dòng thì giải thuật khác hẳn. Không nói số lượng thì nó chọn cách làm sai ngay từ đầu.
Bước 2, tách việc ra ba phần
Xong bước một rồi vẫn đừng cho nó làm vội. Bắt nó chia việc ra đã.
Trước khi bắt tay vào, tách việc này ra ba phần:
[1] Phần cần chính xác tuyệt đối, số liệu, phép tính, đếm, đối chiếu,
xử lý mã, kiểm tra định dạng. Phần này bạn phải viết code chạy ra
kết quả, không được tự tính rồi trả lời.
[2] Phần cần phán đoán, diễn giải, viết lách. Phần này bạn tự làm.
[3] Phần bạn thiếu dữ kiện. Liệt kê ra và hỏi tôi.
Chỉ liệt kê ba phần đó thôi. Chưa làm gì vội.Việc lớn quá thì chia cho nhiều con làm, mỗi con một phần việc gọn, chỗ này tôi có phân tích trong bài chia việc cho nhiều agent để giảm tiền token.
Đừng làm vội, đừng làm vội. Hãy làm việc với AI chậm một nhịp thôi, anh em sẽ thấy nó hiệu quả hơn hẳn. Cách đặt tiêu chí nghiệm thu cho một việc giao cho AI tôi có chia sẻ trong bài AI Agent làm sai vì thiếu tiêu chí đạt.
Bức tranh tổng, gói lại thành một bảng
| Chỗ tốn token | Vì sao tốn | Việc phải làm |
|---|---|---|
| Câu chat của mình | Chiếm 32% cửa sổ ngữ cảnh, mỗi lượt lại phải đọc lại từ đầu | Mở phiên mới khi đổi việc, đừng kéo lê một phiên dài mãi |
| Dữ liệu thừa gửi vào | Cột không dùng vẫn tính tiền, lại làm nó xao nhãng | Hỏi nó cần cột nào trước, rồi mới gửi |
| Câu trả lời dài dòng | Đầu ra đắt gấp 5 lần đầu vào | Bắt trả ngắn gọn, chỉ số liệu và kết quả |
| Trả lời bằng tiếng Việt | Tiếng Việt tốn gấp 2,45 lần tiếng Anh | Chỗ nào chấp nhận được thì cho ra tiếng Anh |
| Bắt nó tự tính toán | Nó đoán trên token chứ không tính, sai thì phải làm lại từ đầu | Bắt viết code chạy ra kết quả |
| Cache hết hạn | Cache mặc định sống 5 phút, hết hạn là đọc lại toàn bộ | Gom việc làm liền mạch, đừng để đứt quãng lâu |
Giới hạn thật
Đây là phần tôi phải nói rõ, vì mấy chỗ này trong video tôi nói giản lược.
Công cụ demo và bảng giá là của hai hãng khác nhau. Công cụ tokenizer tôi dùng để demo chạy bộ từ điển của GPT-4. Còn bảng giá tôi mở ra lại là của Claude. Mỗi hãng dùng bộ từ điển riêng, nên cùng một câu chữ, số token đếm ra sẽ lệch nhau. Nguyên lý thì giống hệt, còn con số cụ thể thì không mang từ hãng này sang hãng kia được. Muốn biết chính xác thì phải đo trên đúng bộ tokenizer của hãng anh em đang trả tiền.
Nói AI không nhớ là nói về bản thân mô hình, không phải về sản phẩm. Mô hình thì đúng là không nhớ gì thật. Nhưng sản phẩm bọc quanh nó thì có gắn thêm cơ chế nhớ. Nhìn lại đúng cái bảng cửa sổ ngữ cảnh bên trên, anh em thấy có một dòng tên là Memory files, chiếm 1,5k token. Tức là cái gọi là bộ nhớ ấy, bản chất vẫn là gửi lại vào cửa sổ ngữ cảnh dưới dạng token. Nó không phải mô hình tự nhớ ra. Nó là sản phẩm gửi lại hộ mình.
Con số 2,45 lần là đo trên bộ tokenizer của GPT-4, không phải đo trên mọi hãng. Nghiên cứu đó công bố năm 2023. Các hãng vẫn liên tục huấn luyện lại và mở rộng từ điển, nên khoảng cách hôm nay có thể đã khác. Chiều thì vẫn đúng, tiếng Việt vẫn tốn hơn tiếng Anh. Còn tốn hơn đúng bao nhiêu lần thì anh em nên tự đo lại trên chính công cụ mình dùng.
Bài toán đếm chữ R giờ nhiều mô hình đã làm đúng. Nhưng làm đúng không có nghĩa là gốc rễ đã hết. Nó làm đúng vì được huấn luyện thêm hoặc vì biết tự gọi công cụ ra chạy. Cơ chế cắt token thì vẫn y nguyên. Nên luật "việc cần chính xác thì bắt viết code" vẫn còn giá trị, và sẽ còn giá trị lâu.
Giá còn khác nhau giữa các dòng model. Cùng một hãng, chọn dòng nào cũng ra hoá đơn khác hẳn. Chuyện chọn dòng model cho đúng việc tôi có phân tích trong bài Claude Fable 5 và ba thay đổi cho doanh nghiệp.
Bảng giá thay đổi theo thời gian. Số trong bài là số tôi đọc từ tài liệu hãng ở thời điểm quay video. Trước khi tính toán chi phí cho dự án thật, anh em mở lại trang giá chính thức mà đối chiếu.
Bảy ngày tới anh em làm được gì?
- Mở một trang tokenizer, dán thử đúng đoạn prompt anh em hay dùng vào, xem nó ra bao nhiêu token. Dán cả bản tiếng Việt lẫn bản tiếng Anh để thấy chênh lệch.
- Bật bảng cửa sổ ngữ cảnh trong công cụ đang dùng, xem phần nào đang ăn nhiều nhất.
- Chép hai mẫu prompt trong bài này ra một file riêng, để sẵn chỗ nào dễ lấy.
- Chọn một việc dữ liệu anh em hay làm bằng cơm, chạy thử theo hai bước ở trên.
- Trong việc đó, tách rõ phần nào bắt nó viết code, phần nào để nó tự phán đoán.
- Thêm một câu vào cuối prompt quen thuộc: trả lời ngắn gọn, chỉ số liệu và kết quả.
- Đổi thói quen mở phiên. Xong một việc thì mở phiên mới, đừng kéo lê một phiên từ sáng tới tối.
Câu hỏi hay gặp
Token khác gì với từ? Token là mẩu chữ mà máy cắt ra theo bộ từ điển của nó, không cắt theo nghĩa. Một từ tiếng Anh quen thuộc thường gói gọn một token. Một từ tiếng Việt có dấu thường bị cắt thành nhiều mẩu. Chữ "chuyên nghiệp" 13 ký tự bị cắt thành 7 token.
Vì sao chat càng lâu càng chậm? Vì mô hình không nhớ, mỗi lượt nó phải đọc lại toàn bộ lịch sử hội thoại rồi mới trả lời. Lịch sử càng dày thì lượng token phải đọc càng lớn, nên vừa chậm hơn vừa đắt hơn.
Cắm nhiều MCP và skill vào có tốn token không? Có tốn, nhưng tốn ít. Trong bảng đo ở bài này, MCP chiếm 1,1% và skill chiếm 1,0% cửa sổ ngữ cảnh, còn phần chat chiếm tới 32%. Muốn giảm chi phí thì nhìn vào phần chat trước.
Trả lời bằng tiếng Anh thì rẻ hơn bao nhiêu? Theo nghiên cứu của Petrov và cộng sự, cùng một nội dung thì tiếng Việt tốn gấp khoảng 2,45 lần tiếng Anh trên bộ tokenizer của GPT-4. Đầu ra lại đắt gấp 5 lần đầu vào, nên đổi ngôn ngữ đầu ra là chỗ tiết kiệm rõ nhất.
Cache có làm AI trả lời nhanh hơn không? Có. Cache vừa giảm tiền vừa giảm thời gian xử lý, vì phần đã lưu không phải tính lại. Nhưng cache mặc định chỉ sống 5 phút, muốn giữ 1 tiếng thì trả thêm tiền ghi.
Vì sao không nên để AI tự tính toán số liệu? Vì nó làm việc trên token chứ không hiểu con số, nên nó đang đoán ra kết quả. Việc cần chính xác tuyệt đối thì bắt nó viết code chạy ra kết quả, lúc đó mới chắc.
Đúc kết
Hiểu token là hiểu cái đơn vị nhỏ nhất mà AI làm việc trên đó, giống hệt cách tôi tối ưu database suốt 15 năm qua. Biết đơn vị nhỏ nhất thì mới biết chỗ nào đang rò tiền.
Chốt lại có ba việc. Khoanh vùng dữ liệu trước khi gửi. Việc cần chính xác thì bắt nó viết code. Cắt phần thừa ở đầu ra, vì đầu ra đắt gấp 5 lần đầu vào.
Cứ làm đi, sai lại sửa. Anh em thử một việc thôi cũng được, thấy hợp thì làm tiếp, tùy anh em.
Nguồn tham khảo
- Philip Gage, A New Algorithm for Data Compression, The C Users Journal, tập 12 số 2, tháng 2 năm 1994, trang 23 tới 38. Bản dựng lại dạng PDF: derczynski.com/papers/archive/BPE_Gage.pdf
- Aleksandar Petrov, Emanuele La Malfa, Philip H. S. Torr, Adel Bibi, Language Model Tokenizers Introduce Unfairness Between Languages, NeurIPS 2023: arxiv.org/abs/2305.15425
- Orevaoghene Ahia và cộng sự, Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models, EMNLP 2023: aclanthology.org/2023.emnlp-main.614
- Tài liệu Claude Platform, mục Prompt caching, phần thời hạn cache 5 phút và 1 giờ: platform.claude.com/docs/en/build-with-claude/prompt-caching
- Công cụ tokenizer dùng trong video: huggingface.co/spaces/Xenova/the-tokenizer-playground
