Tối ưu chi phí token: cách tôi cho AI vận hành kênh YouTube

Tối ưu chi phí token không nằm ở chỗ anh em đi tìm một con model rẻ hơn. Nó nằm ở chỗ anh em giao ít việc hơn cho con model đắt. Bài này tôi chia sẻ đúng con agent đang quản lý kênh YouTube của tôi, và ba tham số tôi kéo xuống để một tháng 200 đô chạy được cả phần marketing của công ty. Cách dựng đội ngũ agent thì tôi đã viết riêng trong bài AI Agent vận hành doanh nghiệp: 3 bước tôi đã làm thật, bài này chỉ nói về tiền.

Video gốc dài 59 phút, đăng ngày 02/08/2026. Bài này thêm bảng giá model có dẫn nguồn chính thức, lược đồ database chép về chạy được luôn, và một mục Giới hạn thật mà video không có thời gian nói.

Bài này đi qua những gì?

1. Vì sao đổi sang model rẻ mà tiền vẫn không giảm
2. Công thức tính tiền token, ba tham số một phép nhân
3. Đơn giá thật của từng con model, và hai kiểu tính tiền
4. Kết quả cuối trông ra sao khi agent trả lời bình luận
5. Bốn bước tôi bóc tách bài toán trước khi mở AI
6. Vì sao lưu bằng file sẽ chết, phải là database
7. Giới hạn thật của cách làm này
8. Việc anh em làm được trong bảy ngày

Vì sao đổi sang model rẻ mà tiền vẫn không giảm?

Vì đơn giá chỉ là một trong ba tham số, và nó thường là tham số nhỏ nhất. Anh em vào diễn đàn thì thấy người ta bàn suốt ngày một chuyện: tôi tìm được con mô hình bên Trung Quốc rẻ bằng một phần ba mà chạy tương đương. Đấy là bàn về đơn giá. Mà đơn giá thì có giảm mấy cũng không cứu được anh em nếu khối lượng công việc đang phình ra.

Tôi lấy đúng bài toán của tôi. Kênh tôi có gần 100 video, có video một tiếng, có video 30 phút, có video 40 phút. Giả sử tôi chỉ tính 50 video, mỗi video 30 phút. Chuyển hết sang transcript dạng chữ thì ra một đống text rất lớn. Bây giờ mỗi lần trả lời một bình luận mà nó phải đọc lại toàn bộ đống transcript đấy để biết bình luận này liên quan tới nội dung nào, rồi nhân với vài trăm bình luận, thì hai con số này nhân với nhau nó khổng lồ.

Lúc đấy anh em chọn model rẻ tới mấy cũng vẫn tốn. Cái số nhân đang to, không phải cái đơn giá đang to.

Công thức tính tiền token gồm những gì?

Tiền anh em trả cho AI bằng khối lượng công việc nhân với số lần làm nhân với đơn giá. Ba tham số, một phép nhân, không có gì bí hiểm.

Anh em thấy công thức này giống hệt công thức tính tiền ngoài đời không? Không khác gì cả. Tôi ví dụ anh em có một tổng đài, cần gọi điện chăm sóc khách hàng.

• Đơn giá là anh em chọn ai gọi. Người 10 năm kinh nghiệm thì trả nhiều tiền hơn.
• Số lần làm là số cuộc gọi.
• Khối lượng là thời gian mỗi cuộc.

Bây giờ so hai phương án. Ông chuyên nghiệp 10 năm kinh nghiệm, gọi đúng một cuộc, mỗi cuộc 5 phút. Ông trung bình, gọi 10 cuộc, mỗi cuộc 60 phút. Anh em thấy chưa chắc thuê ông giỏi đã đắt tiền hơn đâu. Nhân ba số này với nhau mới ra tiền.

Đấy là chỗ mà đa phần người ta bỏ qua. Người ta chỉ nhìn ô thứ ba.

Đơn giá thật của từng con model là bao nhiêu?

Tất cả các hãng đều tính tiền trên một triệu token, và bảng giá là thứ anh em tra được công khai. Cứ search model pricing cộng tên hãng anh em đang dùng.

Số liệu lấy từ trang giá chính thức của Anthropic (docs.claude.com). Token là đơn vị đo. Anh em vứt cho nó một cuốn sách càng dày thì càng nhiều token, càng nhiều tiền. Hiểu đơn giản thế thôi.

Có một chi tiết trong tài liệu của hãng mà tôi thấy đáng nhắc: các đời model mới dùng bộ đếm token khác, cùng một đoạn văn nhưng sinh ra nhiều hơn khoảng 30% token. Nên so giá theo đô trên một triệu token giữa hai đời model không phải phép so ngang bằng.

Thuê bao và API khác nhau chỗ nào?

Thuê bao là trả tiền cố định theo tháng và bị chặn trên bằng hạn mức. API là không chặn, dùng bao nhiêu tính bấy nhiêu theo bảng giá ở trên.

Toàn bộ công ty tôi chạy trên thuê bao. Tôi trả cố định 200 đô một tháng và có một con Claude vận hành từ marketing, tìm kiếm nội dung, lên kịch bản, đề xuất ý tưởng, đề xuất thumbnail, chăm sóc bình luận. Nó còn chạm được sang chăm sóc khách hàng, bán hàng, vận hành dự án. Một nhân sự 200 đô miệt mài làm việc.

Anh em mới bắt đầu thì cứ đi từ gói thuê bao. API mà chưa quen dùng, chưa có bài toán cụ thể, thì đúng là đốt tiền. Rất đơn giản như thế thôi.

Kết quả cuối trông ra sao?

Tôi đưa cho nó một cái link video và bảo trả lời bình luận đi. Nó tự lấy hết bình luận, tóm ý từng người, đề xuất câu trả lời, rồi đăng lên và like. Tôi không phải làm gì hết.

Vì sao chỗ này quan trọng? Vì người trả lời bình luận bằng tay không thể nào nhớ được ba tháng trước mình đã nói điều gì ở video nào, phút thứ mấy. Máy nhớ được. Nên câu trả lời của tôi không dừng ở "cảm ơn bạn đã xem video", nó trỏ thẳng vào chỗ có câu trả lời.

Yêu cầu tôi đặt ra cho nó có hai vế:

1. Bình luận liên quan tới chính video này thì phải trích dẫn được mốc phút trong video này.
2. Bình luận hỏi thứ video này không trả lời, nhưng một video ba tháng trước đã trả lời, thì phải tìm ngược lịch sử và chỉ ra video nào, đoạn nào.

Vế thứ hai chính là chỗ đẻ ra chi phí. Nó phải check ngược lại lịch sử. Mà lịch sử là gần 100 video.

Con số đáng chú ý: câu lệnh tôi gõ trong demo chỉ tốn chưa tới 600 token, và cả lượt chạy skill bên trong chưa tới 800 token. Rất nhỏ. Nhỏ được là vì phần nặng tôi đã đẩy đi chỗ khác từ trước rồi.

Tôi bóc tách bài toán ra sao?

Trước khi mở AI, tôi ngồi trên giấy và tách bài toán thành các kiểu dữ liệu. Mỗi kiểu dữ liệu chọn một nơi lưu và một chiến lược khác nhau. Bản chất là thế. Chưa động tay vào AI gì hết.

Bước 1 · Liệt kê kiểu dữ liệu trước khi mở AI

Kênh YouTube của tôi có ba kiểu dữ liệu: video, bình luận, và người bình luận. Ba kiểu này khác nhau về bản chất nên không thể nhét chung một chỗ.

Anh em chép mẫu này về điền cho bài toán của mình. Điền xong mới mở AI.

PHIẾU BÓC TÁCH BÀI TOÁN TRƯỚC KHI GIAO CHO AI
=============================================

1. BÀI TOÁN
   Việc cần làm         :
   Đầu ra mong muốn     :
   Tiêu chí hoàn thành  :

2. CÁC KIỂU DỮ LIỆU
   Kiểu | Cỡ hiện tại | Có phình theo thời gian không | Nơi lưu | Ai trả tiền
   -----|-------------|-------------------------------|---------|------------
        |             |                               |         |
        |             |                               |         |
        |             |                               |         |

3. KHỐI LƯỢNG
   Mỗi lần chạy, AI phải ĐỌC bao nhiêu chữ ?
   Trong đó bao nhiêu phần BẮT BUỘC do model đắt đọc ?
   Phần còn lại đẩy được cho ai đọc hộ ?

4. SỐ LẦN LÀM
   Một yêu cầu của người dùng đẻ ra bao nhiêu lượt gọi AI ?
   Lượt nào lặp đi lặp lại mà kết quả không đổi ?
   Lượt nào gộp được thành một ?

5. CHỐT
   Việc giữ lại cho model đắt :
   Việc đẩy sang chỗ miễn phí :
   Việc đẩy xuống database    :

Bước 2 · Đẩy transcript sang NotebookLM

Toàn bộ transcript video tôi không đưa vào Claude. Tôi đẩy sang NotebookLM, tên mới của nó bây giờ là Gemini Notebook.

Tại sao? Vì đây là hàng của Google, nó xử lý đống chữ này rất ngon và trả lời chính xác. Quan trọng hơn: phần này tính tiền riêng, mà bản miễn phí đã đủ dùng. Tài liệu chính thức của Google ghi bản miễn phí cho tới 100 sổ ghi chú, mỗi sổ tối đa 50 nguồn (support.google.com). Trong video tôi nói 50 sổ, hoá ra hãng đã nới rộng ra rồi.

Khối lượng mệt nhất là khối lượng đọc. Khối lượng đọc là khối lượng tốn kém nhất. Tôi vứt cho ông làm miễn phí đọc. Đọc xong nó trích ra và trả về đúng một hai dòng: video này, đoạn số bao nhiêu. Con Claude vẫn tốn token để đọc kết quả, nhưng kết quả chỉ có hai dòng.

Nếu lúc đầu anh em vứt nguyên đống transcript vào đầu nó thì nó chết luôn.

Bước 3 · Đưa bình luận và người bình luận vào database

Bình luận và người bình luận thì tôi lưu vào database riêng. Ai đã bình luận, bình luận lúc nào, bình luận thế nào, câu hỏi thuộc loại gì.

Anh em nhìn con số 1,2 nghìn token đấy. Nếu bắt nó tự đọc hết bình luận của gần 100 video để đếm thì con số này gấp mấy trăm lần.

Câu lệnh SQL chạy trên máy tính của tôi. Nó không liên quan gì tới AI, không tốn một đồng nào. Chỗ này miễn phí. Chỗ này cũng miễn phí luôn. Đến khi có danh sách 10 người, mười dòng thôi, thì mới trả về cho Claude. Lúc đấy nó mới ngốn một chút tiền.

Lược đồ ba bảng tôi đang dùng, anh em chép về sửa tên cho hợp bài toán của mình:

-- Ba bang toi dang dung de luu binh luan kenh YouTube
CREATE SCHEMA IF NOT EXISTS yt;

CREATE TABLE yt.videos (
    video_id      TEXT PRIMARY KEY,
    title         TEXT        NOT NULL,
    published_at  TIMESTAMPTZ NOT NULL,
    duration_sec  INTEGER,
    description   TEXT
);

CREATE TABLE yt.commenters (
    channel_id    TEXT PRIMARY KEY,   -- id kenh cua nguoi binh luan
    handle        TEXT,               -- @tenkenh
    display_name  TEXT,
    note          TEXT,               -- ghi chu rieng: hoc vien, khach hang, ban be
    first_seen_at TIMESTAMPTZ,
    last_seen_at  TIMESTAMPTZ
);

CREATE TABLE yt.comments (
    comment_id    TEXT PRIMARY KEY,
    video_id      TEXT        NOT NULL REFERENCES yt.videos(video_id),
    channel_id    TEXT        NOT NULL REFERENCES yt.commenters(channel_id),
    parent_id     TEXT,               -- khac NULL neu la reply
    body          TEXT        NOT NULL,
    like_count    INTEGER     DEFAULT 0,
    published_at  TIMESTAMPTZ NOT NULL,
    replied_at    TIMESTAMPTZ,        -- NULL = chua tra loi
    topic         TEXT                -- loai cau hoi, de thong ke sau
);

-- Ba chi muc nay quyet dinh toc do. Thieu la quet het bang.
CREATE INDEX idx_comments_video   ON yt.comments (video_id);
CREATE INDEX idx_comments_channel ON yt.comments (channel_id);
CREATE INDEX idx_comments_chua_rep ON yt.comments (published_at)
    WHERE replied_at IS NULL;

Cái cột note trong bảng commenters là thứ YouTube không có. Tôi tự thêm vào. Nhờ nó tôi biết người này là học viên coaching, người kia tôi đã quen ngoài đời. Lưu được rồi thì làm được rất nhiều bài toán mà trước đây không làm được.

Tôi ví dụ. Hai tháng trước có người hỏi một câu mà hồi đấy tôi chưa có video nào giải đáp. Bây giờ tôi có rồi. Tôi quay lại gửi cho họ. Anh em nghĩ người ta thấy thế nào?

Bước 4 · Vì sao phải có một thư mục trung gian trên máy?

Vì sau này anh em sẽ có lúc muốn xào nấu lại đống dữ liệu đấy, và lúc đó phải có bản gốc nằm trên máy mình.

Luồng của tôi là YouTube kéo về ổ D trước, lưu dạng file Markdown, rồi mới đẩy lên NotebookLM. Không đẩy thẳng.

Đây là kinh nghiệm làm dữ liệu của tôi. Luôn luôn nên có một file thô ở giữa. Trên máy tôi còn có mấy script chạy xử lý nghiệp vụ khác trên chính đống file đấy.

Vì sao lưu bằng file sẽ chết, phải là database?

Vì file chỉ có đúng một cách tìm là quét hết, còn database có chiến lược thực thi.

Anh em hình dung dữ liệu của mình đang nằm trong một toà chung cư rất lớn. Trong toà đấy có một cô công chúa ở một ô nào đấy mà chúng ta không hề hay biết. Cách tìm thông thường là gì? Là đi tìm tất cả mọi nơi, tất cả mọi nơi, tất cả mọi nơi. Trong thuật ngữ database, cái giải thuật đi tìm tất cả mọi nơi này gọi là full scan.

Full scan thì cực kỳ tốn tài nguyên và cực kỳ chậm. Với file thì nó là cách duy nhất. Chuyện vì sao cùng một câu lệnh lúc nhanh lúc chậm tôi có phân tích kỹ trong bài Tối ưu SQL: cùng một câu lệnh nhưng lúc nhanh, lúc chậm.

Tệ hơn nữa là gì? Là anh em không nhắc gì tới database, để nguyên đống file rồi vứt vào đầu thằng AI. Lúc đấy chính thằng AI của anh em bị full scan. Nó phải quét một đống dữ liệu để tìm. Anh em hãy hình dung số tiền.

Còn khi dữ liệu nằm nhiều nơi mà phải ghép lại với nhau thì trong database gọi là join. Càng nhiều nơi thì càng chậm, càng tốn tài nguyên, và sau này bản chất nó sẽ là tiền của anh em.

Lời khuyên này của tôi không phải lý thuyết. Tôi làm hệ thống gần 15 năm, làm core banking, làm hệ thống chứng khoán từ HNX tới chứng khoán Techcombank, chứng khoán Vietcombank, làm cả hệ thống bệnh viện và bảo hiểm. Thứ tôi thấy đi thấy lại là thế này: lúc dữ liệu còn nhỏ thì lưu vào Excel hay lưu vào database chẳng khác gì nhau. Nó chỉ có vấn đề khi dữ liệu lớn lên.

Nên câu hỏi anh em cần tự đặt lúc bắt đầu chỉ có một câu: dữ liệu này có nhiều lên theo thời gian không? Nếu có thì nghĩ tới database ngay từ đầu.

Và đây là chỗ dễ trượt: nếu anh em không nói rõ, AI sẽ không bao giờ tự dựng database cho anh em. Nó sẽ không bao giờ nó làm. Nó cứ đi theo kiểu full scan rồi vứt hết lên trên, và nó cực kỳ tốn kém. Muốn có thì phải ra đề bài rõ:

Hay cai dat PostgreSQL tren may nay va dung schema "yt" gom ba bang:
videos, commenters, comments (khoa ngoai day du, co index cho cot
video_id, channel_id, va cot loc binh luan chua tra loi).

Sau do khai bao ket noi PostgreSQL vao danh sach cong cu cua anh,
va tu nay ve sau:
  - Moi cau hoi dang thong ke, dem, xep hang, loc theo thoi gian
    thi CHAY SQL, khong doc file tho.
  - Chi doc file tho khi cau hoi doi noi dung nguyen van.
  - Truoc khi chay, in cau SQL ra cho anh xem.
  - Tra ve toi da 50 dong, muon nhieu hon thi hoi lai anh.

Ba dòng cuối là ba cái phanh. Có chúng thì nó không tự tiện kéo cả bảng về nhét vào ngữ cảnh.

Bức tranh tổng gói lại thế nào?

Gói lại thì mỗi kiểu dữ liệu về đúng chỗ của nó, và con model đắt tiền chỉ còn việc ra quyết định.

Ba tham số trong công thức thay đổi thế nào? Đơn giá tôi giữ nguyên, vẫn dùng hàng ngon. Khối lượng tụt xuống vì phần đọc nặng đã có người đọc hộ. Số lần làm tụt xuống vì hàng loạt lượt kiểm tra gộp thành một lượt gọi SQL duy nhất.

Đấy chính là bản chất. Anh em chỉ cần thay đổi hai biến số là khối lượng công việc và số lần gọi, tiền đã tụt hết áp rồi.

Khi mô hình này chạy được thì nó gom lên một chỗ. Tôi giao việc cho một ông CEO agent, ông này tự đọc yêu cầu, tự hiểu ngữ nghĩa, rồi tự tìm xem việc này thuộc phòng ban nào.

Tôi gõ "hãy trả lời các bình luận video mới nhất của tôi". Ông CEO đọc, chuyển sang phòng marketing, phòng marketing giao cho ông quản lý kênh YouTube. Tôi gõ tiếp "hãy chuyển video mới nhất thành bài LinkedIn rồi tạo ảnh sát bài viết", nó giao cho hai ông: ông LinkedIn Writer viết trước, ông thiết kế ảnh làm sau. Cách tôi đóng gói từng ông này thành skill thì nằm ở bài về ba bước dựng đội ngũ AI Agent.

Giới hạn thật của cách làm này là gì?

Có sáu chỗ tôi phải nói thẳng, vì nếu anh em làm theo thì sẽ gặp.

Giá model thay đổi, và có mốc đổi rất gần. Bảng giá tôi để ở trên là giá tại thời điểm viết bài. Tài liệu của Anthropic ghi rõ Sonnet 5 đang ở giá giới thiệu 2 đô đầu vào và 10 đô đầu ra cho tới hết ngày 31/08/2026, từ 01/09/2026 về giá chuẩn 3 đô và 15 đô. Anh em tính toán chi phí thì phải mở lại trang giá, đừng tin bảng trong bài viết nào kể cả bài này.

Tách việc sang chỗ miễn phí là đổi tiền lấy phụ thuộc. NotebookLM miễn phí nhưng Google ghi rõ hạn mức có thể đổi, và hiện tại bản miễn phí chỉ cho 50 lượt hỏi mỗi ngày. Với kênh của tôi thì thừa. Với ai chạy hàng nghìn lượt một ngày thì hạn mức đấy là bức tường.

Database không tự nhiên nhanh. Dựng xong là bắt đầu phải nuôi nó, riêng PostgreSQL còn có chuyện dọn dẹp định kỳ mà tôi có chia sẻ trong bài Vacuum trong PostgreSQL ảnh hưởng tới hiệu năng thế nào. Tôi đưa vào database vì nó có chiến lược thực thi, nhưng nếu anh em không tạo index thì nó vẫn full scan như thường. Ba dòng CREATE INDEX trong lược đồ ở trên không phải trang trí. Mà có index rồi cũng chưa chắc nhanh, chỗ này tôi có phân tích trong bài Vì sao có Index mà câu SQL vẫn chậm và bài Tầm quan trọng của thứ tự các cột trong Index PostgreSQL.

Chuyện dữ liệu dài không dừng ở chuyện tiền. Đây là thứ video chưa kịp nói. Anthropic có bài kỹ thuật nói thẳng: số token trong cửa sổ ngữ cảnh càng tăng thì khả năng model nhớ chính xác thông tin trong đó càng giảm, và chuyện này xảy ra ở mọi model, chỉ khác mức độ (anthropic.com/engineering). Bên nghiên cứu gốc đo trên Claude Sonnet 4, GPT-4.1, Qwen3-32B và Gemini 2.5 Flash cũng ra cùng kết luận: giữ nguyên độ khó, chỉ kéo dài input, hiệu năng vẫn tụt (research.trychroma.com). Nên nhồi cả kho transcript vào ngữ cảnh vừa đắt vừa làm nó trả lời kém đi. Tách việc ra là được cả hai.

Có cách rẻ hơn mà tôi không dùng trong bài toán này. Anthropic công bố prompt caching giảm chi phí tới 90% và độ trễ tới 85% với prompt dài, vì đọc lại từ cache chỉ mất 10% giá token đầu vào (claude.com/blog). Nhưng cache hợp với thứ lặp lại y hệt nhau. Transcript gần 100 video thì mỗi lần cần một mẩu khác nhau, nên tách sang NotebookLM vẫn ăn đứt.

Mô hình này không phải để bán. Tôi làm hệ thống to gần 15 năm rồi nên tôi nói được: anh em không cần hệ thống to. Doanh nghiệp của anh em có phải phục vụ hàng trăm nghìn người đâu. Đừng nhầm áp dụng AI vào công ty với chuyển sang kinh doanh AI. Tôi làm YouTube thì tôi vẫn làm YouTube, chỉ là chất lượng cao hơn.

Bảy ngày tới anh em làm được gì?

1. Ngày 1. Mở bảng giá của hãng anh em đang dùng, chép ba cột vào một file. Biết đơn giá thật trước đã.
2. Ngày 2. Điền phiếu bóc tách bài toán ở trên. Làm trên giấy, chưa mở AI.
3. Ngày 3. Khoanh đúng một việc đang đọc nhiều nhất trong quy trình của anh em. Chỉ một việc thôi.
4. Ngày 4. Tìm chỗ đọc hộ miễn phí cho việc đó. NotebookLM cho tài liệu chữ là chỗ dễ bắt đầu nhất.
5. Ngày 5. Đếm xem một yêu cầu của anh em đang đẻ ra bao nhiêu lượt gọi AI. Gộp những lượt lặp lại thành một.
6. Ngày 6. Dữ liệu nào phình theo thời gian thì dựng database cho nó, chép lược đồ ở trên rồi sửa tên bảng.
7. Ngày 7. Chạy lại đúng việc cũ, so số token trước và sau. Có số rồi mới biết mình làm đúng hay sai.

Cứ làm đi sai lại sửa. Chưa hoàn chỉnh, chưa phải xịn, nhưng chạy được đã.

Câu hỏi hay gặp

Đổi sang model Trung Quốc rẻ hơn có tiết kiệm được không?

Có, nhưng ít. Đơn giá là tham số nhỏ nhất trong ba tham số. Nếu khối lượng và số lần làm đang to thì giảm đơn giá xuống một phần ba cũng chỉ giảm tiền xuống một phần ba, trong khi tách việc có thể giảm hàng chục lần. Sửa hai tham số kia trước.

Không biết lập trình thì có làm được database không?

Làm được. Chính AI dựng database cho anh em. Vấn đề là nó không tự làm nếu anh em không ra đề bài. Chép đoạn đề bài trong mục "Vì sao lưu bằng file sẽ chết" ở trên, sửa tên bảng cho hợp việc của mình, rồi đưa cho nó. Muốn hiểu sâu hơn về chỗ database thì bắt đầu ở bài Tối ưu SQL nên bắt đầu từ đâu.

Có bắt buộc phải dùng Claude không?

Không. Tôi chọn Claude vì tôi muốn từ nay về sau không phải lo nghĩ chuyện đổi model nữa, tôi tập trung vào business. Nguyên lý ba tham số thì con AI nào cũng đúng, vì hãng nào cũng tính tiền trên token.

Gói 20 đô một tháng có đủ chạy không?

Đủ để học và để chạy việc nhỏ. Hạn mức 5 giờ và hạn mức tuần của gói 20 đô nhỏ hơn nhiều so với gói 200 đô. Anh em cứ bắt đầu từ gói nhỏ, khi nào chạm trần thường xuyên thì nâng.

Cách này có dùng được ngoài YouTube không?

Không, chuyển sang nền tảng nào cũng được. Fanpage, livestream, chăm sóc người mua hàng đều dùng chung tư duy này. Chỗ nào có dữ liệu phình theo thời gian và có một con AI đang phải đọc lại từ đầu, chỗ đó dùng được.

Bắt đầu bằng Excel có được không?

Được, nếu dữ liệu còn nhỏ. Nhược điểm lớn nhất của Excel là nhiều lên thì chậm. Anh em cứ bắt đầu bằng CSV hoặc Excel cũng không sao, nhưng biết trước là sẽ phải chuyển, để lúc chuyển đỡ đau.

Đúc kết

Tiền anh em trả cho AI bằng khối lượng nhân số lần làm nhân đơn giá. Đa phần người ta chỉ sửa ô thứ ba, mà ô thứ ba là ô nhỏ nhất.

Việc cần làm là ngồi xuống bóc tách bài toán ra thành các kiểu dữ liệu, rồi hỏi từng kiểu một câu: việc này có bắt buộc do con model đắt nhất làm không? Phần lớn câu trả lời là không.

Anh em thử với đúng một việc trong quy trình của mình, đo số token trước và sau. Phong cách nào cũng được, tuỳ anh em.

Nguồn tham khảo

• Anthropic, bảng giá model chính thức: docs.claude.com/en/docs/about-claude/pricing
• Anthropic, prompt caching giảm chi phí tới 90%: claude.com/blog/prompt-caching
• Anthropic Engineering, context rot và ngân sách chú ý: anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Chroma Research, báo cáo kỹ thuật gốc về Context Rot: research.trychroma.com/context-rot
• Liu và cộng sự, Lost in the Middle, arXiv 2307.03172: arxiv.org/abs/2307.03172
• Google, hạn mức các gói NotebookLM: support.google.com/notebooklm/answer/16269187