Semble - tìm kiếm mã cho agent dùng ít hơn 98% token so với grep

• Semble là thư viện tìm kiếm mã được tạo ra để agent có thể ngay lập tức tìm thấy chỉ những đoạn mã cần thiết bằng truy vấn ngôn ngữ tự nhiên hoặc mã
• So với grep+read, nó dùng ít hơn khoảng 98% token và trả về chỉ các chunk liên quan thay vì đọc toàn bộ tệp
• Nó lập chỉ mục một kho mã trung bình trong khoảng 250ms và phản hồi truy vấn trong khoảng 1.5ms, chạy trên CPU mà không cần API key, GPU hay dịch vụ bên ngoài
• Benchmark được thực hiện trên 63 kho mã thuộc 19 ngôn ngữ với khoảng 1.250 truy vấn, và Semble được giới thiệu là đạt 99% chất lượng của CodeRankEmbed Hybrid trong khi lập chỉ mục nhanh hơn 218 lần
• Trong benchmark hiệu quả token, Semble dùng trung bình ít hơn 98% token và đạt 94% recall chỉ với 2k token, trong khi grep+read đạt 85% recall với cửa sổ ngữ cảnh 100k
• Có thể dùng dưới dạng MCP server trong Claude Code, Cursor, Codex, OpenCode và các agent tương thích MCP; kho mã sẽ được clone và lập chỉ mục khi cần, còn chỉ mục được cache trong suốt phiên
• Nó cũng hỗ trợ cách dùng dựa trên Bash, cho phép đưa workflow semble search và semble find-related vào AGENTS.md hoặc CLAUDE.md; các sub-agent của Claude Code và Codex CLI cần dùng cách này
• CLI có thể nhận cả đường dẫn cục bộ lẫn Git URL https://, và nếu bỏ qua path thì thư mục hiện tại sẽ được dùng làm mặc định
• Nó cũng có thể được dùng như thư viện Python, cho phép tích hợp tìm kiếm vào công cụ tùy chỉnh bằng SembleIndex.from_path, SembleIndex.from_git, search, find_related
• Bên trong, nó dùng tree-sitter để chia tệp thành các chunk nhận biết mã, kết hợp embedding potion-code-16M của Model2Vec với BM25, rồi hợp nhất điểm bằng Reciprocal Rank Fusion
• Xếp hạng sử dụng trọng số từ vựng cho truy vấn dạng symbol, tăng điểm cho chunk định nghĩa, khớp stem của identifier, mức liên quan trong cùng tệp, và giảm điểm cho test, legacy, ví dụ, cùng .d.ts
• Vì dùng mô hình embedding tĩnh nên không có transformer forward pass ở thời điểm truy vấn, nhờ đó có thể tìm kiếm ở mức mili giây trên CPU
• semble savings ước tính số token tiết kiệm được bằng cách so sánh tổng số ký tự của toàn bộ các tệp duy nhất chứa chunk trả về với số ký tự của snippet được trả về cho mỗi lần tìm kiếm, và thống kê được lưu trong ~/.semble/savings.jsonl
• Gói có thể được cài từ PyPI dưới tên semble, và khi dùng MCP thì dùng dạng uvx --from "semble[mcp]" semble
• Giấy phép là MIT

[GN⁺]

Ý kiến trên Hacker News

• Khi dùng những công cụ kiểu này, tôi thấy rằng cũng giống như lập trình viên trở nên ngốc đi khi phụ thuộc quá mức vào công cụ AI, bản thân AI cũng trở nên ngốc đi
  AI dạng agent vốn đã đủ thông minh để tìm ra lộ trình khá tối ưu cho việc khám phá hoặc tìm kiếm mã, nhưng khi gắn thêm mấy công cụ này vào thì nó có xu hướng hành động quá hung hăng vì kết quả tìm kiếm gần như lúc nào cũng chỉ đưa con trỏ thay vì toàn bộ chi tiết
  Tôi đã thử đơn giản với Pi, cho nó theo dõi toàn bộ lộ trình thu thập/tìm kiếm trên một dự án tương đối phức tạp; codebase-memory-mcp dùng 85k/4.4k token vào/ra, cấu hình thường dùng của tôi là 67k/3.2k, còn khi không có công cụ nào là 80k/3.2k
  Chất lượng kết quả và lượng thông tin là như nhau, còn công cụ này thì tuy không nhiều nhưng lại tệ hơn
  Cấu hình thường dùng của tôi là chỉ thêm một dòng vào AGENTS.md và CLAUDE.md: “hãy đọc PROJECT.md trước”
  Trong PROJECT.md, tôi chỉ để phần mô tả dự án 2~3 dòng, các tệp liên quan kèm mô tả một dòng, các điểm cần lưu ý, và một câu dành cho LLM kiểu “nếu có thay đổi đáng để cập nhật thì hãy cập nhật tệp này. Mục đích của tệp này là cho bạn cảm nhận khái quát về dự án, rồi từ đó khám phá thêm nếu cần”

  • Câu “AI dạng agent vốn đã đủ thông minh để tìm ra lộ trình tối ưu hóa cao trong việc khám phá hoặc tìm kiếm mã” không khớp với trải nghiệm của tôi
    Ở chỗ làm trước đây tôi dùng Augment Code, và nó có một Context Engine kiểu giống MCP, trả lời truy vấn ngôn ngữ tự nhiên dựa trên mã đã được lập chỉ mục sẵn
    Sau đó tôi chuyển sang Claude Code, nhưng kỳ lạ là dù có công cụ đọc theo phạm vi, nó vẫn cố đọc tệp bằng sed dựa trên các khoảng dòng có trong trí nhớ của nó
    Tôi không chắc điều đó có thực sự là một lộ trình được tối ưu hóa cao hay không
  • codebase-memory-mcp và semble không hoàn toàn giống nhau, nhưng đây là một so sánh thú vị nên tôi sẽ đưa vào danh sách việc cần kiểm tra và nếu có thể sẽ thêm vào benchmark
    Nếu có dịp thử cùng phép so sánh đó với semble thì đó sẽ là phản hồi cực kỳ hữu ích. Những kịch bản “thực tế” kiểu này rất khó benchmark hoặc tái hiện

• Thú vị đấy. Tôi cũng đang làm trong mảng này, nhưng theo hướng khác
  Thay vì tạo chỉ mục, tôi làm một grep thông minh hơn cho toàn bộ codebase và văn bản thường, có thêm xếp hạng và nhận biết cấu trúc mã; phần lớn thời gian tôi dành để xử lý vấn đề hiệu năng nên nó chạy rất nhanh
  Tôi nên thêm nó làm đối chứng với https://github.com/boyter/cs để xem LLM thích gì hơn với kiểu câu hỏi tôi hay đặt
  Nó cũng có MCP, nhưng không tạo chỉ mục tìm kiếm. Nó dùng một biến thể ngữ nghĩa mã thay vì BM25 mặc định, nên tôi khá tò mò thứ hạng sẽ ra sao
  Công cụ này có vẻ hợp hơn với các truy vấn kiểu “xác thực hoạt động như thế nào”, còn cs thì làm authenticate --only-declarations trước, rồi gán trọng số cho kết quả dựa trên nội dung tệp, tức là vị trí khớp nằm trong mã hay trong chú thích, và độ phức tạp tổng thể của tệp
  Tôi đã bấm sao và sẽ theo dõi tiếp

• Tôi biết công cụ này dành cho AI, nhưng tôi còn hứng thú hơn với việc tự dùng nó khi khám phá codebase mới hoặc codebase của chính mình
  Nó có vẻ hữu ích khi tôi muốn thấy toàn bộ đường nét tổng quan để biết cần sửa chỗ nào khi định refactor gì đó
  LSP cũng làm kiểu việc đó, nhưng công cụ này có vẻ có thể tiến thêm một bước

• Tôi đã chạy vài đánh giá với Pi và GPT 5.5
  Tôi thử RTK bật / headroom bật / cả hai bật / cả hai tắt, tất cả đều dùng chỉ thị hệ thống Pi tiêu chuẩn và không có AGENTS.md
  Tôi quên chính xác là những bài test nào, nhưng đó là vài bộ đánh giá agent tiêu chuẩn mọi người hay dùng, gồm một bài Python và một bài TypeScript là hai ngôn ngữ tôi dùng
  Tôi không dám nói đó là đánh giá chặt chẽ hay đánh giá tốt. Có thể nếu tôi dành một ngày chỉnh AGENTS.md cùng prompt hệ thống Pi và chỉ thị công cụ thì kết quả đã tốt hơn. Một điều tôi học được khi chạy đánh giá là những khác biệt tinh vi như vậy có thể làm thay đổi kết quả rất lớn
  Nhưng trường hợp tắt cả hai lại tốt hơn rõ ràng, đủ để tôi dừng test ngay sau 3 vòng
  Vấn đề là dù mức dùng context đôi khi giảm, số lượt cho đến khi hoàn tất lại tăng lên, khiến tổng chi phí hội thoại cao hơn
  Điều này làm tôi càng nhận rõ rằng có rất nhiều người chia sẻ kiểu công cụ này, nhưng hoặc là không có đánh giá nào cả, hoặc khó tái hiện đến mức đáng ngờ, hoặc như công cụ này là chạy rất nhiều benchmark nhưng lại đo nhầm thứ
  Đúng là công cụ này dùng ít token hơn grep và benchmark đã chứng minh điều đó, nhưng đó không phải điều quan trọng. Điều quan trọng là liệu agent có thể dùng công cụ này để làm cùng chất lượng công việc nhanh hơn và rẻ hơn hay không

  • Hiện giờ toàn ngành AI đều đang thiếu kiểm thử
    Đây không chỉ là vấn đề của công cụ này, mà là vấn đề của mọi thứ gắn AI vào codebase hay quy trình phát triển
    Từ trước thời AI người ta vốn đã không có bài test để đo “cái này được phát triển nhanh và tốt đến mức nào”, và đến giờ vẫn chưa bổ sung
  • Trong AI, chuyện “làm được nên cứ làm, chứ không nghĩ xem có nên làm không” có lẽ sẽ xảy ra rất thường xuyên

• Tôi muốn thấy benchmark agent thực sự. Ví dụ như bỏ grep khỏi Claude Code hoặc Copilot CLI rồi thay công cụ này vào
  Tôi đã xem RTK và nhiều triển khai LSP khác nhau, và các model dường như được reinforcement learning quá mạnh với grep, nên chúng không tin các dạng kết quả khác mà cứ thử lại hoặc đọc lại
  Thành ra toàn bộ phần token tiết kiệm được đều biến mất vì model không tin kết quả từ công cụ khác

  • Tôi đã ghi trong CLAUDE.md toàn cục (~/.Claude) là dùng LSP thay cho grep, và từ đó về sau không còn gặp vấn đề này nữa
  • Codex CLI chạy RTK khá ổn. Ít nhất là với GPT 5.5 xhigh thì vậy
    Nhưng tôi khó chịu ở chỗ khi nó không hỗ trợ một số CLI flag nhất định của find, nó lại báo lỗi thay vì gửi toàn bộ đầu ra lệnh
    Khi đó agent hoặc là lãng phí token để thử lại, hoặc tệ hơn là vì prompt mà sợ không dám chạy lệnh nếu không có RTK nên thậm chí chẳng thử luôn
  • Bọn tôi cũng quan tâm đến các benchmark kiểu này, và nó đã nằm trong roadmap cùng với tối ưu prompt và mô tả để model dễ dùng hơn
    Chỉ là mức giai thoại thôi, nhưng tất nhiên chính chúng tôi cũng đang dùng công cụ này và đến giờ nó hoạt động khá tốt
    Các model của Anthropic có vẻ gọi công cụ này và tin vào kết quả của nó
  • Tiết kiệm token ngày càng quan trọng, nhưng việc agent có tin vào kết quả và dừng tìm kiếm hay không cũng quan trọng
    Không nên chỉ nhìn đầu ra tìm kiếm mà phải đo toàn bộ vòng lặp agent
  • Ít nhất Codex sẽ nghe nếu bảo grep thường chậm quá thì dùng rg, nhưng nếu thêm RTK vào thì nó lại dùng grep thông qua RTK, khá bực

• Ý tưởng có vẻ hay nên tôi đã nghịch thử một chút
  Tôi test trên repo browsercode(https://github.com/browser-use/browsercode), và prompt là “chỉ dùng CLI semble, hãy trả lời Browsercode cung cấp những công cụ nào cho agent ngoài các công cụ OpenCode mặc định. Hãy nêu schema chính xác của input/output công cụ, cùng với tóm tắt ngắn gọn chúng làm gì và hoạt động ra sao”
  Tôi đã dán mảnh AGENTS.md từ https://github.com/MinishLab/semble#bash-integration vào
  Trong bài test không dùng Semble, tôi đổi câu hỏi thành chỉ được dùng CLI rg và fd
  Cả hai trường hợp đều dùng Pi và gpt-5.4 medium, còn các thiết lập khác đều được giữ ở mức rất tối thiểu. Tôi cũng xác nhận là thực sự một bên chỉ dùng rg và fd, bên kia chỉ dùng semble
  Không dùng Semble thì hết 10.9% context của model và $0.144 credit API, còn dùng Semble thì hết 9.8% và $0.172
  Câu trả lời kết quả cũng gần như giống nhau, rất sát nhau
  Tôi còn test thêm một lần trên repo OpenCode, với câu hỏi là “hãy lần theo đường đi từ chỗ biến môi trường OPENCODE_EXPERIMENTAL_EXA được đặt thành 1 đến kết quả xuất hiện trong system prompt hoặc công cụ được cung cấp cho agent OpenCode”
  Tôi cũng kèm các chỉ thị và tài liệu giống như trên
  Bản không dùng Semble chi tiết hơn một chút, và có đề cập việc đường gọi công cụ có gọi Exa hay không tùy vào việc Exa hoặc Parallel có được bật làm nhà cung cấp tìm kiếm web hay không, nhưng câu trả lời cho câu hỏi thực tế thì cả hai bản đều đúng
  Bản Semble dùng 14.7% context / chi phí API $0.282, còn bản không Semble dùng 19.0% / $0.352
  Xét về hiệu quả context thì rõ ràng Semble thắng, nhưng đáng chú ý là bản không Semble lại hoàn thành nhanh gần gấp đôi
  Tất nhiên tôi chỉ nghịch thử chút thôi nên kết quả có thể khác

• Câu “dùng ít hơn 98% token so với grep” có phải là bảo tôi tin rằng grep lãng phí đến mức model cứ phải đọc 98% rác vô dụng mỗi lần không?
  Có vẻ tuyên bố này không mang tính đại diện, hoặc là khi vứt đi phần lớn context đưa cho model thì đang bỏ lỡ điều gì khác

  • 98% là so với cả vòng lặp grep+read, không chỉ đầu ra grep
    Khi agent gặp một codebase lạ, nó thường làm cat file trước hoặc đọc cả tệp. Ít nhất trải nghiệm của tôi là vậy
    Nếu bạn đang khiến agent ổn định chỉ làm grep -C N rồi dừng ở đó thì tôi thật sự muốn biết cấu hình đó. Theo tôi chất lượng kết quả như thế quá thấp để dùng làm context hữu ích
  • Tôi từng gặp vấn đề Claude đọc hàng trăm kilobyte đầu ra vì dính các mục trong node_modules
ripgrep có giúp, nên việc thêm một dòng vào tệp bộ nhớ để bảo nó dùng cái đó là hợp lý
  • grep sẽ in ra mọi dòng khớp
    Khi LLM thực hiện một truy vấn tìm kiếm, có thể sẽ rất nhiều nhiễu, và cũng có thể nó phải tìm theo cách đó vì không biết diễn đạt cụ thể hơn
    Tìm kiếm theo mục tiêu có thể giảm số token
    Tuy vậy, so sánh này có vẻ là giữa việc chỉ nhận phần cần thiết với việc đọc cả codebase

• Góp ý một chút thì codex-cli bị treo khi gọi cái này qua MCP
  Tiến trình semble cũng bị kẹt như zombie và treo mãi mãi. Tôi không biết vì sao, log cũng chẳng có gì
  Nếu gọi theo kiểu CLI thông qua skill thì GPT 5.5 lại có xu hướng bắn ra cực nhiều truy vấn tìm kiếm, như thể nó đã quá quen với ripgrep
  Tôi không rõ chuyện đó hiệu quả tới đâu, và chỉ với tài liệu ngắn trên GitHub cùng chỉ thị cho agent thì chưa rõ cái gì là tối ưu
  Cuối cùng, khi cài cho bash tôi cũng gặp vài lỗi liên quan đến kết nối ra ngoài GitHub. Không biết có liên quan đến vụ treo hay không
  Ngoài ra, agent của tôi sau đó vẫn còn định dùng tiếp ripgrep, nên trông như bị trùng lặp. Nó hành xử như thể có vấn đề về độ tin cậy
  Nếu có phần mô tả skill cho agent chi tiết hơn thì có lẽ sẽ hướng agent tới cách dùng đúng hơn

  • Cảm ơn phản hồi chi tiết
    Với lỗi này, sẽ rất tốt nếu bạn có thể mở issue kèm chi tiết cấu hình. Đây chắc chắn là thứ chúng tôi muốn điều tra và sửa
    Vấn đề nó tung ra nhiều truy vấn cũng là phản hồi rất hay; chúng tôi sẽ thử cập nhật prompt và chỉ thị để chuyện này không xảy ra, đồng thời thêm test liên quan
    Lỗi kết nối ra ngoài trong lúc cài đặt có lẽ do uv đang lấy dependency từ PyPI, và có lẽ không phải nguyên nhân gây treo

• Ý tưởng trông ổn đấy
  Nhân tiện nói một vấn đề liên quan, với các codebase nhỏ thì Claude đôi khi có thể đơn giản nhét cả codebase vào context một lần và xử lý với rất ít token, nhưng lại mất nhiều thời gian đi tìm thứ gì đó
  Một cách lách khá ổn là dùng hook khởi động để nạp toàn bộ thư mục vào context
  Như vậy Claude sẽ bỏ qua được đoạn “lần mò trong bóng tối” ở mỗi tác vụ
  Tôi cũng từng thấy một dự án rất hay cho model một bản tổng quan có stub trên các repo lớn hơn, nhưng quên mất tên rồi

  • Có thể là aider chăng? https://aider.chat/2023/10/22/repomap.html
  • Chuẩn đấy. Agent không thực sự biết rõ những gì nó đang nhìn, ví dụ như số lượng tệp hay kích thước tệp
    Tuy nhiên với codebase nhỏ thì thứ bạn muốn tìm cũng dễ tìm hơn, nên tìm kiếm vẫn có thể giúp tiết kiệm chi phí

• Vấn đề lớn hơn của các giải pháp kiểu này là phần lớn AI, nhờ được huấn luyện, vốn đã dùng grep và tìm kiếm rất giỏi
  Khi đưa cho AI một công cụ mới, công cụ đó sẽ lấy đi một phần năng lực nhận thức của AI
  Con người thường sẽ “học” cách dùng những công cụ như vậy, nhưng việc học của LLM thì đã cố định và nó vốn đã rất thành thạo với các công cụ hiện có như grep
  Ví dụ AI đã biết cách khám phá codebase bằng các lệnh Linux như tree, và điều này cũng đã được huấn luyện rất kỹ
  Một vấn đề nữa là rất dễ tạo ra ví dụ cho thấy ích lợi của công cụ như vậy, nhưng lại khó thực sự chứng minh rằng trong các phiên chạy dài, lợi ích đó bù được phần thiếu hụt nhận thức do công cụ gây ra
  Trực giác ban đầu của tôi là trong các phiên chạy dài, trí thông minh có thể triển khai sẽ bị giảm ròng, khiến agent làm tệ hơn so với khi dùng các công cụ sẵn có
  Chứng minh điều ngược lại không phải bài toán đơn giản, nhưng có lẽ đó là một thử thách đáng thử