---
title:

ChunkHound — локальна база знань для ШІ за вашим кодом

date: 2026-01-18
draft: false
---

https://github.com/chunkhound/chunkhound

ChunkHound — це локальний інструмент (код залишається на вашій машині), який перетворює репозиторій на «базу знань» для ШІ: він підтримує семантичний пошук («де у нас авторизація?»), regex-пошук (точні збіги) та режим Code Research — «дослідження» коду, яке будує структурований звіт про архітектуру та зв’язки компонентів.

Це виглядає дуже цікаво для використання в AI-IDE. Це прямий аналог індексації в Cursor, але OSS та локальний. Теоретично можна зібрати й віддалений MCP для всієї компанії, якщо він розуміє версійність.


Уявіть, що у вас є «розумний пошук по проєкту»:

  • Звичайний пошук (grep/ripgrep) шукає літери/слова.
  • Семантичний пошук шукає сенс: ви пишете «перевірка токена», а він знаходить код, навіть якщо там немає слова «token».
  • Code Research — це «режим аналітика»: не просто список файлів, а пояснення, як усе влаштовано, з посиланнями на конкретні місця в коді.

Як це працює

  1. Індексація: ChunkHound сканує проєкт і ріже файли на шматочки («чанки»).
  2. Розумна нарізка коду (cAST): замість «кожні N символів» він намагається не ламати структуру функцій/класів. Це спирається на дослідження про cAST (chunking через синтаксичне дерево).
  3. Embeddings: для кожного чанка (і для вашого запиту) будується «вектор сенсу», щоб потім шукати найближчі за змістом шматки.
  4. Пошук:
    • семантичний (за змістом),
    • regex (точно за шаблоном),
    • опціонально multi-hop: він розширює пошук «за сусідніми пов’язаними темами», щоб зібрати картину цілком (наприклад, «auth» → хешування пароля → сесії → логування).
  5. Інтеграція з асистентами через 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 та таймаутами на великих файлах.