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

• Thư viện tìm kiếm mã được tạo ra để agent có thể ngay lập tức tìm đúng các đoạn mã cần thiết bằng truy vấn ngôn ngữ tự nhiên và mã
• So với grep+read, sử dụng ít hơn khoảng 98% token, và thay vì đọc toàn bộ tệp thì chỉ trả về các chunk liên quan
• Trung bình lập chỉ mục một repo 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
• Kết quả benchmark cho thấy so với CodeRankEmbed Hybrid 137M tham số, lập chỉ mục nhanh hơn 218 lần và vẫn giữ được 99% chất lượng tìm kiếm
• Có thể dùng dưới dạng máy chủ MCP trong Claude Code, Cursor, Codex, OpenCode và các agent tương thích MCP; kho lưu trữ sẽ được clone và lập chỉ mục khi cần, đồng thời chỉ mục được cache trong suốt phiên
• Cũng hỗ trợ cách dùng dựa trên Bash: có thể thêm 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 sử dụng cách này
• CLI nhận cả đường dẫn cục bộ và Git URL https://; nếu bỏ qua path thì sẽ mặc định dùng thư mục hiện tại
• Cũng có thể 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 với SembleIndex.from_path, SembleIndex.from_git, search, find_related
• Cách hoạt động:
  phân đoạn mã nhận biết cú pháp bằng tree-sitter +
  embedding ngữ nghĩa Model2Vec (potion-code-16M) +
  đối sánh từ vựng BM25 được kết hợp bằng RRF (Reciprocal Rank Fusion)
• Nhờ dùng mô hình embedding tĩnh, không cần transformer forward pass khi truy vấn nên chạy ở mức mili giây trên CPU
• Giấy phép 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ử

[roxie]

Đây không phải là bình luận liên quan trực tiếp đến bài viết, nhưng,

Trong AI, có lẽ câu “vì làm được nên đã không nghĩ xem có nên làm hay không” sẽ xảy ra rất thường xuyên

là một câu mà tôi có lẽ sẽ còn nghĩ đến rất lâu.