#llm #petproject

Великий rclone (или иногда агенту нужны просто файлы)

Делаем агента для европейской маркетинговой компании. Они год мучались с RAG - индексировали, чанкали, перебирали эмбединги, то лагает, то галлюцинирует, то не находит нужное.

Предложил радикально другой подход: выкинуть RAG, вместо этого - Claude Agent SDK + обычная файловая система и MCP как интерфейс. Сделал им прототип - результат настолько лучше, что сначала не поверили. Сравнить можно +/- с тем, насколько Claude Code лучше чем обычный AI чат в кодинге. Поиск по гигабайтам PDF, DOCX, PPTX - доли секунды. Залетает новый файл - агент сразу готов его учитывать. Никакого чанкинга, никакой индексации. По сути - это то же самое что Claude Code или Codex CLI делают с кодовой базой, только тут вместо code base у нас knowledge base.
Но есть нюанс, и даже несколько. Вообще, планирую серию постов на эту тему, начну с проблемы синхронизации файлов и ее решения.

Итак, проблема. Основной источник знаний в их случае - Google Drive. Там все: презентации клиентам, стратегии, исследования. Но делать квери туда - слишком долго и мы ограничены только встроенным поиском драйва - не пойдет. Нам нужно чтобы Claude Code (Agent SDK) шустро шуршал по файлам.

Решение - rclone

Rclone - это как rsync для облачных хранилищ. Поддерживает Google Drive, OneDrive, Dropbox и десятки других. Крутая штука: умеет автоматически экспортировать форматы. Google Docs превращается в .docx, Sheets в .xlsx, презентации в .pptx и тд.

rclone sync "gdrive:/" "/local/path" --drive-export-formats docx,xlsx,pptx

Файлы летят на сервер, конвертируются, агент работает с ними как с обычными файлами.

Почему file-first лучше

Storage дешевый и быстрый. Иногда (особенно для использования внутри компании) куда проще загрузить все на диск и работать с файлами напрямую, чем городить удаленный инджестинг с векторными базами и пайплайн индексации.

Современные CLI агенты прекрасно справляются с файловым поиском. "Найди все упоминания проекта X за последние 3 месяца" - делает за секунды через обычные файловые операции. Когда нужно читает файлы по частям или целиком. А еще на лету пишет скрипты для работы с ними если надо (!), собственно эту концепцию сейчас и продвигают Антропик со своими Skills.


В общем, если строите агента для работы с документами:
- Посмотрите на file-first подход. Может быть быстрее и надежнее RAG.
- Используйте rclone для синхронизации облачных хранилищ.
- Дайте агенту доступ к файловой системе и нормальным тулам поиска - часто лучше наивного RAG.

---

Этот проект оказался интереснее чем я ожидал. Куча нюансов, неочевидных решений и инсайтов, которыми буду делиться дальше. Продолжение следует.

#llm #rag #search #petproject

Продолжаю про 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 умеет на лету конвертить файлы через внешние тулы перед поиском. Для этого используется флаг --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 и вопросы авторизации
- Подходы к разграничению прав доступа
- Вопросы изоляции (безопасность)

🔥 ➕ 🔁 поддержите если хотите больше на эту тему

Никак не мог понять почему SDXS так плохо генерит короткие промпты

Те если описание длинное то все более менее хорошо, но если дать короткое - например dog или собака - все разваливалось

Сперва думал дело в датасете - нужно чтобы были равномерно представлены разные типы описаний, как короткие так и длинные

Добавил больше коротких - стало хуже. Дело в том, что например было длинное описание черно-белая иллюстрация небоскреба, вид снизу бла-бла-бла

При сокращении ЛЛМ-кой описание она превращается во что то типа "вид снизу на небоскреб устремленный в небеса - и прочие галлюцинации символизирующие что то там"

В итоге у меня самурай стал черно белым, тк ллм считает часть про черно белую иллюстрацию менее существенной, чем описание того, что собственно на картинке

Как оказалось дело было в паддингах. При добивании до одинакового батч сайз - например 150 (выравнивание нужно для обучения) пустой текст заменяется на служебные пад токены. Выравниваться может как слева так и справа, типа
пад пад .. собака
или
собака пад пад..

Казалось бы ну и хрен с ним. Но у падов есть значения типа 0.1 0.2 Токен_собаки
Те пад добавляет мусорные числа в вектор - которые не только замедляют обучение - "запутывая" диффузию но и мешают выучить токен

Поэтому длинные описания учили лучше и работали лучше (ну я так думаю)

Для решения этой проблемы можно взять маску внимания 1, 0, 0 - где 0 - соотвествует позиции пад токена

И умножив на нее - получить чистый скрытый слой в котором не будет мусора пад токенов

Хорошо что я это понял. Плохо что опять переучивать придется

такой день

История autonomous driving от Антона Слесарева

Современная история autonomous driving началась в 2007-м. Сразу несколько команд сделали решение, автономно ездящее в игрушечном городе несколько часов без серьёзных инцидентов! В историю поверили фаундеры Google и собрали победителей в Google Self-Driving Car Project.

В 2012-м появились первые видео полностью беспилотных проездов!

В 2014-м уже стали катать внешнюю публику. И в 2020-м запустили настоящее такси.

Сейчас такси Waymo можно вызвать в 6–7 городах, и Лондон будет первой локацией за пределами Штатов!

У Waymo было много конкурентов, многих из которых создали выходцы из Google Self-Driving. Но все компании, открытые выходцами, либо закрылись, либо застыли в развитии. Из значимых игроков в США - Zoox (купленный Amazon), Tesla (про которую есть много сомнений, что её подход приведет к запуску), Cruise (куплен, а потом закрыт GM) ну и мой Avride(кстати последний независимый игрок на рынке!) В Китае есть несколько заметных игроков, но мне сложно судить об их зрелости.


Интересно, что CEO Waymo Дмитрий Долгов участвовал в DARPA Challenge, всё это время работал в компании в роли CTO, а недавно стал CEO. Ещё интересно, что он выпускник Физтеха, как и я - и мы одно время шутили, что во всех успешных self-driving компаниях CTO - с Физтеха.

Autonomous driving оказался сложнее любых самых пессимистичных прогнозов - например, с момента первых хороших демо до запуска прошло аж 6 лет. И даже сейчас полностью беспилотно в США ездят только полторы компании. И лидер рынка Waymo работает только в ограниченных зонах! С другой стороны, даже эта технология позволила завоевать заметную долю рынка. Лично я всегда выбираю такси без постороннего человека и уверен, что вот оно - будущее!

Если хотите подробнее почитать про историю - есть отличная книга Driven https://www.goodreads.com/book/show/52767920-driven

Сейчас происходит бум робототехники. Ожидать ли прорывов или ждать ещё 10 лет? Об этом я готов написать еще один гостевой пост у Феди, но только если этот наберёт 100 лайков!

#гостевойпост

Подписаться на канал https://t.iss.one/rybasharp

JS-библиотека для визуализации данных в реальном времени. Делает интерактивные дашборды, легко тянет большие наборы данных, лайв-обновления и сложную аналитику

#сервисы@daniilak

#ml #prompt #interesting