#llm #books

Тут и перевод подвезли (оригинал репостил тут)

Русскоязычный перевод The Smol Training Playbook от @sergeydolgov с качественной версткой.

Оригинальный материал представляет собой очень полезное пособие по обучению LLM, да и DL в целом.

#dl #cv #courses

CS231n: Deep Learning for Computer Vision by Stanford

Computer Vision has become ubiquitous in our society, with applications in search, image understanding, apps, mapping, medicine, drones, and self-driving cars. Core to many of these applications are visual recognition tasks such as image classification, localization and detection. Recent developments in neural network (aka “deep learning”) approaches have greatly advanced the performance of these state-of-the-art visual recognition systems.

This course is a deep dive into the details of deep learning architectures with a focus on learning end-to-end models for these tasks, particularly image classification. During the 10-week course, students will learn to implement and train their own neural networks and gain a detailed understanding of cutting-edge research in computer vision. Additionally, the final assignment will give them the opportunity to train and apply multi-million parameter networks on real-world vision problems of their choice.

Through multiple hands-on assignments and the final course project, students will acquire the toolset for setting up deep learning tasks and practical engineering tricks for training and fine-tuning deep neural networks.

Links:
- Course Materials
- Useful Notes
- Videos (2025)

Navigational hashtags: #armknowledgesharing #armcourses
General hashtags: #cv #computervision #nn #neuralnetworks

@data_science_weekly

Чистил канпюктер от старья и внезапно обнаружил, что за последний год перестал использовать в разработке четыре столпа, которые казались незыблемыми последние лет десять: iTerm, Pycharm, Pyenv, Docker Desktop.

iTerm и Pycharm продолжали обрастать фичами, которые мне ни к чему. Фичи бесплатными не бывают: у iterm в 2024 всплыла неприятная уязвимость, Pycharm продолжал слегка тормозить даже на свежем железе (возможно, я просто не знаю все флаги, как дать ему еще больше памяти). Так я перешел на более легкие альтернативы - Wezterm и Zed.

Pyenv когда-то был отличным способом управлять зоопарком питонов и вместе с poetry делал управление зависимостями терпимым. Но uv разрубил этот узел, оно просто работает. Лучшее, что случилось с Python экосистемой, не считая maturin.

Про избавление от Docker Desktop мне пришлось подумать на работе, потому что в Большой Корпорации для него нужна отдельная лицензия, которая положена не всем. Мне таки положена, но дать продакту демку стало сложнее. Так я познакомился с colima, перешел на нее (все еще с docker runtime / docker cli, которые не требуют коммерческой лицензии) на рабочей тачке, а заодно и на своей, совершенно этого не заметив. Впрочем, чистым докером я тоже пользуюсь все меньше, потому что меня покусал Dagger.

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

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