Hệ thống RAG nào mình từng ship cũng có chung một ràng buộc khó chịu từ ngày đầu: đánh index bằng model nào thì query bằng model đó. Mãi mãi, trừ khi chịu chi phí đánh lại index toàn bộ corpus. Embed 5 của Cohere, ra mắt 30/9, phá vỡ ràng buộc đó một cách có chủ đích. embed-v5.0-pro và embed-v5.0-fast dùng chung một không gian vector. Bạn có thể đánh index bằng Pro rồi query bằng Fast — hoặc ngược lại — mà không cần đánh lại index gì cả.
Đây không phải chiêu khoe benchmark. Đây là một kiến trúc mặc định khác hẳn cho bất kỳ ai chạy retrieval ở quy mô mà lượng query vượt xa lượng document — tức là phần lớn RAG chạy production.
Con số, không phải marketing
Trên 40 bộ dữ liệu gồm text, hình ảnh, document fused, document đã parse, Cohere đo bốn tổ hợp so với baseline Pro-index/Pro-query là 100:
- Index Pro, query Fast: 98.4
- Index Fast, query Fast: 96.6
- Theo chính bài viết của Cohere: lệch model gây mất “1.6% và 2.7% cho query Fast và Pro tương ứng,” và con số này vẫn giữ nguyên qua Matryoshka truncation và int8 quantization — nghĩa là bạn cũng thu nhỏ vector được mà không bị cộng dồn thêm phạt từ việc lệch model.
Trên ViDoRe V3 (benchmark dựng quanh document doanh nghiệp phức tạp về hình ảnh — bảng biểu, PDF scan, layout trộn lẫn), Embed 5 Pro đạt 85.8, Fast đạt 84.5, cả hai đều vượt Voyage 4 Large ở mức 83.7. Throughput: Fast xử lý 377.3 document/giây so với 159.7 của Pro — gấp 2.4 lần.
Giá cả mới là chỗ quyết định kiến trúc thực sự được đưa ra:
| Model | Text | Hình ảnh |
|---|---|---|
| Pro | $0.12 / triệu token | $0.40 / triệu token |
| Fast | $0.08 / triệu token | $0.40 / triệu token |
Giá hình ảnh giống hệt nhau giữa hai tier. Text mới là chỗ việc chia tier đem lại lợi ích, và text cũng là nơi phần lớn hệ thống thực sự chịu khối lượng query.
Vì sao điều này đổi chỗ bạn tiêu ngân sách embedding
Đánh index và query có hồ sơ chi phí hoàn toàn khác nhau trong một hệ thống thật, và phần lớn team vô tình tối ưu sai chỗ vì trước giờ chỉ có một model để tinh chỉnh.
Đánh index: xảy ra một lần cho mỗi document.
khối lượng: giới hạn bởi kích thước corpus
độ chịu latency: cao (batch job, chạy đêm, tùy)
độ chịu chất lượng: gần như bằng không — embedding tệ ở đây
là vĩnh viễn cho tới khi đánh lại index
Query: xảy ra một lần cho mỗi request của user.
khối lượng: không giới hạn, tăng theo traffic, không theo
kích thước corpus
độ chịu latency: thấp (user đang đợi)
độ chịu chất lượng: có chút — bước rerank phía sau có thể
hấp thụ vài điểm recall bị mấtTrước Embed 5, bạn chọn một model, và cả hai hồ sơ trên đều thừa hưởng chi phí và độ trễ của model đó dù có cần hay không. Một hệ thống tìm kiếm ticket hỗ trợ với 50.000 document và 2 triệu query mỗi tháng đang trả giá latency tier Pro và giá tiền tier Pro cho từng query trong 2 triệu query đó, chỉ vì số lượng document chưa bao giờ đủ lớn để biện minh cho việc đổi model và đánh lại index.
Với một không gian vector dùng chung, phía đánh index có thể cho phép mình đắt và kỹ lưỡng — vì đây là chi phí một lần, khấu hao theo cả vòng đời corpus — trong khi phía query được tinh chỉnh đúng với bản chất của nó: một đường dẫn khối lượng lớn, nhạy latency, chịu được chất lượng ở mức vừa phải.
# đánh index một lần, dùng model độ chính xác cao hơn
doc_embeddings = co.embed(
model="embed-v5.0-pro",
input_type="search_document",
texts=documents,
output_dimension=1024,
embedding_types=["float"],
).embeddings.float_
# query bằng model rẻ, nhanh, trên cùng index đó
query_embedding = co.embed(
model="embed-v5.0-fast",
input_type="search_query",
texts=[user_query],
output_dimension=1024,
embedding_types=["float"],
).embeddings.float_Không có gì khác trong pipeline retrieval thay đổi. Cùng vector store, cùng ANN index, cùng distance metric. Việc chọn model chuyển từ một quyết định kiến trúc chốt cứng lúc đánh index thành một tham số runtime bạn có thể bật tắt theo từng request.
Chỗ 1.6-2.7% thực sự đáng quan tâm
Con số mất mát đó không phải nhỏ là bỏ qua được. Tính toán trên chính hệ thống của bạn trước khi bật công tắc:
- Khối lượng query cao, tác vụ dễ tính (tìm FAQ, tra tài liệu nội bộ, bất cứ gì có con người lướt qua top-10 kết quả): cứ lấy mức chiết khấu từ query Fast mà không cần đắn đo. Mức giảm tương đối 1.6% trên tập retrieval top-10 chỉ là nhiễu so với những gì reranker hoặc tính năng “ý bạn là” của giao diện đã hấp thụ sẵn.
- Khối lượng query thấp, tác vụ đòi độ chính xác (tìm kiếm tài liệu pháp lý đưa thẳng vào bước generation không có người review, tìm kiếm tuân thủ nơi thiếu một document là rủi ro thật): ở lại Pro-to-Pro. Lợi ích throughput chẳng mang lại gì nếu khối lượng query chưa bao giờ là nút thắt, và ngưỡng chất lượng quan trọng hơn trần latency.
- Điểm cân bằng thực sự — và đây là trường hợp phần lớn hệ thống RAG chạy production rơi vào — là đánh index bằng Pro, query bằng Fast, rồi đưa qua reranker. Reranker vốn đã ở đó để dọn nhiễu của retrieval; mức giảm 1.6% chất lượng từ tầng embedding đúng là loại lỗi mà cross-encoder reranker sinh ra để bắt. Nếu bạn đã có bước rerank, như bài viết của The New Stack về mô hình “retrieval funnel” đã nói cùng tuần này, bạn đã có khoảng dư trong pipeline dành riêng cho kiểu đánh đổi này.
Thứ mình sẽ kiểm tra trước khi đổi
Mình không tin một con số tổng hợp trên 40 bộ dữ liệu có thể dự đoán chính xác chuyện gì xảy ra trên corpus của riêng mình — benchmark tổng hợp làm mịn đi đúng những trường hợp mà từ vựng hay cấu trúc document của một domain cụ thể lại là chỗ một model nhỏ hơn gãy. Trước khi chuyển một đường query production từ Pro sang Fast:
- Lấy log query thật của bạn, không phải tập eval tổng hợp, chạy cả hai model trên index thật.
- Đo recall@10 và recall@20 cụ thể trên những query mà đội support từng gắn cờ “tìm kiếm không ra câu trả lời hiển nhiên” — đó là tập adversarial của bạn, và nó đáng giá hơn bất kỳ benchmark công khai nào.
- Kiểm tra xem reranker hoặc bước generation phía sau đã bù được phần không hoàn hảo của retrieval chưa. Nếu có rồi, mức 1.6-2.7% gần như miễn phí. Nếu pipeline của bạn không có reranker và kết quả top-1 đi thẳng vào prompt, đúng chỗ đó là nơi một câu trả lời sai được sinh ra với đầy đủ sự tự tin.
Điểm đáng chú ý ở đây không phải “model mới của Cohere nhanh hơn.” Mà là việc chọn embedding model không còn là một quyết định không thể đảo ngược chốt cứng trong index, mà trở thành một tham số bạn tinh chỉnh theo từng code path dựa trên cái path đó thực sự cần gì. Đó là một hình dạng hữu ích hơn nhiều cho một hệ thống production, so với thêm nửa điểm benchmark nữa.