LLM-стройка

Книги O’Reilly

https://www.amazon.com/Beyond-Vibe-Coding-AI-Era-Developer/dp/B0F6S5425Y/ref=ast_sto_dp_puis 

Раньше, когда я видела книги этого издательства, в моей голове возникала только одна мысль «Надо брать», потому что мне казалось, что это самые крутые и качественные, с точки зрения материала, книги. Но вот уже как минимум год я замечаю, что издательство просто хайпует на разных темах. Появилась куча новых книг с 2025 года по ИИ и всем производным. 

Я как по привычке покупаю эти не самые дешевые книги, и вот уже 3 книга – полная шляпа. Если представить милую коровку, пасущуюся на лугу и пережевывающую травку… вот эта травка – книги орейли. 

Последнее, что прочитала – книга про вайбкодинг. Ожиданий было не много, но хотелось получить какие-то рекомендации по работе с ИИ-агентами. В итоге 250 страниц описания, как важно все тестировать и смотреть глазами на код. Не советую. В любой статье от OpenAI/Anthropic/DeepSeek можно найти больше и качественнее. 

Зато удобно читать такое в дороге, все равно практических кейсов там нет. Пук

Orchestrator-worker и контекст

Недавно узнала о подходе к организации контекста в оркестраторе – и он хорошо ложится на наши задачи, где нужно хранить контекст предыдущей коммуникации с пользователем.

Пользователь возвращается через два дня, дописывает уточнение, ссылается на прошлый разговор. Обычная реакция – тащить всю историю в один агент. И тут всё разваливается: окно распухает, модель теряет середину диалога, а каждый вызов инструмента засоряет контекст мусором.

Orchestrator-worker решает это разделением памяти. Оркестратор держит только тонкий долгий слой: кто пользователь, о чём договорились, какая цель. Воркеры получают чистое изолированное окно под одну подзадачу и возвращают не сырую выдачу, а сжатый отчёт. Шум остаётся внутри воркера.

Плюсы: контекст оркестратора живёт долго и остаётся читаемым, воркеры взаимозаменяемы за счёт фиксированной структуры отчёта, оркестратор можно держать на сильной модели, а воркеров – на дешёвой.

Честно: токенов уходит кратно больше (пук), оркестратор становится единой точкой отказа, а нечёткий план-файл = воркер уверенно делает не то. Так что схема не «лучше», а уместна там, где подзадачи реально независимы.
Разбираем сейчас, что должно жить в долгой памяти, а что выбрасывать после отчёта. Протестируем – расскажу, что выжило.

Encyclopedia of Agentic Coding Patterns

🧱 Локальная модель не решает проблему персональных данных

Самый частый ответ на вопрос «а как вы закрываете ПДн в LLM»: «у нас всё локально, данные не уходят».
Проблема в том, что «не уходят наружу» ≠ «защищены». Как только сырой текст попал в контур, персональные данные оказываются в:
— логах приложения и трейсах запросов
— кэшах и очередях
— RAG-индексе, откуда их достанет любой, у кого есть доступ к поиску
— обучающих выборках, если вы дообучаете модель на своей переписке
— выгрузках и бэкапах

Поэтому обезличивание стоит ставить не «на границу с интернетом», а до инференса. Тогда ниже по стеку – только токены, и вопрос «кто имел доступ к ФИО клиента» решается в одном месте.
Плюс идея для бизнеса – очистка данных перед ЛЛМ (такого добра уже много, но тем не менее...)

Channel photo updated

Channel created