@nobilix TG
Продолжаю про file-first подход к агентам для работы с базами знаний. В прошлом посте рассказал про общий концепт и rclone. В этом посте как и обещал расскажу про поиск по бинарным (не-текстовым) файлам.
Напомню что общая идея - использовать всю мощь передовых кодинг-агентов (в данном случае Claude Code) для задачи работы с базами знаний.
Итак, синхронизация настроена, имеем на быстром диске файлы, но большинство из них в формате Word, PDF, Excel, PowerPoint. По дефолту Claude Code (а точнее в его обертке под названием Agent SDK) доступны все инструменты для поиска по текстовым файлам (grep, ripgrep и тд), но эти файлы не текстовые.
Первая мысль была: ок, давай конвертнем все в plain text (есть же docling, markitdown и тд). Но хотелось чего-то проще, не хотелось строить пайплайн индексации: это и время, и дублирование источника истины, и проблема инвалидации - файлы-то постоянно обновляются. Хотелось найти решение которое работает напрямую с Office файлами.
Эксперименты
Создал тестовое окружение: 150 документов в разных форматах и сравнивал такой шортлист, который мне подкинул deep research:
- ripgrep c расширенными настройками (на самом деле их было больше) - почти сразу отпал
- pdfgrep - прекрасно ищет по PDF файлам
- ugrep - хоть и ищет по всем файлам, но по-началу давал средние результаты, например был хуже pdfgrep для pdf и плохо искал по презентациям, но потом я открыл его суперсилу - фильтры!
Фильтры ugrep - вот где магия
ugrep умеет на лету конвертить файлы через внешние тулы перед поиском. Для этого используется флаг
Пример:
Или еще проще:
Самое крутое - ugrep уже идет с набором преднастроенных фильтров для популярных форматов. В итоге pdfgrep и другие специализированные тулы оказались не нужны -
ugrep еще умеет искать в архивах (zip, tar, gz) без распаковки, поддерживает fuzzy-поиск и regex с Unicode, может выдавать контекст вокруг найденного текста с подсветкой и все это можно конфигурировать через .ugrep конфиг-файл. Короче, швейцарский нож для поиска.
По скорости. На деле с быстрым диском поиск по тысячам документам занимает доли секунды и не является узким местом в агентных сценариях. Но если база огромная и нужна реальная скорость - у ugrep есть встроенная система индексирования через
Далее, чтобы это эффективно работало было несколько раундов работы с промптом агента. Одна из лучших идей оказалась - инструктировать агента сначала запускать команду
Почему file-first - это кайф
Мне нравится работать в file-first экосистеме. Linux - это filesystem-first операционка и в этом мире много сильных инженеров и очень развитый опенсорс. Поражаешься как много эффективных и производительных тулов доступны, они просто работают. Плюс это же все текстовые интерфейсы - CLI + stdin/stdout - кодинговые агенты (считай LLM) с ними на ты. Никаких API оберток, никаких дополнительных слоев абстракции. Просто композиция мощных Unix-тулов.
В будущих постах по этой теме планирую покрыть:
- Другие челленджи: чтение и понимание содержимого нетекстовых файлов
- Когда все-таки нужны индексы или "шпаргалки" (или навигаторы) для таких агентов
- Опыт с Remote MCP и вопросы авторизации
- Подходы к разграничению прав доступа
- Вопросы изоляции (безопасность)
🔥 ➕ 🔁
Напомню что общая идея - использовать всю мощь передовых кодинг-агентов (в данном случае Claude Code) для задачи работы с базами знаний.
Итак, синхронизация настроена, имеем на быстром диске файлы, но большинство из них в формате Word, PDF, Excel, PowerPoint. По дефолту Claude Code (а точнее в его обертке под названием Agent SDK) доступны все инструменты для поиска по текстовым файлам (grep, ripgrep и тд), но эти файлы не текстовые.
Первая мысль была: ок, давай конвертнем все в plain text (есть же docling, markitdown и тд). Но хотелось чего-то проще, не хотелось строить пайплайн индексации: это и время, и дублирование источника истины, и проблема инвалидации - файлы-то постоянно обновляются. Хотелось найти решение которое работает напрямую с Office файлами.
Эксперименты
Создал тестовое окружение: 150 документов в разных форматах и сравнивал такой шортлист, который мне подкинул deep research:
- ripgrep c расширенными настройками (на самом деле их было больше) - почти сразу отпал
- pdfgrep - прекрасно ищет по PDF файлам
- ugrep - хоть и ищет по всем файлам, но по-началу давал средние результаты, например был хуже pdfgrep для pdf и плохо искал по презентациям, но потом я открыл его суперсилу - фильтры!
Фильтры ugrep - вот где магия
ugrep умеет на лету конвертить файлы через внешние тулы перед поиском. Для этого используется флаг
--filter или его алиас `ug+`. Работает просто: ты говоришь "для файлов .docx юзай pandoc, для .pdf юзай pdftotext" и все.Пример:
ugrep --filter="docx:pandoc %f -t plain" --filter="pdf:pdftotext % -" "искомая фраза"
Или еще проще:
ug+ "искомая фраза"
Самое крутое - ugrep уже идет с набором преднастроенных фильтров для популярных форматов. В итоге pdfgrep и другие специализированные тулы оказались не нужны -
ugrep is all you need.ugrep еще умеет искать в архивах (zip, tar, gz) без распаковки, поддерживает fuzzy-поиск и regex с Unicode, может выдавать контекст вокруг найденного текста с подсветкой и все это можно конфигурировать через .ugrep конфиг-файл. Короче, швейцарский нож для поиска.
По скорости. На деле с быстрым диском поиск по тысячам документам занимает доли секунды и не является узким местом в агентных сценариях. Но если база огромная и нужна реальная скорость - у ugrep есть встроенная система индексирования через
ugrep-indexer, которая может дать ускорение в разы.Далее, чтобы это эффективно работало было несколько раундов работы с промптом агента. Одна из лучших идей оказалась - инструктировать агента сначала запускать команду
tree чтобы понять структуру директорий, а потом уже делать таргетированные запросы. Это хорошо фокусирует поиск и помогает агенту лучше ориентироваться в контексте.Почему file-first - это кайф
Мне нравится работать в file-first экосистеме. Linux - это filesystem-first операционка и в этом мире много сильных инженеров и очень развитый опенсорс. Поражаешься как много эффективных и производительных тулов доступны, они просто работают. Плюс это же все текстовые интерфейсы - CLI + stdin/stdout - кодинговые агенты (считай LLM) с ними на ты. Никаких API оберток, никаких дополнительных слоев абстракции. Просто композиция мощных Unix-тулов.
В будущих постах по этой теме планирую покрыть:
- Другие челленджи: чтение и понимание содержимого нетекстовых файлов
- Когда все-таки нужны индексы или "шпаргалки" (или навигаторы) для таких агентов
- Опыт с Remote MCP и вопросы авторизации
- Подходы к разграничению прав доступа
- Вопросы изоляции (безопасность)
🔥 ➕ 🔁
⭐ 48 🔥 249 ❤️ 25 👏 11 🥰 3 💯 3 🆒 3
