Vì sao chúng tôi nâng cấp tìm kiếm mã nguồn lên voyage-4-large

Các con số benchmark trong bài này phản ánh bảng xếp hạng RTEB tại thời điểm xuất bản (tháng 6/2026). Bảng xếp hạng luôn thay đổi; hãy xem các thứ hạng này như một lát cắt thời điểm, không phải một sự thật vĩnh viễn.

Tìm kiếm ngữ nghĩa chỉ tốt bằng đúng lớp embedding nằm bên dưới nó.

Khi một agent hỏi Maguyva “chúng ta xử lý retry ở đâu,” nó không grep tìm từ “retry.” Nó đang hỏi về ý nghĩa — vòng lặp backoff, circuit breaker, thứ bọc quanh một lệnh gọi chập chờn. Câu hỏi đó được trả lời bởi một mô hình vector biến mã nguồn thành một điểm trong không gian rồi tìm các điểm lân cận. Chọn một mô hình tốt hơn và mọi truy vấn ngữ nghĩa trong sản phẩm sẽ âm thầm trở nên sắc bén hơn.

Vì vậy chúng tôi đã đổi mô hình của mình. Kể từ tháng 6/2026, embedding mã nguồn của Maguyva chạy trên voyage-4-large, thay thế voyage-code-3.

Benchmark

Chúng tôi không đưa ra quyết định này dựa trên cảm tính. Retrieval Embedding Benchmark (RTEB) công khai xếp hạng các mô hình embedding trên các tác vụ truy xuất thực tế, và trên bảng xếp hạng Code của nó, voyage-4-large đứng ở vị trí #1 tổng thể (90,86) — vượt qua gemini-embedding-2-preview (90,26) và, đáng chú ý, vượt qua cả mô hình chúng tôi đang dùng, voyage-code-3 (89,73, #3).

Đó là một khoảng cách tuyệt đối nhỏ. Nhưng đó là khoảng cách đúng hướng, trên một benchmark công khai, đúng vào tác vụ chúng tôi quan tâm: truy xuất mã nguồn theo ý nghĩa.

Sự đánh đổi chúng tôi chấp nhận: Lượng tử hóa nhị phân

Đây là phần mà hầu hết các bài viết kiểu “chúng tôi đã nâng cấp mô hình” thường bỏ qua.

Maguyva không lưu trữ vector độ chính xác đầy đủ. Chúng tôi lưu embedding đã lượng tử hóa nhị phân: mỗi vector 2048 chiều được nén thành một chữ ký 2048-bit — 256 byte cho mỗi vector. Những chữ ký đó được tìm kiếm bằng khoảng cách Hamming, được lập chỉ mục và phân vùng theo từng tenant.

Đó là một sự đánh đổi có chủ đích. Lượng tử hóa nhị phân từ bỏ một phần độ chính xác truy xuất để đổi lấy dung lượng lưu trữ nhỏ hơn đáng kể và phép tính khoảng cách nhanh, rẻ, không cần vận hành một cơ sở dữ liệu vector riêng biệt. Với một sản phẩm lập chỉ mục toàn bộ repo cho từng workspace, bài toán kinh tế đó quan trọng hơn việc vắt kiệt phần trăm điểm benchmark cuối cùng.

voyage-4-large phù hợp với thiết kế này mà không buộc phải di trú tầng lưu trữ: nó cho ra đầu ra 2048 chiều, giống như voyage-code-3, nên các cột bit(2048) và đường tìm kiếm Hamming của chúng tôi không phải thay đổi. Mô hình tốt hơn; schema vẫn giữ nguyên.

Mã nguồn chỉ là khởi đầu

Maguyva là một công cụ trí tuệ mã nguồn. Nhưng chúng tôi cũng là khách hàng số 0 của chính mình, và chúng tôi hướng nó vào một thứ khác: các file markdown sống cùng mã nguồn trong repo của chúng tôi. Bản ghi quyết định kiến trúc, runbook, hợp đồng, tài liệu tài chính và chính sách — tất cả đều được quản lý phiên bản trong Git, tất cả đều nằm sau cùng một máy chủ MCP, một chỉ mục ngữ nghĩa trên tài liệu, không chỉ trên mã nguồn.

Đó chính xác là lý do vì sao độ rộng của voyage-4-large quan trọng. Trên cùng họ bảng xếp hạng RTEB đó, nó là #1 về tài chính, #1 về y tế, và #1 về truy xuất văn bản tổng thể — vượt qua Gemini Embedding của Google, Embed v4 của Cohere, và text-embedding-3-large của OpenAI. (Voyage là đồng sáng lập của RTEB, nên chúng tôi xem đây là một tín hiệu công khai mạnh mẽ hơn là một trọng tài hoàn toàn trung lập — nhưng nó vẫn được đối chiếu trực tiếp với mọi mô hình thương mại lớn, trên các tập dữ liệu giữ riêng.) Cùng một chỉ mục tìm ra đúng hàm cho một agent cũng tìm ra đúng điều khoản trong một hợp đồng hoặc đúng dòng trong một chính sách — và trên những lĩnh vực đó, voyage-4-large không phải là một sự thỏa hiệp, nó là kẻ dẫn đầu.

Vì sao chúng tôi trả tiền cho embedding cao cấp

Có một cách rẻ hơn để làm tìm kiếm, và phần lớn trong đó là miễn phí. Tìm kiếm từ vựng — BM25 và họ hàng của nó — khớp từ khóa, chạy cục bộ, và không tốn chi phí gì. Các mô hình embedding mã nguồn mở như BGE, Nomic, và embeddinggemma cho khả năng truy xuất ngữ nghĩa thực sự khá tốt, và bạn có thể tự host chúng với giá của một GPU. Maguyva cũng dùng phía miễn phí: mỗi truy vấn đều hợp nhất tìm kiếm văn bản, AST, đồ thị, và ngữ nghĩa. Thứ chúng tôi không tiết kiệm là tầng ngữ nghĩa.

Chúng tôi trả tiền theo token cho embedding cao cấp — voyage-4-large — thay vì tự host một mô hình miễn phí, vì hai lý do. Thứ nhất, tìm kiếm từ khóa đơn thuần không thể trả lời “chúng ta xử lý retry ở đâu” khi mã nguồn viết backoff và circuit breaker mà chẳng bao giờ dùng từ “retry” — ý nghĩa chính là toàn bộ mục đích của embedding, và trên các lĩnh vực chúng tôi phục vụ, các mô hình mở tụt lại phía sau các mô hình cao cấp: kém vài điểm trên văn bản tổng quát, và kém xa hơn ở các lĩnh vực ngách như mã nguồn, hợp đồng, và tài chính. Thứ hai, theo kinh nghiệm của chúng tôi, chất lượng truy xuất định hình câu trả lời cuối cùng nhiều hơn là mô hình ở đầu bên kia — một agent mạnh được đưa sai ngữ cảnh vẫn trả lời sai, và nó không bao giờ thấy được tài liệu mà nó chưa từng được đưa cho.

Vì vậy embedding cao cấp là một hóa đơn tính theo token, tăng theo mỗi repo và tài liệu chúng tôi lập chỉ mục — và chúng tôi trả nó một cách có chủ đích. Đối với kết quả mà người dùng của chúng tôi nhận được, đúng hàm hoặc đúng điều khoản, chúng tôi nghĩ sự đánh đổi đó là xứng đáng.

Phần thành thật

Tài liệu chính thức của Voyage vẫn gắn nhãn voyage-code-3 là mô hình tối ưu cho mã nguồn. Vậy tại sao lại chuyển đổi?

Vì chúng tôi đọc benchmark công khai, chứ không chỉ bảng mô hình của nhà cung cấp, và benchmark đặt voyage-4-large lên vị trí đầu bảng cho truy xuất mã nguồn. Đây là một quyết định hướng đến tương lai: chọn mô hình mới hơn, nhìn chung mạnh hơn, và xác thực nó dựa trên một bảng xếp hạng công khai cho các tác vụ thực sự quan trọng. Chúng tôi thoải mái đặt cược này vì bằng chứng khá rộng — voyage-4-large không chỉ thắng ở mã nguồn, nó còn dẫn đầu ở tài chính, y tế, và truy xuất tổng thể.

Nền tảng thầm lặng

Mọi công cụ chúng tôi cung cấp — tìm kiếm ngữ nghĩa, thu thập ngữ cảnh tác vụ, hỏi đáp có căn cứ — cuối cùng đều quy về khâu truy xuất. Khi bộ truy xuất được cải thiện, agent ở đầu bên kia nhận được bằng chứng tốt hơn, mắc ít bước sai hơn, và neo câu trả lời của mình vào đúng mã nguồn — hoặc đúng điều khoản, hoặc đúng chính sách. Một mô hình embedding sắc bén hơn không phải là một tính năng phô trương. Nó là nền tảng bên dưới mọi thứ khác, và chúng tôi vừa nâng nó lên. Bạn sẽ không nhận ra điều đó. Đó chính là mục đích.