LateOn-Code & ColGrep: LightOn công bố các mô hình truy xuất mã và công cụ tìm kiếm mã tiên tiến

Hôm nay, chúng tôi xin giới thiệu LateOn-Code, hai mô hình truy xuất tương tác muộn tiên tiến cho mã nguồn, và ColGrep, một công cụ tìm kiếm di động, cắm và chạy trực tiếp vào các trợ lý lập trình. LateOn-Code có hai kích cỡ thân thiện với người dùng cục bộ: LateOn-Code-edge (17 triệu tham số) cho việc sử dụng siêu nhanh, luôn bật và LateOn-Code (130 triệu tham số) cho chất lượng tối đa trong khi vẫn giữ được sự nhẹ nhàng. Cả hai đều được đào tạo chuyên biệt cho truy xuất mã và vượt trội hơn các mô hình lớn hơn nhiều.

ColGrep là một công cụ dòng lệnh Rust bắt chước giao diện grep quen thuộc nhưng thay thế việc khớp mẫu thuần túy bằng xếp hạng ngữ nghĩa được cung cấp bởi LateOn-Code. Nó chạy hoàn toàn cục bộ, hỗ trợ các truy vấn kết hợp regex và ngữ nghĩa, và tích hợp trực tiếp vào các tác nhân như Claude Code, OpenCode hoặc Codex — chiến thắng 70% các so sánh đối đầu với grep thông thường đồng thời cắt giảm 15,7% lượng token sử dụng.

---

Giới thiệu

Các mô hình tương tác muộn đã cho thấy khả năng vượt trội ngoài miền ứng dụng, hỗ trợ ngữ cảnh dài và truy xuất đòi hỏi suy luận cao. Như Antoine đã trình bày chi tiết trong buổi nói chuyện này, chúng có nhiều điểm tương đồng với các phương pháp từ vựng như BM25: biểu diễn trên mỗi token tránh được việc nén mạnh của các mô hình đơn vector, mang lại cho chúng những điểm mạnh tương tự về truy xuất ngoài miền và ngữ cảnh dài. Nhưng chúng cũng khắc phục được điểm yếu của tìm kiếm từ vựng bằng cách tận dụng học sâu để thực hiện khớp mềm, giúp chúng mạnh mẽ khi truy vấn và tài liệu liên quan không chia sẻ các thuật ngữ chính xác.

Truy xuất mã là một lĩnh vực mà các thuộc tính này đặc biệt liên quan — và nơi tìm kiếm từ vựng vẫn chiếm ưu thế. Nhiều tác nhân lập trình vẫn dựa vào grep cơ bản để điều hướng cơ sở mã, và vì những lý do chính đáng: tìm kiếm ngữ nghĩa thường yêu cầu lưu trữ từ xa mã nhạy cảm và giữ cho chỉ mục đồng bộ với cơ sở mã thay đổi nhanh chóng là khó khăn. Tuy nhiên, những thách thức truy xuất mà các tác nhân gặp phải — tìm kiếm các triển khai liên quan trên các kho lưu trữ không quen thuộc, khớp ý định thay vì từ khóa chính xác — chính là những lĩnh vực mà các mô hình tương tác muộn xuất sắc. Theo hiểu biết của chúng tôi, các mô hình kiểu ColBERT chưa từng được nghiên cứu công khai cho truy xuất mã.

Để lấp đầy khoảng trống này, chúng tôi giới thiệu LateOn-Code, hai mô hình tương tác muộn chuyên biệt cho truy xuất mã. Vì chúng tôi tin rằng truy xuất mã nên được thực hiện cục bộ, cả hai mô hình đều đủ nhỏ để chạy hiệu quả trên CPU trong khi dẫn đầu các bảng xếp hạng vượt xa trọng lượng của chúng. Sau đó, chúng tôi giới thiệu ColGrep, một công cụ dòng lệnh Rust giúp các mô hình này trở nên thiết thực: nó tái tạo giao diện grep mà các tác nhân đã biết, bổ sung nó bằng xếp hạng ngữ nghĩa và truy vấn kết hợp regex + ngữ nghĩa, và chạy hoàn toàn cục bộ với các bản cập nhật chỉ mục tăng dần nhanh chóng. Khi được tích hợp vào các tác nhân lập trình, nó giúp cung cấp câu trả lời tốt hơn đồng thời làm cho nó nhanh hơn và tiêu thụ ít token hơn. Chúng tôi tin rằng đây là những gì tìm kiếm mã cho các tác nhân nên trông như thế nào.

---

Mô hình LateOn-Code

Chúng tôi đã tiền huấn luyện các mô hình LateOn-Code theo phương pháp CoRNStack, sau đó là giai đoạn tinh chỉnh dành riêng cho tác vụ. Thay vì đào tạo từ đầu, chúng tôi bắt đầu với các mô hình đã mạnh về tìm kiếm miền chung, vì truy xuất mã thường liên quan đến ngôn ngữ tự nhiên: người dùng và tác nhân viết truy vấn bằng tiếng Anh thuần túy và tài liệu là văn bản thông thường.

Mô hình cơ sở

Chúng tôi bắt đầu với hai mô hình ColBERT tốt nhất trên điểm chuẩn MTEB (Code) tương ứng với kích thước của chúng. Mô hình đầu tiên là mô hình LateOn nội bộ của chúng tôi, một phiên bản mới của GTE-ModernColBERT-v1 được xây dựng trên ModernBERT-base (cũng được phát triển tại LightOn). Phiên bản này đã trải qua quá trình đào tạo sâu hơn đáng kể, đạt điểm 57 trên BEIR, cải thiện gần 2,5 điểm và do đó dẫn đầu bảng xếp hạng với biên độ lớn. Chúng tôi sẽ phát hành mô hình cơ sở này cùng với dữ liệu đào tạo và các mẫu boilerplate trong tương lai gần, vì vậy hãy theo dõi!

LateOn-Code-edge là một mô hình nhỏ hơn dựa trên gia đình mô hình edge-colbert từ mixedbread, sử dụng biến thể nhỏ nhất (Ettin-17M) để đạt hiệu quả tối đa.

Ngoài việc là các mô hình ColBERT mạnh mẽ, chúng tôi đã chọn các mô hình này vì cả hai đều dựa trên ModernBERT, và ngoài sự hài lòng khi tiếp tục nâng cao các mô hình của riêng mình, chúng tôi biết rằng các mô hình này đã được chế tạo cẩn thận với sự hỗ trợ mã ngay từ đầu.

Đào tạo

Chúng tôi sử dụng dữ liệu CoRNStack để tiền huấn luyện các mô hình của chúng tôi, bao gồm 6 ngôn ngữ (Go, Java, JavaScript, PHP, Python và Ruby). Mỗi mẫu ghép nối một docstring văn bản với hàm tương ứng của nó làm tài liệu tích cực, cùng với các ví dụ tiêu cực được khai thác. Chúng tôi giới thiệu người đọc đến bài báo CoRNStack để biết chi tiết về quy trình tạo dữ liệu.

Vì các ví dụ tiêu cực được khai thác cẩn thận loại bỏ nhu cầu về kích thước batch lớn, chúng tôi đào tạo với thiết lập tinh chỉnh giám sát tiêu chuẩn sử dụng kích thước batch 128. Truy xuất mã liên quan đến các truy vấn và tài liệu dài hơn đáng kể so với các thiết lập truy xuất thông thường. Các mô hình đa vector được biết là có khả năng khái quát hóa tốt cho các tài liệu dài hơn so với trong quá trình đào tạo, điều này ít được thiết lập hơn cho các truy vấn (mặc dù chúng tôi đã quan sát thấy một số khả năng khái quát hóa). Do đó, việc đào tạo trên các đầu vào dài khi có thể vẫn là ưu tiên. Chúng tôi nhận thấy rằng độ dài truy vấn và tài liệu là 256 và 2048 tương ứng bao phủ phần lớn dữ liệu đào tạo. Các giá trị này không đáp ứng được các bộ dữ liệu đánh giá, nhưng chúng tôi không có dữ liệu đào tạo dài hơn.

Chúng tôi đào tạo với học tương phản tiêu chuẩn, đảm bảo mỗi batch chứa các mẫu từ một phân chia ngôn ngữ duy nhất để ngăn chặn việc học phím tắt giữa các ngôn ngữ. Sự khác biệt chính so với thiết lập tương phản PyLate thông thường là lấy mẫu tiêu cực dựa trên softmax từ CoRNStack: thay vì chỉ giữ lại top-k ví dụ tiêu cực hoặc lấy mẫu ngẫu nhiên, chúng tôi sử dụng điểm số khai thác để suy ra xác suất lấy mẫu thông qua softmax. Điều này giữ cho sự tập trung vào các ví dụ tiêu cực khó nhất trong khi vẫn bảo tồn một số sự đa dạng. Chúng tôi lấy mẫu 15 ví dụ tiêu cực cho mỗi truy vấn tại mỗi bước với nhiệt độ 0,05 (tập trung mạnh vào các ví dụ tiêu cực khó nhất). Các tác giả CoRNStack báo cáo rằng một chương trình giảng dạy về nhiệt độ, bắt đầu cao để đa dạng hóa và giảm dần trong quá trình đào tạo, là có lợi. Các bài kiểm tra nhanh của chúng tôi cho thấy không có sự khác biệt đáng kể, vì vậy chúng tôi đã giữ nhiệt độ cố định, mặc dù thử nghiệm kỹ lưỡng hơn có thể mang lại lợi ích trên một số bộ dữ liệu.

Tinh chỉnh

Mặc dù các mô hình tiền huấn luyện của chúng tôi đã đạt được kết quả rất cạnh tranh trên MTEB Code (đặc biệt là trên CodeSearchNetwork), một số đối thủ cạnh tranh đã đạt điểm cao hơn nhiều trên bộ dữ liệu AppsRetrieval trong khi kém hơn hoặc bằng trên các phân chia khác, một khoảng cách ẩn bởi điểm số trung bình. Vì điều này rất có thể là một vấn đề về miền, chúng tôi đã tinh chỉnh trên các tập đào tạo của các bộ dữ liệu CoIR khác nhau. Theo phương pháp luận nv-retriever, chúng tôi lọc bỏ các ví dụ tiêu cực được khai thác với điểm tương tự trên 99% so với điểm tích cực. Chúng tôi giữ lại 50 ví dụ tiêu cực cho mỗi truy vấn, lấy mẫu ngẫu nhiên 15 ví dụ mỗi bước và đào tạo với kích thước batch 128. Để cho phép tái tạo và mở rộng, chúng tôi phát hành dữ liệu chưa lọc với 2048 ví dụ tiêu cực được khai thác cùng với điểm số của chúng, vì vậy bất kỳ ai cũng có thể chọn ngưỡng lọc của riêng mình. Việc tinh chỉnh này cải thiện đáng kể hiệu suất, cả bằng cách thêm các khả năng mới (đào tạo trên các tác vụ ngoài việc chuyển đổi tài liệu sang mã) và bằng cách đưa mô hình vào miền.

Kết quả

Chúng tôi báo cáo kết quả trên điểm chuẩn MTEB (Code, v1) cho cả hai mô hình LateOn-Code cùng với các đối thủ cạnh tranh chính. Do các hạn chế về bộ nhớ, chúng tôi đánh giá các mô hình LateOn với giới hạn độ dài truy vấn và tài liệu tối đa lần lượt là 1024 và 2048. Chúng tôi cũng bao gồm điểm số BM25 làm điểm tham chiếu cho tìm kiếm từ vựng (tương tự grep). Mô tả bộ dữ liệu được cung cấp bên dưới.

Model	Params	Type	Avg	Apps	COIR CSNet	CodeEdit	CodeFB MT	CodeFB ST	CSNet CC	CSNet	CodeTrans Contest	CodeTrans DL	CosQA	StackOF QA	Synth T2SQL
Baseline
BM25	-	Lexical	44.41	4.76	40.86	49.85	59.19	68.15	53.97	60.01	47.78	34.42	18.75	70.26	24.94
Small (≤50M)
granite-embedding-small-english-r2	47M	Single vector	55.84	13.54	60.46	57.16	52.19	76.85	48.42	78.28	77.63	33.63	35.58	90.04	46.33
LateOn-Code-edge-pretrain	17M	Multi vector	57.50	10.81	73.78	62.07	51.92	76.65	63.22	88.03	71.31	33.16	30.53	74.63	53.83
LateOn-Code-edge	17M	Multi vector	66.64	26.22	81.60	62.21	74.25	87.12	79.26	87.85	75.36	37.08	40.54	85.63	62.57
Δ (fine-tune - pretrain)			+9.14	+15.41	+7.82	+0.14	+22.33	+10.47	+16.04	-0.18	+4.05	+3.92	+10.01	+11.00	+8.74
Medium (100M–300M)
granite-embedding-english-r2	149M	Single vector	57.22	13.96	64.65	59.35	52.54	77.18	47.67	80.79	77.07	35.03	37.01	91.80	49.55
CodeRankEmbed	137M	Single vector	60.47	23.45	83.20	59.98	42.61	78.10	68.89	89.50	66.43	34.49	35.17	80.53	63.27
GTE-ModernBERT	149M	Single vector	71.66	57.72	83.10	55.83	86.15	86.00	93.61	88.76	72.35	37.27	43.36	91.14	64.61
embeddinggemma-300m	300M	Single vector	68.76	84.39	75.54	62.10	51.42	80.26	73.71	90.15	85.51	33.52	43.60	86.47	58.42
LateOn-Code-pretrain	149M	Multi vector	63.77	23.09	80.27	68.74	50.21	82.66	71.47	91.05	82.20	34.46	34.15	85.61	61.34
LateOn-Code	149M	Multi vector	74.12	54.76	86.57	64.99	82.22	90.40	89.32	90.40	87.44	41.00	45.23	93.43	63.67
Δ (fine-tune - pretrain)			+10.35	+31.67	+6.30	-3.75	+32.01	+7.74	+17.85	-0.65	+5.24	+6.54	+11.08	+7.82	+2.33
Large (≥500M)
C2LLM-0.5B	500M	Single vector	75.46	61.02	86.71	71.39	92.29	88.63	96.29	89.20	84.27	33.99	38.30	89.40	74.08
Qwen3-Embedding-0.6B	600M	Single vector	75.42	75.34	84.69	64.42	90.82	86.39	91.72	91.01	86.05	31.36	36.48	89.99	76.74

Kết quả tốt nhất trên tất cả các kích thước được gạch chân. Kết quả tốt nhất trong mỗi danh mục kích thước được in đậm.

Tin vào kết quả và muốn thử nghiệm các mô hình/sử dụng dữ liệu? Hãy xem bộ sưu tập HuggingFace.

---

ColGrep

Các tác nhân lập trình tự động như Claude Code tìm kiếm cơ sở mã bằng grep. Chúng tránh tìm kiếm ngữ nghĩa vì những lý do chính đáng: nó thường yêu cầu lưu trữ từ xa mã nhạy cảm và giữ cho chỉ mục đồng bộ với cơ sở mã thay đổi nhanh chóng là khó khăn. Mặc dù tìm kiếm ngữ nghĩa chứng tỏ là hữu ích, đặc biệt đối với các cơ sở mã lớn, các tác nhân vẫn quản lý để tìm thấy những gì họ cần thông qua thử và sai, vậy tại sao phải bận tâm?

ColGrep là câu trả lời của chúng tôi. Đây là một chương trình dòng lệnh Rust tái tạo giao diện grep mà các tác nhân đã biết, nhưng bổ sung nó với các khả năng phát hiện ý định và ngữ nghĩa của các mô hình tương tác muộn. Được cung cấp bởi LateOn-Code và Next-Plaid, cơ sở dữ liệu đa vector của chúng tôi được viết bằng Rust, ColGrep chạy hoàn toàn cục bộ: không có lưu trữ từ xa, không có dịch vụ API riêng biệt và các bản cập nhật chỉ mục tăng dần nhanh chóng được kích hoạt bởi bất kỳ thay đổi tệp nào. Nó được thiết kế đặc biệt cho các tác nhân lập trình như Claude Code, OpenCode hoặc Codex, những người tìm kiếm các chi tiết triển khai liên quan trước khi đề xuất chỉnh sửa hoặc tạo bản vá. Quan trọng là, ColGrep cũng hỗ trợ các truy vấn kết hợp: tác nhân có thể áp dụng các ràng buộc regex trước, giống như họ làm với grep, và sau đó để mô hình ngữ nghĩa xếp hạng các kết quả đã lọc theo ý định, nhận được những điều tốt nhất từ cả hai thế giới.

Lập chỉ mục dự án của bạn

colgrep init ./path/to/your/project

Tìm kiếm

colgrep “kết nối nhóm cơ sở dữ liệu”

Tích hợp với Claude Code

colgrep –install-claude-code

Một phiên điển hình bắt đầu bằng một truy vấn được diễn đạt bằng ngôn ngữ tự nhiên:

Tác nhân lập trình có thể chuyển sang chế độ chi tiết theo yêu cầu và chọn số dòng cần hiển thị:

Phân tích cú pháp

Lần đầu tiên bạn truy vấn ColGrep, nó sẽ quét thư mục hiện tại, mã hóa mọi khối mã tìm thấy và lưu trữ các biểu diễn kết quả trong cơ sở dữ liệu đa vector trên đĩa. Bởi vì cơ sở dữ liệu được nhúng trong client, cả người dùng con người lẫn tác nhân lập trình không cần khởi động hoặc quản lý một dịch vụ API riêng biệt. Giao tiếp giữa client, mô hình và cơ sở dữ liệu vector diễn ra trực tiếp trong Rust thay vì qua HTTP.

Colgrep phân tích cú pháp thư mục hiện tại trong khi tôn trọng các quy tắc bị bỏ qua (từ .gitignore) và loại trừ các thư mục chủ yếu chứa nội dung được tạo hoặc của bên thứ ba. Nó cũng thực thi giới hạn kích thước tệp, làm giảm xác suất các gói được tối ưu hóa hoặc đầu ra máy chiếm ưu thế trong phân phối token. Kết quả là việc lập chỉ mục tập trung vào các phần của kho lưu trữ thường mang lại ý nghĩa.

Phân tích cú pháp Colgrep chuyển đổi các tệp thành các đơn vị mã. Đối với các ngôn ngữ lập trình được hỗ trợ, tree-sitter tạo ra một AST được sử dụng để trích xuất các đơn vị như hàm, phương thức và khối loại. Đối với tài liệu và tệp cấu hình, ColGrep quay trở lại các đơn vị kiểu tài liệu để các tạo tác này vẫn có thể tìm kiếm được. Ở những nơi mà việc trích xuất cấu trúc để lại khoảng trống, hệ thống sẽ phát ra các đơn vị RawCode bổ sung để các câu lệnh cấp cao nhất, các phần nhập khẩu và logic khởi tạo rời rạc vẫn được lập chỉ mục. Thuộc tính phạm vi này rất quan trọng đối với truy xuất, bởi vì nhiều truy vấn “X được cấu hình ở đâu?” sẽ giải quyết các đoạn không nằm trong hàm.

Biểu diễn được gửi đến mô hình không chỉ là mã thô. ColGrep thực hiện phân tích tĩnh theo lớp và tuần tự hóa kết quả thành một dạng văn bản có cấu trúc. Lớp AST cung cấp bằng chứng về giao diện như tên, chữ ký, danh sách tham số, chú thích trả về và nhận xét tài liệu. Lớp đồ thị cuộc gọi thêm ngữ cảnh quan hệ: các lệnh gọi được thu thập trong mỗi đơn vị trong quá trình duyệt AST và sau đó được giải quyết toàn cục để điền vào các trường “gọi” và “được gọi bởi”. Các lớp bổ sung thêm các bản tóm tắt thô về luồng điều khiển, ràng buộc biến và phụ thuộc, với các phụ thuộc được lọc để nhấn mạnh những phụ thuộc được tham chiếu trong đơn vị. Đầu ra là một bản ghi nhỏ gọn nhằm mục đích làm cho đơn vị có thể tìm kiếm theo ý định mà không yêu cầu truy vấn khớp với cú pháp chính xác.

ColGrep hỗ trợ Python, TypeScript, JavaScript, Go, Rust, Java, C, C++, Ruby, C#, Kotlin, Swift, Scala, PHP, Lua, Elixir, Haskell, OCaml, R, Zig, Julia, SQL, Vue và Svelte với phân tích cú pháp tree-sitter đầy đủ để trích xuất cấu trúc, cùng với HTML, Markdown, Văn bản thuần túy, YAML, TOML, JSON, Dockerfile, Makefile, Shell/Bash, PowerShell, AsciiDoc và Org dưới dạng định dạng kiểu tài liệu.

Một ví dụ đơn giản hóa về văn bản được xây dựng trông như thế này:

Vì cơ sở dữ liệu đa vector hỗ trợ cập nhật tăng dần, ColGrep tránh việc lập chỉ mục lại các tệp không thay đổi. Lần đầu tiên chạy, ColGrep tính toán một hàm băm nội dung cho mỗi tệp được lập chỉ mục và lưu trữ nó cùng với các biểu diễn. Các lần chạy tiếp theo, nó so sánh hàm băm hiện tại của mỗi tệp với hàm băm đã lưu. Các tệp có hàm băm khớp sẽ bị bỏ qua hoàn toàn: không phân tích cú pháp, không gọi biểu diễn, không ghi cơ sở dữ liệu. Chỉ các tệp mới hoặc đã sửa đổi mới trải qua toàn bộ quy trình.

Điều này giữ cho chi phí tìm kiếm phù hợp với mẫu phát triển phổ biến là các chỉnh sửa nhỏ và các truy vấn thường xuyên. Một nhà phát triển kéo một nhánh với một vài tệp đã thay đổi chỉ trả tiền cho những thay đổi đó, không phải cho toàn bộ kho lưu trữ. Điều tương tự cũng áp dụng cho các tác nhân lập trình gọi ColGrep lặp đi lặp lại trong một phiên: truy vấn đầu tiên xây dựng chỉ mục, và các truy vấn sau đó được hưởng lợi từ việc khởi động gần như tức thời. Lần tiếp theo tác nhân sẽ tạo ra, nó sẽ tái sử dụng chỉ mục hiện có.

Phương pháp dựa trên hàm băm cũng xử lý việc xóa một cách duyên dáng. Khi một tệp biến mất khỏi cây làm việc, các mục của nó sẽ bị cắt tỉa khỏi cơ sở dữ liệu để các kết quả lỗi thời không bao giờ xuất hiện trong các truy vấn.

Suy luận

ColGrep sử dụng LateOn-Code-edge làm mô hình mặc định, mặc dù nó có thể được thay thế. Nó chạy trên ONNX Runtime và được lượng tử hóa int8 theo mặc định.

Để hỗ trợ xếp hạng đa vector ở độ trễ tương tác, ColGrep sử dụng Next-Plaid. Nó nhóm các vector token thành các tâm và lưu trữ chúng trong một cấu trúc đảo ngược để truy xuất các ứng cử viên mà không cần quét toàn bộ kho ngữ liệu. Nó cũng lượng tử hóa các phần dư để giảm dung lượng lưu trữ và giữ cho việc xếp hạng gần đúng phải chăng. Chỉ mục kết quả được lưu dưới dạng các tệp ánh xạ bộ nhớ, vì vậy các truy vấn có thể chạy mà không cần tải trước mọi thứ vào bộ nhớ và hệ điều hành có thể tải vào chỉ những phần thực sự được truy cập.

Siêu dữ liệu được lưu trữ trong SQLite và ColGrep sử dụng bộ lọc SQL trước khi xếp hạng vector. Điều này hỗ trợ việc sử dụng kết hợp, nơi một ràng buộc từ vựng được áp dụng trước và xếp hạng ngữ nghĩa được áp dụng sau. Ví dụ: một tác nhân có thể yêu cầu các đơn vị ứng cử viên chứa chữ ký hàm bất đồng bộ Rust cụ thể, sau đó yêu cầu xếp hạng ngữ nghĩa trong tập hợp con đó:

Trong thực tế, giai đoạn lọc này cũng là nơi các biểu thức chính quy phức tạp hơn trở nên hữu ích, bởi vì bộ lọc được áp dụng trước khi xếp hạng ngữ nghĩa. Ví dụ, một regex tìm mã đợi futures (có hoặc không có truyền lỗi), sử dụng runtime tokio, hoặc tạo các closure bất đồng bộ chiếm quyền sở hữu môi trường của chúng:

Mặc dù regex không thân thiện với con người, các tác nhân lập trình phần lớn hưởng lợi từ tính năng này và háo hức sử dụng nó. Grep mang đến cho các tác nhân một cách để giảm không gian tìm kiếm xuống các ứng cử viên có liên quan cao. Trong ColGrep, Grep được mô phỏng bằng các truy vấn lọc Sqlite chống lại cơ sở dữ liệu đa vector của chúng tôi.

Một ví dụ khác là tìm kiếm các mẫu thử lại theo kiểu Rust, đồng thời xếp hạng theo ý định về logic quay số lại. Regex giới hạn tập hợp ứng cử viên cho các vòng lặp vô hạn chứa các từ khóa liên quan đến thời gian (sleep, elapsed, timeout, retry, attempt), sau đó truy vấn ngữ nghĩa ưu tiên những thứ triển khai backoff theo cấp số nhân hoặc phục hồi lỗi tạm thời:

Giống như grep, các tìm kiếm có thể được phạm vi theo thư mục, đường dẫn tệp hoặc mẫu phần mở rộng. Tìm 3 hàm công khai hàng đầu trong thư mục xử lý API có liên quan ngữ nghĩa nhất đến việc xử lý điểm cuối, chỉ lọc mã Rust:

Để viết tập lệnh và đánh giá, đầu ra JSON hiển thị siêu dữ liệu tệp, đơn vị và điểm số:

Khi cung cấp cờ -n cho tìm kiếm để chuyển sang chế độ chi tiết, ColGrep chọn các dòng đại diện bằng cách xếp hạng sự chồng chéo token giữa các thuật ngữ truy vấn và văn bản mã. Sau đó, nó tính toán các cửa sổ ngữ cảnh xung quanh các dòng đó, hợp nhất các cửa sổ chồng chéo và đảm bảo rằng chữ ký vẫn hiển thị ngay cả khi dòng đại diện nằm sâu trong thân hàm, chẳng hạn.

Toàn bộ hệ thống được hiểu tốt nhất như một quy trình: duyệt kho lưu trữ xác định kho ngữ liệu, phân tích cú pháp phân chia các tệp thành các đơn vị, phân tích chuyển đổi các đơn vị thành biểu diễn có cấu trúc, biểu diễn tạo ra các tính năng đa vector và chỉ mục kiểu PLAID hỗ trợ xếp hạng tương tác muộn ở độ trễ thấp. Bề mặt dòng lệnh vẫn nhỏ gọn, nhưng trình tự nội bộ được thiết kế rõ ràng để làm cho các truy vấn ở cấp độ ý định trở nên khả thi trên các kho lưu trữ thực tế.

Đánh giá

Chúng tôi đã xây dựng ColGrep để cung cấp cho các tác nhân lập trình một công cụ tìm kiếm hiểu ý định và ngữ nghĩa cũng như hỗ trợ khớp mẫu mờ, để họ có thể tìm mã liên quan mà không cần biết nhận dạng chính xác. Trong thực tế, nhiều tác nhân vẫn dựa vào grep lặp đi lặp lại vì nó thường hoạt động tốt như, hoặc tốt hơn, tìm kiếm vector. Vậy câu hỏi quan trọng là: ColGrep có vượt trội hơn grep truyền thống không? Để trả lời, chúng tôi đã chạy đánh giá có hệ thống trên một số cơ sở mã nguồn mở tiêu chuẩn.

Chúng tôi đã thiết kế điểm chuẩn để trả lời ba câu hỏi. Đầu tiên, ColGrep có giúp tác nhân tìm mã phù hợp không? Thứ hai, ColGrep có giảm tiêu thụ tài nguyên không? Thứ ba, ColGrep có tăng tốc điều hướng không?

Chúng tôi đã sử dụng Claude Opus 4.5 trong Claude Code với hai cài đặt khác biệt để thực hiện đánh giá.

1. Baseline: Claude Opus 4.5 với Claude Code thông thường.
2. ColGrep: Claude Opus 4.5 với Claude Code đã cài đặt ColGrep và mô hình LateOn-Code-edge.

Đánh giá của chúng tôi sẽ tập trung vào việc trả lời câu hỏi về các kho lưu trữ phổ biến có sẵn trên github.

Chúng tôi yêu cầu Claude Code tạo 135 câu hỏi truy xuất mã trải dài ba cấp độ khó. Các câu hỏi dễ yêu cầu các điểm vào đã biết. Các câu hỏi trung bình yêu cầu hiểu ranh giới mô-đun. Các câu hỏi khó mô tả chức năng mà không đặt tên cho việc triển khai. Chúng tôi tạo một phiên Claude Code dành riêng cho mỗi câu hỏi.

Chúng tôi đã tính toán tỷ lệ thắng trên tác vụ trả lời câu hỏi bằng cách phân tích các dấu vết của tác nhân lập trình với Opus 4.5 làm người đánh giá. Nó đã trao điểm cho tác nhân lập trình có dấu vết tốt nhất dẫn đến câu trả lời chính xác.

Cả baseline và ColGrep đều trả lời thành công hầu hết các câu hỏi, nhưng chúng khác biệt rõ rệt về nỗ lực cần thiết để đạt được điều đó. Trong các so sánh đối đầu trực tiếp, Opus 4.5 đánh giá câu trả lời của ColGrep tốt hơn trong 70% trường hợp. Hơn nữa, khi ColGrep được ưu tiên, nó đạt được những chiến thắng đó với ít tương tác hơn đáng kể, giảm khoảng 60.000 token cho mỗi câu hỏi trung bình.

Hiệu suất thay đổi theo kho lưu trữ. ColGrep chiếm ưu thế trong kho lưu trữ Datasets, nơi nó thắng mọi câu hỏi. Nó cũng hoạt động tốt trên các kho lưu trữ Accelerate, Optimum và Transformers. Chúng tôi nghĩ rằng các cơ sở mã này thưởng cho sự hiểu biết ngữ nghĩa vì chúng sử dụng quy ước đặt tên mô tả nhưng không rõ ràng.

Chiến thắng lớn nhất

Một số câu hỏi cho thấy tiết kiệm token đáng kể. 10 trường hợp thành công hàng đầu tiết kiệm từ 159.000 đến 324.000 token mỗi trường hợp: giảm 50% đến 72% so với baseline.

Các câu hỏi khái niệm về bộ nhớ đệm, đồng bộ hóa và cấu hình hưởng lợi nhiều nhất từ tìm kiếm ngữ nghĩa. Các truy vấn này mô tả hành vi thay vì đặt tên trực tiếp cho các hàm.

Ngoại lệ TRL

TRL là kho lưu trữ duy nhất nơi baseline liên tục vượt trội hơn ColGrep. TRL sử dụng tên hàm mô tả rất chi tiết mà grep khớp trực tiếp. Khi câu hỏi chứa bộ nhận dạng chính xác, khớp mẫu sẽ tìm thấy nó ngay lập tức. Tìm kiếm ngữ nghĩa trả về kết quả rộng hơn cần phải tinh chỉnh.

Các câu hỏi khó hơn cho thấy lợi ích lớn hơn. Đối với các câu hỏi dễ, ColGrep thắng 65% trường hợp với mức tiết kiệm khiêm tốn. Đối với các câu hỏi khó, tỷ lệ thắng là 69% nhưng mức tiết kiệm trung bình gần gấp ba lần. Mẫu này có ý nghĩa. Các câu hỏi dễ thường có khớp từ khóa trực tiếp. Các câu hỏi khó mô tả chức năng bằng ngôn ngữ tự nhiên, đó chính xác là những gì các biểu diễn ngữ nghĩa nắm bắt được.

Đối với các nhóm chạy hàng nghìn truy vấn tác nhân mỗi ngày, mức giảm 15,7% cộng lại nhanh chóng. Tuy nhiên, đánh giá của chúng tôi đo lường việc trả lời câu hỏi trên một cơ sở mã lớn, vì vậy kết quả có thể không áp dụng trực tiếp cho các tác vụ lập trình, hoặc chúng có thể mở rộng quy mô khác nhau trong cài đặt đó. Chúng tôi cũng bỏ qua bộ nhớ đệm có thể giảm chi phí để có các so sánh tương đương.

Không phải mọi câu hỏi đều tạo ra lợi ích lớn. ColGrep tiết kiệm token trong 70% câu hỏi. Các chiến thắng tập trung ở nhóm tiết kiệm vừa phải (0–50k), nhưng các chiến thắng lớn (>50k) chiếm 27,5% trường hợp và thúc đẩy phần lớn lợi ích tổng hợp.

ColGrep giảm số lượng thao tác tìm kiếm cần thiết để trả lời một câu hỏi. Các tác nhân baseline liên tục đưa ra các lệnh grep và glob, tinh chỉnh các mẫu cho đến khi chúng tìm thấy những gì chúng cần. ColGrep thường trả về kết quả hữu ích ngay từ truy vấn đầu tiên hoặc thứ hai. ColGrep yêu cầu ít thao tác tìm kiếm hơn 56% so với baseline. Hiệu quả này cộng dồn: ít tìm kiếm hơn có nghĩa là ít lệnh gọi công cụ hơn, ít token hơn được sử dụng cho kết quả trung gian và hội tụ nhanh hơn đến câu trả lời.

ColGrep tiết kiệm nhiều token nhất trong hai tình huống. Đầu tiên, đối với các câu hỏi phức tạp, đặc biệt là những câu hỏi có nhiều token dưới baseline, nơi tìm kiếm ngữ nghĩa giúp điều hướng. Thứ hai, khi nó giảm số lượng lượt, nó thường cũng giảm token vì tìm kiếm trực tiếp hơn.

Nhìn chung, ColGrep thắng cả về số lượt ít hơn và token ít hơn trong 49% câu hỏi. Ngay cả trong 13% trường hợp mất nhiều lượt hơn, nó vẫn tiết kiệm token tổng thể vì mỗi lượt truy xuất các kết quả hữu ích hơn.

Tìm kiếm kết hợp

ColGrep tránh việc buộc phải đánh đổi giữa tìm kiếm ngữ nghĩa và từ vựng bằng cách hỗ trợ các truy vấn kết hợp. Nó trước tiên áp dụng một ràng buộc regex, giống như grep, và sau đó thực hiện xếp hạng ngữ nghĩa trên các kết quả còn lại.

Điều này đặc biệt hữu ích cho các tác nhân lập trình. Một tác nhân có thể yêu cầu các ứng cử viên bao gồm một mẫu cụ thể, chẳng hạn như chữ ký hàm bất đồng bộ hoặc một trình trang trí cụ thể, và sau đó yêu cầu xếp hạng ngữ nghĩa trong tập hợp đã lọc đó. Giai đoạn regex thu hẹp không gian tìm kiếm thành các ứng cử viên có liên quan cao, và sau đó mô hình ngữ nghĩa xếp hạng các kết quả khớp với ý định tốt nhất.

Ví dụ, nếu một tác nhân đang tìm kiếm logic thử lại với backoff theo cấp số nhân, nó có thể bắt đầu bằng cách lọc mã chứa các từ khóa liên quan đến thời gian như sleep, timeout, retry, hoặc attempt, và sau đó xếp hạng các kết quả khớp đó theo sự tương tự với “backoff theo cấp số nhân với phục hồi lỗi tạm thời”. Bộ lọc regex loại bỏ nhiều kết quả dương giả, trong khi xếp hạng ngữ nghĩa đưa các triển khai liên quan nhất lên đầu.

Thiết kế kết hợp này cũng là lý do tại sao ColGrep không chỉ đơn giản thay thế grep. Nó kết hợp điểm mạnh của grep đồng thời mở rộng chúng. Các tác nhân kết hợp lọc từ vựng theo sau là xếp hạng ngữ nghĩa có thể vượt trội hơn cả hai phương pháp được sử dụng riêng lẻ.

Giới hạn

Tác nhân lập trình ColGrep đã nhận được các hướng dẫn được chèn tự động qua một móc nối về cách sử dụng ColGrep thay vì grep. Tuy nhiên, ngay cả với hướng dẫn rõ ràng, các tác nhân vẫn chưa tận dụng đầy đủ khả năng của ColGrep, điều này cho thấy một cơ hội. Một tác nhân được đào tạo đặc biệt hoặc được nhắc nhở mạnh mẽ hơn để sử dụng khám phá ngữ nghĩa, lọc kết hợp và chế độ đầu ra nhẹ nhàng có thể sẽ làm tăng thêm khoảng cách. Tỷ lệ thắng 70% của chúng tôi đến từ một tác nhân đa năng khám phá giá trị của ColGrep một cách hữu cơ, và một tác nhân chuyên biệt có thể đẩy nó cao hơn.

Chế độ chi tiết, nghiên cứu điển hình

ColGrep cung cấp tùy chọn -n chi tiết, bổ sung số dòng và ngữ cảnh mã rộng hơn cho đầu ra của nó. Chúng tôi đã đánh giá cả hai cài đặt và kết quả rõ ràng ủng hộ chế độ nhẹ nhàng mà không cần -n.

Trong thử nghiệm của chúng tôi, chế độ chi tiết tạo ra lượng văn bản gấp khoảng chín lần cho mỗi truy vấn mà không cải thiện độ chính xác. Ngữ cảnh bổ sung đó làm tăng cuộc trò chuyện, thúc đẩy các yêu cầu theo dõi dài hơn và cuối cùng tiêu thụ nhiều token hơn để đạt được câu trả lời tương tự. Khi ColGrep trả về các khối mã lớn hơn, tác nhân cuối cùng sẽ sàng lọc qua tài liệu dư thừa và thường xuyên xem lại cùng một nội dung.

---

Điểm chính

ColGrep cung cấp những lợi ích rõ ràng cho việc tìm kiếm mã ngữ nghĩa. Trong các so sánh đối đầu, nó thắng 70% trường hợp, giảm 15,7% lượng token sử dụng trung bình và xử lý các câu hỏi khái niệm khó tốt hơn so với khớp mẫu thuần túy. Chế độ chi tiết làm tăng chi phí mà không mang lại lợi ích tương ứng, trong khi đầu ra nhẹ nhàng cộng với việc đọc tệp có mục tiêu luôn vượt trội hơn việc mở rộng mã nội tuyến. Đầu ra tối thiểu nên là mặc định.

ColGrep cũng cho phép các truy vấn kết hợp kết hợp lọc regex kiểu grep với xếp hạng ngữ nghĩa. Điều này mở rộng và về cơ bản bao trùm việc khớp mẫu truyền thống thay vì thay thế nó. Các tác nhân kết hợp lọc ban đầu bằng các ràng buộc regex và sau đó áp dụng xếp hạng ngữ nghĩa có thể đạt được kết quả mà không phương pháp nào đạt được riêng lẻ.

Chiến lược tác nhân tốt nhất kết hợp các ý tưởng này: sử dụng ColGrep để khám phá ngữ nghĩa, chuyển sang lọc kết hợp khi bạn biết các mẫu một phần và giữ cho đầu ra nhẹ nhàng trừ khi bạn cần độ chính xác ở cấp độ dòng ngay lập tức. Một tác nhân được đào tạo đặc biệt về các hành vi này có thể vượt qua tỷ lệ thắng 70% đạt được với nhắc chung chung.

Link bài viết gốc

• Tags:
• Ai
• 5 Days Ago
• Huggingface.co