[1/2] Prompt Engineering for LLMs (Рубрика #AI)

Прочитал по большей части на новогодних каникулах популярную книгу про prompt engineering , которая вышла ~2 года назад. В ней Джон Берриман и Альберт Циглер рассказывали о том, как правильно «разговаривать» с большими языковыми моделями (LLMs). Авторов интересно читать, так как они – создатели одного из самых успешных AI-продуктов (GitHub Copilot) и шарят в теме.

В 2024 году тема prompt engineering была горячей, ее много обсуждали и эта книга стала одним из первых гидов - от основ до продвинутых тем, также в ней были готовые шаблоны с примерами кода. Все это сделало книгу ценным пособием для разработчиков. Если говорить подробнее про содержание книги, то она состоит из трех частей

1️⃣ Основы LLM: устройство и эволюция моделей, их обучение и переход к диалогам.
В первой части было 4 главы
1. Introduction to Prompt Engineering - почему LLM выглядят как «магия», краткая эволюция языковых моделей и где в этой картине prompt engineering как инженерная дисциплина.
2. Understanding LLMs - LLM как completion engine: токены/токенизация, автрорегрессия, галлюцинации, temperature/probabilities, основы трансформера; почему порядок текста и «нагрузка» на модель реально влияют на качество.
3. Moving to Chat - переход от completion к chat: RLHF (как он собирается), instruct vs chat, «alignment tax», эволюция API и почему следующая остановка — tools. Идея промптинга как «постановки пьесы» (сцены/роли/реплики).
4. Designing LLM Applications - ключевой фрейм: LLM loop (перевод проблемы пользователя в домен модели → completion → пост‑обработка обратно). Внутри: retrieval → snippetizing → scoring → prompt assembly; где добавляются state, внешний контекст, глубина рассуждений, tools и eval.

2️⃣ Ключевые техники: few-shot примеры, добавление внешних данных (подход Retrieval-Augmented Generation) для снижения галлюцинаций, форматирование длинных запросов
Во второй части было 3 главы
5. Prompt Content - из чего «собирать» промпт: static (инструкции, few-shot + типовые риски) vs dynamic (контекст на лету); RAG (lexical vs neural), эмбеддинги/векторное хранилище; суммаризация (в т.ч. иерархическая) и выбор «общей» vs «под задачу».
6. Assembling the Prompt - как упаковать всё в лимит контекста: «анатомия» промпта, выбор формата документа (advice conversation / analytic report / structured doc), форматирование сниппетов и few-shot, elastic snippets, зависимости между кусками (position/importance/dependency). Плюс важная практика: середина промпта часто “проседает” (условная valley of meh), важное лучше держать ближе к концу.
7. Taming the Model - «анатомия completion»: preamble, узнаваемые start/end, postscript; stop‑sequence/стриминг; logprobs для уверенности/классификации; как выбирать модель (качество/цена/латентность/фичи).

В продолжении я расскажу про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.

#AI #DevOps #Software #Engineering #Architecture

[2/2] Prompt Engineering for LLMs (Рубрика #AI)

Заканчивая рассказ про книгу о промпт инжиниринге надо рассказать про продвинутые темы, а также поделюсь своими мыслями насчет актуальности книги в 2026 году.

3️⃣ Продвинутые темы: разработка чат-агентов с памятью и инструментами (метод ReAct), разбиение сложных задач на шаги (workflows), оценка качества решений моделью.
8. Conversational Agency - tool use в деталях: как проектировать инструменты (имена/аргументы), разруливать ошибки и опасные действия; reasoning‑паттерны (CoT, ReAct и дальше); контекст для task‑диалогов; сборка агента, управление диалогом и UX.
9. LLM Workflows - когда «чат‑агент» не нужен, а нужен workflow: задачи как кирпичики; реализация через шаблонные промпты или tools; усложнение/вариативность; идея «eval начинается на уровне task»; пример end‑to‑end workflow; продвинутые схемы: agent‑driven workflow, stateful task agents, роли/делегирование.
10. Evaluating LLM Applications - что вообще тестируем; offline: example suites, gold standard / functional testing / LLM‑as‑judge, SOMA; online: A/B и метрики.
11. Looking Ahead - куда всё едет: multimodality, UI/UX как часть качества, рост «интеллекта»/скорости/доступности моделей.

В общем, контента в книге много, но возникает вопрос, а насколько он полезен сейчас (в 2026 году). И действительно с момента выхода книги LLM-технологии шагнули вперёд, и некоторые в 2025-м провозгласили «prompt engineering мёртв». Качество моделей выросло – они всё лучше понимают пользователя даже без хитрых подсказок; кроме того, лучшие техники уже встроены в инструменты (готовые шаблоны промптов). В реальных продуктах поведение модели всё чаще определяется системными настройками или fine-tuning’ом, а не текстом пользовательского запроса. В итоге роль "prompt engineer" вскоре слилась с более широкими ролями AI/LLM-разработчиков.

Однако книга не потеряла ценности – её фундаментальные принципы по-прежнему полезны каждому инженеру. Авторы честно предупреждали, что конкретные API могут устареть, но базовые идеи останутся актуальными. Так и вышло: например, подход RAG теперь повсеместно применяют для подключения знаний модели, а техника chain-of-thought стала стандартным приёмом в современных AI-агентах. А в 2025 году Андрей Карпати ввёл термин «контекст-инжиниринг» – фокус на предоставлении модели полного окружения (данные, история, инструменты) вместо подбора идеальной формулировки запроса. Такой подход требует уметь динамически находить и подставлять нужные сведения, ужимать их под контекстное окно, чётко задавать роли (system/user) и подключать внешние инструменты по мере необходимости. Кроме того, появились практики вроде PromptOps – управление промптами (версионирование, мониторинг качества запросов). А некоторые команды уже пытаются полностью автоматизировать подготовку контекста и инструкций (т.н. workflow-подход).

#AI #DevOps #Software #Engineering #Architecture

CS230 Lecture 2 @ Stanford (Рубрика #AI)

Раньше я уже рассказывал про то, что начал изучать этот курс и посмотрел первую лекцию Andrew Ng. Дальше пришло время второй лекции, которую вел Kian Katanforoosh, со-автор этого курса, CEO и основатель Workera (платформа для оценки AI-навыков), сооснователь deeplearning.ai. Лекция выглядела как "recap про supervised" после изучения лекций с Coursera, но на деле это разбор инженерных рычагов в AI‑проектах: постановка задачи → данные/разметка → архитектура → loss → эксплуатация embeddings. Основные тезисы примерно следующие

1️⃣ Supervised ML решение - это обычный прод‑сервис
- В проде «модель» = архитектура + веса (два артефакта), вокруг которых крутятся пайплайны, метрики и деплой.
- Меняете задачу (binary → multi‑label) - меняется контракт лейблов, loss и метрики. Это не «добавили классы в датасет».
- Capacity: размер модели должен соответствовать сложности + разнообразию данных + compute/latency. Иначе получите красивый dev и боль в реальном трафике.
- Embeddings - когда расстояния в пространстве имеют смысл. Это фундамент поиска, рекомендаций, retrieval/RAG и «переиспользуемых представлений».

2️⃣ Три кейса, где всё решают данные и постановка
1) Определение day/night по картинке: сначала scope (одна камера или «весь мир»? indoor/outdoor? рассвет/закат/полярный день?) → потом сбор данных. Разрешение подбирают через human‑эксперимент: печатаем/показываем людям разное качество и ищем нижнюю границу информативности. Типичный компромисс: ~64×64×3 + небольшая CNN.
2) Работа с триггер словом типа "Алекса"/"Алиса"/"Siri", тут предлагается “activate”: классический паттерн каскада (дешёвое → дорогое): VAD/activity → trigger → ASR/intent. Чтобы не разметить руками бесконечные аудио, делают synthetic data + programmatic labeling: позитивы (“activate”), hard negatives (“deactivate” и похожие), фоновые шумы; скрипт миксует всё в 10‑сек клипы и генерит временные метки. Часто выигрыш даёт не «ещё данных», а правильная схема разметки по времени.
3) Face verification: «сравниваем пиксели» и «классифицируем каждого человека» не масштабируются. Решение - face embeddings + triplet loss (A,P ближе, чем A,N + margin). Дальше один embedding‑слой закрывает сразу три продукта:
- verification: distance < threshold
- identification: nearest neighbor по базе
- clustering: k‑means/agglo

3️⃣ Как масштабироваться без дорогих меток
- Self‑supervised: contrastive (SimCLR‑стиль) - две аугментации одного объекта должны быть ближе, остальные дальше; и next‑token prediction (GPT) - данные «размечают себя».
- Weak supervision: используем естественные пары модальностей (image↔️text, video↔️audio, subtitles↔️video). Отсюда CLIP/ImageBind‑подходы и единые multimodal embedding‑spaces.

Что можно почерпнуть для техлида DL/ML проекта
- Начинайте проект с постановки + распределения + edge‑кейсов, не с выбора модели.
- Ревьюйте свои ML модели как код: labels contract + loss + метрики (и их связь с бизнес‑ценой ошибок).
- Делайте быстрые human‑тесты до траты GPU‑недель.
- Оптимизируйте iteration speed: чуть меньшая модель/разрешение часто быстрее приводит к правильной системе.
- Стройте архитектуру вокруг embedding‑API: «выучили представление один раз → решаем N задач».
- Ищите в домене неразмеченные потоки и слабые связи (логи↔️действия, текст↔️телеметрия) - это топливо для self/weak supervision.

#Software #ML #AI #Engineering #Architecture

AI Periodic Table Explained: Mapping LLMs, RAG & AI Agent Frameworks (Рубрика #AI)

Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системы Менделеева "AI Periodic Table". У этой таблицы, как ни странно, два измеренияя

Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)

Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности

Если разбирать содержимое таблицы по колонкам, то получится интересно

Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов

Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели

Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain

Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference

Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей

Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))

Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?

#AI #DevOps #Software #Engineering #Architecture #SystemDesign

ASML Statement on Strengthening Focus on Engineering and Innovation (Рубрика #Engineering)

Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.

Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.

В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация.

#Engineering #Management #Leadership #Software #Processes