ChunkHound — локална база знания за ИИ по вашия код

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 и таймаути при големи файлове.