ChunkHound — локальна база знань для ШІ за вашим кодом
https://github.com/chunkhound/chunkhound
ChunkHound — це локальний інструмент (код залишається на вашій машині), який перетворює репозиторій на «базу знань» для ШІ: він підтримує семантичний пошук («де у нас авторизація?»), regex-пошук (точні збіги) та режим Code Research — «дослідження» коду, яке будує структурований звіт про архітектуру та зв’язки компонентів.
Це виглядає дуже цікаво для використання в AI-IDE. Це прямий аналог індексації в Cursor, але OSS та локальний. Теоретично можна зібрати й віддалений MCP для всієї компанії, якщо він розуміє версійність.
Уявіть, що у вас є «розумний пошук по проєкту»:
- Звичайний пошук (grep/ripgrep) шукає літери/слова.
- Семантичний пошук шукає сенс: ви пишете «перевірка токена», а він знаходить код, навіть якщо там немає слова «token».
- Code Research — це «режим аналітика»: не просто список файлів, а пояснення, як усе влаштовано, з посиланнями на конкретні місця в коді.
Як це працює
- Індексація: ChunkHound сканує проєкт і ріже файли на шматочки («чанки»).
- Розумна нарізка коду (cAST): замість «кожні N символів» він намагається не ламати структуру функцій/класів. Це спирається на дослідження про cAST (chunking через синтаксичне дерево).
- Embeddings: для кожного чанка (і для вашого запиту) будується «вектор сенсу», щоб потім шукати найближчі за змістом шматки.
- Пошук:
- семантичний (за змістом),
- regex (точно за шаблоном),
- опціонально multi-hop: він розширює пошук «за сусідніми пов’язаними темами», щоб зібрати картину цілком (наприклад, «auth» → хешування пароля → сесії → логування).
- Інтеграція з асистентами через MCP: ChunkHound запускається як MCP-сервер, і IDE/асистент викликає його інструменти.
Ключові факти
1) Головна фішка — якість «чанків»
У RAG-системах часто все ламається на банальному: код порізали криво → пошук знаходить уривки → ШІ «розуміє» неправильно. ChunkHound робить ставку на структурну нарізку cAST, що значно покращує якість пошуку та генерації відповідей.
2) «Семантика + regex» = і розумно, і надійно
Семантика корисна для «знайди, де тут логування помилок», але іноді потрібно «знайти всі виклики validateUser». Regex-пошук закриває цей «залізобетонний» сценарій і не потребує ключів API.
3) Два рівні: швидкий пошук та «дослідження архітектури»
У проєкту чітко розділені базовий шар пошуку (семантика/regex) та «оркестрація» (Code Research), яка робить багатопрохідне дослідження та пише звіт.
4) Local-first — корисно для приватних репозиторіїв та швидкості
Проєкт підкреслює «код залишається локально», а зберігання/пошук здійснюється через локальну БД (DuckDB плюс векторний індекс).
5) Проєкт живий і швидко розвивається
За відкритими issues видно, що ще доопрацьовують стабільність: вирішують проблеми з Ollama reranking, MCP disconnects та таймаутами на великих файлах.