Лекция 3. Архитектуры AI-систем: агенты, RAG, API¶
Лекция 3 · ~88 мин · 40 слайдов
Air Canada: чат-бот выдумал политику¶
Начну с истории, которая стоила денег и закончилась в суде. Четырнадцатого февраля две тысячи двадцать четвёртого года трибунал в канадской провинции Британская Колумбия вынес решение по делу Моффатт против Air Canada.
История простая. Пассажир зашёл на сайт авиакомпании после смерти бабушки и спросил у чат-бота про тариф по случаю утраты близкого. Бот ответил: купите билет по обычной цене, а потом в течение девяноста дней подайте заявку на возврат разницы. Это было неправдой. Реальная политика такого возврата не допускала — и она была написана на той же странице, на которую бот сам ссылался.
Пассажир сделал, как сказал бот. Получил отказ. Дошёл до трибунала. Авиакомпания защищалась удивительным аргументом: чат-бот, мол, отдельное юридическое лицо, само за себя отвечает. Трибунал этот аргумент отверг и обязал компанию заплатить.
(пауза)
Нам важно в этой истории не юридическое, а инженерное. Задача была элементарной: показать пользователю фиксированную, заранее известную политику. Для этого есть архитектура, которая работает идеально и стоит почти ничего — статическая страница или детерминированный поиск по таблице правил. А выбрали генеративный чат-бот — то есть архитектуру, которая по своей природе способна сочинить несуществующую политику, потому что её работа — генерировать правдоподобный текст, а не извлекать проверенный факт.
Запомните формулировку: это не сбой модели. Это неправильный выбор архитектуры под задачу. И ровно про этот класс ошибок — вся сегодняшняя лекция, а она сегодня заметно длиннее и глубже, чем обычно, потому что раздел про агентов вырос почти до половины времени. А пока подумайте про себя: если задача всего лишь «узнать правило тарифа», какая архитектура её закрывает — и нужен ли здесь ИИ вообще? Мы вернёмся к этому ответу.
[Переходим к обложке.]
Обложка¶
Лекция третья. Архитектуры AI-систем: агенты, RAG, API. Это последняя обзорная лекция первого модуля.
[Не зачитывать подзаголовок, перейти к карте лекции.]
Карта лекции: шесть разделов¶
Прежде чем углубляться, посмотрим на маршрут целиком. Шесть разделов, и это не каталог технологий, а одна линия рассуждения. Ноль — открытие, Air Canada. Первый — промпт и его границы. Второй — RAG. Третий — дообучение модели. Четвёртый, самый большой, — агенты: как модель становится частью системы, из чего собран агент-помощник и как всё это ломается. Пятый — сборка всего в лестницу и короткий чек-лист.
Одна линия через все шесть: не «изучите шесть технологий», а «научитесь выбирать, какую применять — и когда не применять ни одну».
[Переходим к повторению.]
Повторение Лекции 2 и мост¶
Быстро вспомним, на чём стоим. Лекция первая дала картину «модель — чат — агент — приложение» и формулу промпта: роль, задача, контекст. Лекция вторая объяснила, почему промпт работает: токенизация, эмбеддинги, внимание, сэмплинг.
Из второй лекции мы с вами берём сюда два готовых блока и переобъяснять их не будем. Первый — семантический поиск на эмбеддингах: текст превращается в вектор, близость векторов означает близость смысла. На этом блоке целиком стоит RAG. Второй — один вызов модели, single-shot: один проход без памяти между вызовами. Вокруг этого одного прохода мы будем надстраивать инструменты, циклы и агентов.
Посмотрите на схему: в центре — один вызов, вокруг — четыре обвязки. И обратите внимание: вон та стрелка, подсвеченная золотым, — это прямой мост от эмбеддингов второй лекции к RAG. Детали — в Разделе 2.
[Переходим к центральному вопросу.]
Центральный вопрос и лестница¶
Теперь — главный вопрос всей лекции. Прочитаю его медленно, потому что мы будем возвращаться к нему в каждом разделе.
(пауза)
«У меня есть задача и доступ к LLM. Какую архитектуру выбрать — и когда правильный ответ "не ИИ"?»
LLM — это большая языковая модель, если кто-то ещё держит этот термин на слух.
Заметьте вторую половину вопроса. Она не менее важна, чем первая. Мы с вами учимся не только выбирать инструмент ИИ, но и говорить «нет», когда он не нужен.
Ответом будет вот эта лестница — шесть ступеней. Снизу: обычный код без ИИ. Выше — один вызов модели с промптом. Выше — RAG и контекст-инжиниринг. Выше — workflow, предопределённые пути. Выше — агент. На самом верху — мульти-агент.
И сразу — важная оговорка, чтобы снять напряжение. Эта лестница — карта всей лекции, а не требование понять всё прямо сейчас. Каждую ступень мы с вами разберём отдельно и подробно. Сейчас от вас не ждут, что вы её освоили; ждут, что вы видите маршрут.
Главное на этой картинке — не сами ступени, а правило движения по ним. Оставайся на самой нижней ступени, которая закрывает требования задачи. Поднимайся на следующую только тогда, когда сформулировал требование, которое текущая ступень не закрывает. Каждый подъём не бесплатен: он добавляет новые режимы отказа, стоимость, задержку и новую поверхность для атаки.
Обратите внимание на самую нижнюю ступень. Это обычный код, без всякого ИИ. То есть лестница архитектур AI-систем начинается с честного вопроса: «а может, ИИ здесь вообще не нужен?» Именно этот вопрос мы и задавали себе на примере Air Canada.
[Переходим к Разделу 1.]
Divider: Раздел 1¶
Раздел первый из пяти — «Промпт и его границы». Идём снизу лестницы: что умеет один вызов и где его потолок.
Дефолт: один вызов¶
Зафиксируем точку отсчёта, от которой мы с вами дальше отсчитываем всё. Самая дешёвая, самая надёжная и самая предсказуемая AI-архитектура — это один вызов модели с хорошо составленным промптом. Никакого внешнего поиска, никакого цикла, никаких инструментов. На вход — промпт, на выход — ответ. И зафиксируем сразу границу, к которой мы будем возвращаться весь раздел: модель знает только то, что попало в промпт, плюс то, что осело в её весах при обучении. Больше — ничего.
Инженерное правило, которое я предлагаю принять как настройку по умолчанию: не усложнять архитектуру без причины, выраженной в требованиях задачи. Anthropic в руководстве по агентам говорит об этом прямо: ищите простейшее решение, прежде чем строить что-то сложнее.
Это не призыв к примитивизму. Это распределение бремени доказательства. По умолчанию архитектура — один вызов. Любой шаг вверх требует явного обоснования: вот требование задачи, которое одним вызовом не закрывается, поэтому я добавляю RAG, или инструмент, или цикл.
Давайте посмотрим на список справа. Добавляя RAG, вы добавляете конвейер индексации, хранилище и retrieval, который может тихо деградировать. Добавляя агента — внешние вызовы, петли, недетерминизм и новую поверхность атаки. Ничего из этого нет у одного вызова.
[Переходим к ролям в промпте.]
Роли в промпте: миф о точности¶
Первый элемент, который инженер обычно пишет в системный промпт, — это роль: «ты опытный юрист», «ты заботливый ассистент поддержки». Интуиция понятная: чем точнее роль, тем компетентнее ответ. Разберём миф, который стоит за этой интуицией, потому что он один из самых живучих в промпт-инжиниринге.
Специально спроектированное исследование Zheng и соавторов, опубликованное в двадцать четвёртом году, проверило сто шестьдесят две персоны на двух тысячах четырёхстах десяти вопросах, поперёк четырёх семейств моделей. Результат однозначный: персоны не улучшают точность ответа на фактические вопросы по сравнению с ответом вовсе без роли. «Ты нобелевский лауреат по физике» не делает модель точнее в физике.
А что роль тогда делает? Отдельное исследование двадцать шестого года показывает: она реально влияет на тон и глубину изложения — насколько формально, насколько подробно модель раскрывает тему. Это не универсальный закон, эффект модель-специфичен, но направление ясное.
Сведём в вывод — часть «магической пилюли», которую мы сегодня опровергаем: роль в промпте — не инструмент точности, а инструмент стиля. Если нужна фактическая точность — правильный инструмент не формулировка роли, а грамотный контекст, и, при необходимости, RAG.
[Переходим к структуре промпта.]
Структура промпта: разделители¶
Если роль отвечает за тон, то за качество ответа в куда большей степени отвечает структура промпта — насколько ясно в тексте разделены инструкция, контекст и данные. Плоский промпт одним абзацем заставляет модель самой угадывать эти границы.
Практический инструмент — разделители: XML-подобные теги, markdown-заголовки, тройные кавычки вокруг вставляемого текста. Конкретный синтаксис не так важен, как сам факт разделения: модель, которой явно показали, где кончается инструкция и начинаются данные, реже путает одно с другим.
И вот параллель, которую стоит запомнить и к которой мы вернёмся в разделе про агентов: то же самое мы увидим у structured output — там схема структурирует выход модели, здесь разделители структурируют вход. Один и тот же принцип с двух концов. И ещё одна связь на будущее: эта же путаница «данные против команды» — корень атаки под названием prompt injection, к которой мы придём в разделе четыре.
[Переходим к chain-of-thought.]
Chain-of-thought и предел faithfulness¶
Один частый способ улучшить один вызов, не меняя архитектуру, — это chain-of-thought, пошаговое рассуждение. Модель просят не выдавать ответ сразу, а сначала рассуждать вслух по шагам. Технически это всё ещё один вызов — вы поменяли только промпт.
Пример на экране. В корзине двадцать три яблока, семь испортились, докупили два ящика по шесть. Без рассуждения модель часто ошибается. С рассуждением: двадцать три минус семь — шестнадцать; два на шесть — двенадцать; шестнадцать плюс двенадцать — двадцать восемь. На арифметике и многошаговой логике рассуждение заметно помогает; на простом извлечении факта — нет и может навредить.
Но у этого приёма есть предел, и он важнее самого приёма. Раз модель рассуждает вслух, кажется — можно проверить, как она пришла к ответу. Это неверно фундаментально. Faithfulness, верность рассуждения, — степень, в которой проговорённая цепочка отражает реальные причины ответа. Anthropic измерила это: давали подсказку, менявшую ответ, и смотрели, признается ли модель, что опиралась на неё. Claude три-семь признавался примерно в двадцати пяти процентах случаев, DeepSeek R1 — примерно в тридцати девяти. По данным Anthropic за апрель двадцать пятого — подаю как измерение конкретной работы, не универсальную константу.
(пауза)
В остальных случаях модель меняла ответ, но строила другую, выдуманную аргументацию. И хуже: верность падает на трудных задачах — именно там, где аудит нужнее. Вывод структурный: рассуждение — это сгенерированный текст, а не протокол. Отсюда правило курса: человек-валидатор проверяет результат против источника, а не самообъяснение модели.
[Переходим к контекст-инжинирингу.]
Контекст-инжиниринг и context rot¶
Если chain-of-thought — про форму одного вызова, то контекст-инжиниринг — про его содержимое. Промпт-инжиниринг — одна инструкция: роль, задача, контекст. Контекст-инжиниринг — шире: курирование всего набора токенов, видимых модели, включая системные инструкции, описания инструментов и историю. Принцип Anthropic: найти наименьший набор высокосигнальных токенов, который максимизирует вероятность нужного исхода.
Почему минимальность — инженерное требование, а не эстетика? Вспомните из второй лекции эффект «lost in the middle»: модель хуже использует информацию из середины длинного контекста. У этого феномена появилось второе имя — context rot. По мере роста числа токенов точность извлечения падает. Это тот же самый феномен, просто под практическим названием.
Прямое следствие: «просто положить всё в контекст» — не стратегия. Большое окно даёт возможность вместить много текста, но не гарантию, что модель им воспользуется правильно.
И вот точка возврата нашего центрального вопроса номер один — их несколько, и мы с вами будем встречать их в каждом разделе. Когда НЕ усложнять? Три «не». Не добавляйте RAG, если корпус знаний мал и стабилен. Не добавляйте инструменты и цикл, если задача — один проход рассуждения. И не используйте ИИ вовсе, если задача детерминированная и верифицируемая. Дело Air Canada из начала лекции — ровно третий случай.
[Переходим к чек-листу.]
Чек-лист: как строить промпт¶
Соберём раздел в короткий чек-лист — восемь пунктов, которые можно приложить к любому промпту перед первым запуском.
Роль задана, если нужен тон, — и не используется как обещание точности. Задача сформулирована как конкретное, проверяемое действие. Контекст содержит минимально необходимое, а не всё, что могло бы пригодиться. Формат вывода указан явно, если ответ должен быть машинно-обрабатываемым. Разделители расставлены, если в промпте несколько видов содержимого. Примеры добавлены только там, где формат неочевиден без них. Chain-of-thought включён только там, где нужно многошаговое рассуждение. И последнее: промпт не длиннее необходимого — каждый лишний абзац рискует утонуть в контексте.
Это компактная форма всего раздела: роль — не точность, структура помогает разделить входы, CoT — точечный инструмент, контекст — минимальный. Мы с вами вернёмся к более развёрнутому аналогу этого чек-листа в конце лекции, уже для целой архитектуры, а не одного промпта.
[Переходим к Разделу 2.]
Divider: Раздел 2, RAG¶
Раздел второй из пяти — RAG, поиск-дополненная генерация. Один вызов и его границы мы прошли. Следующая ступень лестницы — добавить модели внешнее знание. Коротко суть: извлечь релевантное, положить в контекст, ответить с опорой на источник. Дальше — подробно.
Принцип RAG¶
Один вызов упирается в естественную границу: модель знает только то, что попало в её веса при обучении, плюс то, что вы вручную положили в контекст. Если задача требует приватной базы компании или знаний, которые меняются быстрее, чем выходят новые версии модели, — один вызов не справится. Здесь начинается RAG.
RAG — это архитектура, где перед вызовом модели система сначала извлекает релевантные фрагменты из внешнего хранилища, кладёт их в контекст вместе с вопросом, и только потом модель генерирует ответ, опираясь на них. Введём термин: retrieval — это и есть этап поиска и извлечения релевантного.
Ключевое: механизм retrieval — это ровно тот семантический поиск на эмбеддингах, который мы с вами построили во второй лекции. Переобъяснять не буду. RAG надстраивает три шага. Первый — индексация, заранее: корпус режется на фрагменты, каждый превращается в эмбеддинг, кладётся в хранилище. Второй — retrieval, на запрос: вопрос превращается в вектор, достаются ближайшие фрагменты. Третий — генерация с опорой: фрагменты идут в контекст, модель отвечает по ним и в хорошей реализации — со ссылкой на источник.
Введём ещё один несущий термин. Grounding — опора на источник: свойство ответа быть выведенным из конкретных извлечённых фрагментов, а не сочинённым из головы, с возможностью показать, из какого фрагмента взят каждый факт.
И сразу зафиксируем инвариант, к которому будем возвращаться. «Не знаю» — это корректный ответ RAG-системы. Правдоподобный ответ при нерелевантном retrieval — это дефект, а не «лучше, чем ничего».
[Переходим к тому, когда RAG прав.]
Когда RAG — правильный выбор¶
RAG — правильный выбор, когда есть сильный сигнал по нескольким признакам сразу — и при этом нет блокеров, о которых мы поговорим на следующем слайде.
Пройдём по признакам. Признак первый: знание большое или растущее, не помещается в окно целиком. Второй: знание меняется — документы, цены, регламенты обновляются чаще, чем выходят версии модели. Третий: нужны свежесть и провенанс — ответ должен опираться на проверяемый источник, и надо показать, откуда взят факт. Четвёртый: база приватная — знания компании не входят в веса публичной модели.
Один признак сам по себе RAG обычно не оправдывает. «Знание большое», но не меняется и влезает в окно — это кандидат на длинный контекст, не RAG. Признаки обычно усиливают друг друга: чем больше их сходится, тем увереннее выбор.
Образцовый пример — внизу. Корпоративная база из тысяч регламентов, обновляются еженедельно, вопросы на естественном языке, обязательная ссылка на пункт-источник. Проверяем: большое — да; меняется — да; нужен провенанс — да; приватное — да. Все четыре сложились. Запомните этот пример: мы с вами вернёмся к нему в пятом разделе.
И интересный практический факт: RAG особенно выигрывает у прямого ответа для меньших моделей — по исследованию U-NIAH двадцать пятого года. Иначе говоря, RAG не только даёт знание, но иногда позволяет удешевить систему, оставаясь на меньшей модели.
[Переходим к тому, когда RAG НЕ нужен.]
Когда RAG НЕ нужен¶
А вот это — точка возврата центрального вопроса номер два, и она важнее предыдущего слайда. Знать, когда RAG не нужен, ценнее, чем знать, когда нужен. Потому что RAG — модная архитектура, и её ставят туда, где она вредит.
Три критерия «не RAG». Первый: корпус помещается в окно — ориентир меньше примерно двухсот тысяч токенов — и меняется редко. Тогда правильный ответ — full-context с кэшированием префикса, а не RAG-инфраструктура: это проще, дешевле и без риска, что retrieval достанет не то.
Второй: задача — отдать фиксированную политику или значение. Тариф, цена, пункт регламента. Тогда правильная архитектура — детерминированный lookup, а не генерация поверх извлечённого фрагмента. Генерация всегда несёт ненулевой риск, что модель перефразирует или додумает, — и ровно это произошло в Air Canada.
И третий, самый недооценённый: данные уже доступны живьём через API или MCP, к которому мы придём в четвёртом разделе. Если у модели и так есть прямой программный путь к системе-источнику, строить отдельный RAG-индекс поверх неё — избыточный, более хрупкий и более устаревающий слой. Вопрос-тест простой: «а почему бы модели просто не спросить систему X напрямую через инструмент?» Если ответ «действительно, почему бы и нет» — RAG здесь не нужен.
[Переходим к провалу RAG.]
Провал RAG на масштабе и Air Canada¶
Главный урок этого раздела — одной фразой, к которой стоит возвращаться при каждом проектировании RAG: «система вернула что-то» не означает «система вернула правильное». У RAG по умолчанию нет сигнала «я не нашёл подходящего» — он всегда возвращает ближайшие фрагменты, даже если они нерелевантны. А модель честно сочинит правдоподобный ответ поверх того, что ей дали.
Давайте три документированных кейса. Юридический поиск достаёт по вектору «близкие» дела — но из другой юрисдикции или с отменённым прецедентом — и модель встраивает их в аргументацию. Medical-RAG смешивает фрагменты карт разных пациентов, потому что эмбеддинг кодирует медицинский смысл, а не принадлежность пациенту. Support-бот работал на сотнях статей, а после роста до тысяч качество тихо поползло вниз — и никто не заметил, пока не посчитали метрики.
Быстрый вопрос в зал, ответьте про себя за двадцать секунд: RAG вернул вам ответ — как вы узнаете, что он правильный?
(пауза)
Ответ: только измерением. Здесь нужен golden set — фиксированный набор вопросов с заранее известными правильными источниками, который регулярно прогоняют, чтобы видеть деградацию.
И вернёмся к Air Canada — теперь как к полноценному кейсу. Источник истины существовал, был доступен, бот даже на него ссылался. Но ответ был не выведен из него, а сгенерирован как правдоподобный текст. Это образцовый отказ grounding. Правильная архитектура: для фиксированной политики — детерминированный lookup; если по продуктовым причинам нужен диалог — RAG со строгой опорой, обязательной цитатой и честным «не знаю» вместо выдумки.
[Переходим к Разделу 3.]
Divider: Раздел 3¶
Раздел третий из пяти — fine-tuning против промпта и RAG. Знание мы решили через RAG. А если проблема не в знании, а в поведении модели?
Что такое fine-tuning¶
Прежде чем критиковать fine-tuning, дадим ему определение, которое мы с вами используем весь оставшийся раздел, — потому что в прошлых лекциях он встречался только мельком.
Fine-tuning, по-русски дообучение, — это дополнительное обучение уже готовой, предобученной модели на ваших данных, при котором изменяются веса модели. Посмотрите на мини-схему: предобученная модель плюс ваш датасет проходят дообучение — и на выходе другие, дообученные веса.
И вот принципиальный водораздел, запомните его. Промпт и RAG меняют контекст — то, что модель видит на момент запроса; веса они не трогают. Fine-tuning меняет саму модель — её веса.
И сразу практическая оговорка, важная для следующего слайда: на практике «дообучить модель» почти всегда означает не переобучение всех весов, а параметр-эффективное дообучение. Полное дообучение всех весов в двадцать шестом году — редкость.
[Переходим к PEFT.]
PEFT вместо полного дообучения¶
Слово «дообучить модель» у многих ассоциируется с обновлением всех весов. В двадцать шестом это почти никогда не то, что нужно.
Введём термин. PEFT — параметр-эффективное дообучение: базовые веса модели замораживаются, а обучается лишь небольшой набор дополнительных параметров, адаптеров. Самый распространённый метод — LoRA: в выбранные слои добавляются маленькие низкоранговые матрицы, и обучаются только они.
Масштаб принятия — не оценка на глаз. По данным команды PEFT Hugging Face, среди почти двадцати одной тысячи карточек моделей с тегом PEFT девяносто восемь и четыре десятых процента используют именно LoRA. Оговорка обязательна: это доля среди уже помеченных тегом PEFT, а не среди всего fine-tuning в принципе — полное дообучение всех весов так аккуратно не тегируют. Но тенденция ясна: среди тех, кто выбрал параметр-эффективный путь, LoRA — практически безальтернативный дефолт.
Три причины, почему PEFT почти всегда лучше. Первая: дешевле и быстрее — миллионы параметров вместо миллиардов. Вторая: модульность — адаптеры это мегабайты, на одну замороженную базу можно подключать много адаптеров. И третья, архитектурная, про надёжность: базовые веса заморожены, физически не переписываются. То, что модель умела раньше, в основном сохраняется.
[Переходим к области применения и критериям.]
Fine-tuning сузился и критерии выбора¶
Среди инженеров ходит формулировка: «в две тысячи двадцать шестом fine-tuning умер, всё решает RAG и длинный контекст». Это неточно. Fine-tuning не умер — он сузился и перестал быть настройкой по умолчанию.
Что ушло: знание, факты, всё, что меняется, — это ушло в RAG и длинный контекст. Что осталось: стабильное поведение, стиль, формат вывода, следование политике.
И здесь — важное уточнение, которое стоит закрепить точно, потому что раньше формулировка была неаккуратной. Дистилляция — это самостоятельная техника, а не вид fine-tuning. Дистилляция — это обучение меньшей модели воспроизводить поведение большей: собирают выходы сильной модели и дообучают на них компактную. На практике эти две техники часто комбинируются: сначала teacher-модель дообучают под нужное поведение, а затем из неё дистиллируют компактную student-модель. Это связка из двух отдельных техник, а не «дистилляция как случай fine-tuning».
Точка возврата центрального вопроса номер три — теперь в виде критерия. Знание меняется, нужна свежесть — это RAG, не fine-tuning: знание устареет, риск забывания. Нужно стабильное поведение — это fine-tuning, PEFT, не RAG: RAG подаёт знание в контекст, но не меняет манеру модели. Снизить стоимость на узкой задаче — это связка «дообучить teacher плюс дистиллировать student». А если ответ детерминированный — это обычный код, без ИИ вовсе.
И главный вывод: чистый выбор «одно из» — редкость, норма — гибрид. Но осторожно: гибрид — норма там, где у задачи одновременно есть и проблема знания, и проблема поведения. Нет проблемы поведения — fine-tuning не нужен, даже когда RAG есть.
[Переходим к catastrophic forgetting.]
Catastrophic forgetting¶
Введём термин через документированный провал. Catastrophic forgetting, катастрофическое забывание, — это деградация общих способностей модели в результате узкого агрессивного дообучения.
Как это выглядит на практике. Команда дообучает модель классифицировать тикеты в свой формат. На целевой метрике — рост, модель отлично справляется с классификацией. А параллельно, незаметно, проседают общие способности: рассуждение на нецелевых задачах, следование сложным инструкциям, качество на смежных запросах. И если команда мерила только целевую метрику — а так делают часто, ради неё ведь и дообучали, — деградация не видна, пока модель не применят на чём-то другом.
Контринтуитивная деталь для архитектора: с ростом масштаба модели тяжесть забывания, как правило, возрастает. То есть «возьмём модель побольше, чтобы надёжнее» здесь работает наоборот. Это эмпирически наблюдается при continual fine-tuning — исследования показывают, я подаю это именно так, не как закон.
Почему это в разделе про выбор архитектуры, а не в курьёзах. Сам по себе forgetting — управляемый риск. Катастрофическим его делает отсутствие дисциплины: нет петли оценки на общих задачах, нет версионирования датасета и весов для отката. Правило жёсткое: если нет eval-петли и версий датасета — не делайте fine-tuning. Не будет ни сигнала о поломке, ни кнопки отката.
[Переходим к Разделу 4.]
Divider: Раздел 4¶
Раздел четвёртый из пяти, самый большой — Агенты. Мы уже знаем, куда деть знание и куда поведение. Теперь — как встроить модель в систему, из чего собран агент-помощник, где живёт его память, и где всё это ломается.
API-слой и MCP¶
До сих пор мы получали от модели текст. Чтобы ИИ стал частью системы, его выход должен быть машинно-обрабатываемым, а сам он — уметь дотягиваться до внешних систем. Разберём три механизма и один стандарт.
Первый, structured output: модель обязана вернуть ответ строго по схеме, например JSON. Тонкость: гарантируется валидность формы, не содержания — значение поля всё ещё может быть неверным.
Второй, function calling: модели описывают доступные функции, и она может вернуть запрос «вызови инструмент X с аргументами Y». Подчеркну принципиальное: модель не исполняет ничего сама. Исполняет ваш код. Безопасность агентной системы — это свойство кода-обвязки, а не модели. Это будет ключевым дальше в разделе.
Третий, prompt caching: переиспользование уже вычисленного состояния для неизменной начальной части промпта. Именно это делает full-context для малого стабильного корпуса реальным конкурентом RAG.
И стандарт поверх этого — MCP, Model Context Protocol: открытый способ подключать инструменты к модели. Метафора: USB-C для инструментов. При N моделях и M инструментах было N на M интеграций; MCP сводит это к N плюс M. Открыт Anthropic в конце двадцать четвёртого, принят OpenAI и Google в начале двадцать пятого.
Но вот критический поворот. Стандартизация подключения не означает безопасность подключаемого. Каждый подключённый инструмент — это код в вашем окружении, описание, которое попадает в контекст и может нести инъекцию, и ещё одна граница доверия. Удобство подключения — не аргумент за подключение.
[Переходим к циклу агента.]
Цикл агента¶
Теперь у нас с вами есть всё для следующей ступени. Один вызов умеет рассуждать, RAG умеет доставать знание, function calling умеет дотягиваться до внешних систем, MCP стандартизует подключение.
Агент — это архитектура, в которой модель работает в цикле: планирует шаг, действует, наблюдает результат, проверяет, достигнута ли цель, и повторяет, сама динамически определяя последовательность шагов. Каноническая формулировка: plan — act — check — iterate, планируй, действуй, проверяй, повторяй. Это паттерн ReAct: чередование рассуждения и действия, где рассуждение ведёт и обновляет план, а действие даёт наблюдение из среды. Это уже другая модель применения ИИ по сравнению с одним вызовом из первого раздела: там модель отвечала один раз, здесь — управляет процессом из многих шагов.
Разберём цикл по шагам — каждый это место конкретного отказа, и мы вернёмся к ним на примере реального провала чуть позже. Plan: модель формулирует шаг. Отказ — близорукий или зацикленный план, модель не видит накопленную стоимость. Act: вызывается инструмент. Отказ — инструмент упал, а ветки на это нет. Check: оценивается результат. Iterate: цикл повторяется. Отказ — нет внешнего лимита на итерации, стоимость или время.
Подчеркну один шаг — check, золотой на схеме, потому что он несёт основную нагрузку всего цикла. Здесь возвращается ребром урок про faithfulness с шестого слайда. Проверка не должна быть «модель сама себя спросила, всё ли хорошо». Самооценка модели подвержена той же неверности — это иллюзия контроля. Надёжная проверка — валидация против внешнего критерия: схема, тест, сверка с источником истины, а в значимых решениях — человек-валидатор. Без содержательного check цикл агента — это петля, которая уверенно идёт не туда.
[Переходим к workflow против агента.]
Workflow против Agent¶
Введём различение, которое для нашей цели одно из самых важных в лекции. Anthropic разделяет два понятия, которые в обиходе путают.
Workflow, рабочий поток: LLM и инструменты оркестрируются по предопределённым в коде путям. Агент: модель динамически определяет собственный процесс.
Критерий прямой: задача предсказуемая — workflow. Задача непредсказуемая, и её ценность оправдывает кратный рост стоимости — агент. Большинство надёжных продакшн-систем — это workflow, а не полностью динамические агенты.
И вот точка возврата центрального вопроса номер четыре, возможно, самая дорогая ошибка отрасли: строить динамического агента там, где задача предсказуема и хватило бы workflow. Один практический вопрос-диагностика: могу ли я заранее выписать последовательность шагов? Да — это workflow. И «лень формализовать» не делает задачу непредсказуемой.
И ещё один важный нюанс на будущее: workflow и агент могут вкладываться друг в друга. Агент на одном из своих шагов может вызвать целый workflow как инструмент — например, «прогони линтер, прогони тесты» как единый детерминированный подпроцесс. И наоборот: внутри жёсткого workflow один непредсказуемый шаг может делегироваться мини-агенту. Это не третья архитектура, это признание того, что вопрос «workflow или агент» — не про систему целиком, а про конкретное место в ней.
[Переходим к тому, из чего сделан агент-помощник.]
Из чего сделан агент-помощник¶
До сих пор мы говорили про агента как про абстрактный цикл — plan, act, check, iterate. Но реальный агент-помощник — тот, с которым инженер работает каждый день, — это не голый цикл, а цикл плюс оснастка вокруг него.
Введём термин. Harness, экипировка агента, — совокупность памяти, инструкций-правил, skills, subagents и MCP-доступа, которыми оснащён конкретный агент-помощник поверх базового цикла. По данным независимого публичного реестра agent-harness-registry — это живой, независимо тестируемый каталог, не вендорский самоотчёт — можно выделить пять типовых слотов этой экипировки, и вдоль них мы пройдём следующие несколько слайдов. Первый слот — память: что агент помнит между сессиями, в отличие от контекста одного разговора. Второй — инструкции-правила: файлы-конвенции вроде журнала прогресса, в которые команда фиксирует, как собирать и тестировать проект. Третий — skills: переиспользуемые процедуры под конкретный повторяющийся класс задач. Четвёртый — subagents: делегированные под-агенты с собственным контекстным окном. И пятый — доступ через MCP к внешним системам.
И вот тезис, который рифмуется с центральным правилом всей лекции: каждый слот экипировки — это компромисс между ценой, сложностью и отказоустойчивостью, а не апгрейд по умолчанию. Ровно как не стоит подниматься по лестнице архитектур без требования задачи, не стоит и добавлять агенту память, subagents или доступ к инструментам «на всякий случай». Каждый добавленный слот несёт свою цену: операционную сложность, новую поверхность отказа, новую границу доверия. Мы с вами вернёмся к этому явно в конце лекции как к «стартовому комплекту агента».
[Переходим к памяти агента.]
Память агента¶
Первый слот экипировки — память: то, что агент помнит между сессиями, в отличие от контекста одного разговора. Простейшая форма — плоский файл: агент дописывает в текстовый лог факты и историю решений и читает его целиком при следующем запуске. На другом конце спектра — специализированные базы памяти, которые извлекают релевантный фрагмент по смыслу, а не читают весь лог.
Три примера из реестра, каждый на своей ступени сложности. Mem0 — cross-session память пользователя, собирает факты о предпочтениях. Cognee — память на основе графа знаний, факты связаны через онтологию. Graphiti и Zep — temporal knowledge graphs: граф, который явно отслеживает время действия факта и его происхождение.
И вот прямая параллель, которую мы с вами уже разбирали для RAG во втором разделе: тот же вопрос масштаба знания, что решает RAG для корпуса документов, здесь встаёт для памяти самого агента. Плоский файл работает, пока история мала и стабильна — это тот же критерий, что «корпус помещается в окно». Структурированная база нужна, когда история большая, растущая или требует структурированного поиска по фактам. И симметрично: правило лестницы применяется и здесь — не ставьте graph-базу памяти агенту с короткими несвязанными сессиями.
[Переходим к провалу памяти.]
Провал памяти¶
Наличие памяти интуитивно кажется чистым улучшением — агент, который помнит, должен быть полезнее того, кто каждый раз начинает с нуля. Данные независимого реестра показывают, что это не всегда так, причём иногда — драматически не так.
Кейс первый — Letta, оценена реестром на самом низком уровне. По данным реестра, Letta проигрывает и голой модели без всякой памяти, и тривиальному плоскому файлу. Конкретные цифры на одном из бенчмарков: голая модель — результат единица за девяносто четыре секунды, плоский файл — ноль целых восемьсот тридцать три тысячных за сто пятьдесят девять секунд, Letta — ноль целых семьсот пятьдесят тысячных за четыреста девяносто шесть секунд — на порядок медленнее при худшем результате. Механизмы провала три: капитуляция под давлением — при повторном вопросе система теряет уже данный верный ответ; многословие топит факт — правильный ответ прячется в приукрашенном тексте; и факт замечен, но не закоммичен в архивную память. Важная оговорка по свежести: тестировалась версия полуторагодовой давности относительно текущей, поэтому это оценка конкретной устаревшей версии, а не сегодняшнего состояния продукта.
Кейс второй — Anthropic Memory Tool, лучшая протестированная система в реестре. Сильный результат в целом. Но и здесь в семнадцати процентах задач — потеря информации: через явный отказ записать факт как «эфемерный», через немотивированный отказ как «не по теме», и через тихую сжатую суммаризацию, теряющую деталь. И самое тревожное: невоспроизводимость — одна и та же беседа дважды дала разное поведение памяти.
Урок один и тот же, что мы уже видели у RAG на масштабе и у catastrophic forgetting: наблюдаемое качество на выборке — не гарантия на всех случаях. Даже у лучшей протестированной системы — измеримый хвост потерь.
[Переходим к операционному слою.]
Операционный слой: presence paradox¶
Второй слот экипировки — операционный слой: файлы-инструкции проекта и журнал задач, в который агент пишет собственный прогресс. Интуиция понятная: подробная инструкция плюс журнал того, что уже сделано, должны поднять качество работы. Разберём, что на этот счёт показывают контролируемые исследования — интуиция здесь заметно расходится с измерением.
Исследование под названием «presence paradox», опубликованное в двадцать шестом году, — рандомизированный контролируемый эксперимент с тремя плечами: без файла-инструкции, файл сгенерирован моделью, файл написан человеком. Контринтуитивный вывод: само по себе наличие файла-инструкции не дало значимого прироста успешности задач по сравнению с его отсутствием, а стоимость выполнения при этом росла. Исключение одно и оно осмысленно: файл, сгенерированный моделью, реально помогал там, где не было другой документации — то есть заполнял настоящий информационный пробел.
Второе исследование, «Honest Lying», показывает риск ещё серьёзнее: самоавторская память агента — заметки о собственных выводах — может не помогать исправлению, а закреплять неверное убеждение. Ошибочный ранний вывод, записанный в журнал, повторно используется вместо перепроверки.
И реальный кейс: в открытом issue репозитория Клод Код зафиксировано, что письменное признание прошлой ошибки не предотвратило её повторение спустя двадцать пять дней. Синтез: операционный слой — не магическая прививка от ошибок, а инструмент, полезный только там, где реально заполняет пробел.
[Переходим к skills, subagents и доступу.]
Skills, subagents, доступ и безопасность¶
Оставшиеся три слота экипировки — skills, subagents и доступ к внешним системам — мы с вами разберём вместе с безопасностью, потому что это не отдельная тема сбоку, а прямое следствие того, что происходит, когда агент получает эти три возможности.
Skill, навык, — переиспользуемая процедура под конкретный повторяющийся класс задач, чтобы агенту не изобретать её заново каждый раз. Subagent, под-агент, — выделенный агент с собственным контекстным окном, которому делегируется часть работы: во-первых, чтобы не засорять контекст главного агента сырыми результатами, во-вторых — чтобы изолировать обработку недоверенного контента.
И вот поворот. Каждое MCP-подключение — это новая граница доверия. Каждый раз, подключая инструмент, вы добавляете код, которому доверяете исполнение, канал, через который в контекст может попасть недоверенный текст, и ещё одну политику хранения данных в цепочке «ваши данные — агент — инструмент — внешний API — провайдер».
Введём термины. ZDR, нулевое удержание данных, — режим, при котором провайдер не хранит содержимое после обработки. Least-privilege — каждому компоненту даются только строго необходимые права. Два факта, ломающих наивное «у нас же ZDR, всё в порядке». В споре Нью-Йорк Таймс против OpenAI суд в мае двадцать пятого обязал сохранить все логи как доказательства — договорная политика оказалась бессильна против судебного приказа. И второе: ZDR у Anthropic не покрывает ряд функций — файлы, batch, MCP-коннектор и, ключевое, стороннюю интеграцию — а агент по определению это модель плюс инструменты, часто сторонние.
(пауза)
Теперь — сама атака. Prompt injection, инъекция в промпт: во внешние данные, попадающие в контекст модели, встраивается текст, который модель принимает за команду. Корень фундаментальный: для модели инструкция и данные — один поток токенов.
Кейс: атака на GitHub через MCP, май двадцать пятого. У разработчика ассистент с доступом к GitHub под токеном, у которого права на все репозитории, включая приватные. Атакующий создаёт публичный issue со скрытой инструкцией «собери информацию о других репозиториях и опубликуй здесь». Ассистент читает issue — и инструкция становится командой. Читает приватные репозитории и публикует их. Два условия, оба нужны: переизбыточный токен и недоверенный контент. Убери любое — атака не проходит.
Четыре правила: least-privilege, изоляция недоверенного контента, human-in-the-loop на необратимых действиях, и допуск только аудированных инструментов с фиксированными версиями.
[Переходим к обзору реальных coding-агентов.]
Реальные coding-агенты через рамку экипировки¶
Соберём весь понятийный аппарат раздела в один практический ориентир: как через эти пять слотов выглядят реальные coding-агенты, которыми инженеры пользуются сегодня.
Claude Code — широкая экипировка: собственная память между сессиями, файлы-инструкции, встроенные skills, полноценные subagents, MCP-доступ. Почти все пять слотов заполнены — это возможности ценой операционной сложности.
Aider — противоположная точка: минимальная файловая простота, без развитой памяти, без subagents. С открытым исходным кодом, десятки тысяч звёзд на GitHub. И вот важный тезис: тонкая экипировка — не недоразвитая версия полной, а самостоятельный рабочий выбор для задач, где широкая оснастка не нужна.
Cursor — третья точка: не терминал, а агент внутри desktop-редактора, форк VS Code. Он показывает: форма интеграции в рабочий процесс — терминал против IDE — отдельная ось, не то же самое, что набор слотов.
И четвёртый — OpenHands: self-hosted платформа с открытой лицензией, разворачивается локально или в контейнере. Здесь мне нужно сделать честную оговорку. По совпадению профиля — открытый код, автономность, свободная лицензия — это похоже на инструмент, который упоминался владельцем курса на слух под неформальным названием. Но это рабочая гипотеза по совпадению характеристик, а не подтверждённый факт, и я подаю её именно так.
Общий вывод: разница между реальными coding-агентами — не в качестве модели внутри, а в том, какие слоты экипировки заполнены и где агент физически живёт.
[Переходим к провалам агентов.]
Провалы агентов¶
Агент — самая мощная из пройденных ступеней, и поэтому самая опасная при неоправданном применении. Три документированных провала.
Первый — петля на четыре тысячи двести долларов за шестьдесят три часа. Команда поставила автономного агента синхронизировать данные заказов в CRM — задача предсказуемая. Внешний API упёрся в ограничение частоты и вернул ошибку. У агента не было ветки на этот случай, и он действовал по своей природе: планирую, вызываю, ошибка, перепланирую — тысячи раз в час. Агент не понимает ни накопленной стоимости, ни времени. И вот важная деталь, которой не хватало в прошлой версии этого разбора: обычный детерминированный retry-скрипт с экспоненциальной задержкой решил бы ту же задачу практически бесплатно — несколько строк кода, секунды-минуты, а не часы. Значит, четыре тысячи двести долларов — это не цена автоматизации вообще, это цена неправильного выбора архитектуры под предсказуемую задачу. Это пятая точка возврата центрального вопроса в чистом виде.
Второй — reliability compounding, накопление ошибок. В цепочке компонентов надёжности перемножаются, а не усредняются. Пять компонентов по девяносто девять процентов дают не девяносто девять, а примерно девяносто пять процентов; десять — около девяноста. Улучшить отдельного агента почти не двигает систему; сильный рычаг — уменьшить число шагов и поставить валидацию между ними.
Третий, коротко: мульти-агентная хрупкость. На зависимых подзадачах параллельные субагенты принимают неявные конфликтующие решения. Мульти-агент по умолчанию — не апгрейд.
[Переходим к Разделу 5.]
Divider: Раздел 5¶
Раздел пятый из пяти — как выбрать: фреймворк решения. Мы разобрали все архитектуры и увидели, где каждая проваливается. Теперь соберём это в один инструмент выбора.
Лестница сложности¶
Соберём всё, что мы с вами прошли, в одну структуру — лестницу архитектурной сложности. Снизу вверх: обычный код без ИИ; один вызов модели с промптом; RAG и контекст-инжиниринг, а для малого стабильного корпуса — длинный контекст с кэшем; workflow с предопределёнными путями; агент с лимитами и осознанной экипировкой; мульти-агент.
Несущее правило главы: оставайтесь на самой нижней ступени, которая закрывает требования задачи, и поднимайтесь только при явно сформулированном требовании, которого текущая ступень не закрывает.
Посмотрите на каждую стрелку-переход — рядом написано требование, которое его открывает. Код — один вызов: появился естественный язык. Один вызов — RAG: знание большое, меняющееся и приватное. RAG — workflow: задача многошаговая, но последовательность известна заранее. Workflow — агент: последовательность принципиально нельзя выписать заранее, и ценность оправдывает кратную стоимость.
Каждая стрелка — не «улучшение», а обмен. «Зачем агент?» — «потому что современно» — это провал. «Потому что последовательность нельзя выписать заранее, а цена задачи оправдывает рост токенов» — это проходит.
[Переходим к маршруту выбора.]
Маршрут выбора¶
Лестница говорит «не поднимайся без нужды», но не говорит, по каким осям мерить нужду. Оси, которые мы с вами встречали по всей лекции, — это объём знания, частота изменений, потребность в провенансе, стоимость, латентность, аудируемость. Но удобнее не складывать их в таблицу, а пройти задачу через явный маршрут вопросов сверху вниз, останавливаясь на первом сработавшем.
Первый вопрос, и он же самый дешёвый отсев: задача детерминированная и верифицируемая? Да — обычный код, стоп здесь. Второй: закрывает один вызов? Да — промпт, стоп. Третий: ответ должен быть проверяем по источнику, регулируемый домен? Тогда провенанс обязателен независимо от прочего. Четвёртый: знание меняется часто или нужен провенанс? Да — RAG, если не заблокировано; нет и корпус мал — длинный контекст. Пятый: нужно стабильное поведение, а не факты? Да — fine-tuning, PEFT. Шестой: задача многошаговая, последовательность можно выписать заранее? Да — workflow; нет, но ценность оправдывает — агент с лимитами. Седьмой: подзадачи широко параллельны и независимы? Да — мульти-агент; иначе — один линейный. И восьмой, параллельная проверка на любом шаге: данные чувствительны — карта данных, least-privilege, человек-валидатор.
И самая важная строка всей лекции — нижняя плашка, золотая. Прочитаем её медленно.
(пауза)
Если задача детерминированная, верифицируемая и повторяемая — фиксированная цена, политика, парсинг, арифметика, маршрутизация по правилам — правильная архитектура: обычный код, без ИИ. Именно эта строка объясняет Air Canada из начала лекции.
[Переходим к стартовому комплекту агента.]
Стартовый комплект агента¶
Лестница дала правило для архитектуры системы целиком. Применим тот же принцип на уровень ниже — к вопросу, какой именно экипировкой оснащать конкретного агента, к карте пяти слотов из четвёртого раздела.
Дефолт — тонкий агент. Один файл-инструкция и плоская память, без subagents, без сложного набора skills, минимальный MCP-доступ. Это тот же дефолт, что «один вызов» на лестнице архитектур: бремя доказательства на усложнении, а не на простоте.
Триггеры усложнения явные. Память-бэкенд — когда история переросла контекст или нужен структурированный retrieval по фактам, дословно тот же критерий, что переход от промпта к RAG. Subagents — когда конкретная подзадача требует отдельного окна или изоляции недоверенной работы. Больше MCP-доступа — когда конкретная задача требует конкретного инструмента, не «на всякий случай».
И важная отсылка к предыдущему разделу: presence paradox прямо показал, что добавление файла-инструкции как ритуал не работает без реального пробела, который он заполняет. Дать агенту сразу всё — это тот самый карго-культ, против которого работает вся лестница.
[Переходим к человеку-валидатору.]
Человек-валидатор и MIT NANDA¶
Во всех ветках лестницы, где есть генерация, остаётся одна сквозная роль — человек-валидатор. Его функция, обоснованная и faithfulness, и шагом check в цикле агента: проверять результат и факты против независимого источника, а не самообъяснение модели.
Разложим эту роль, как мы с вами и договаривались, на три измерения, чтобы она не осталась лозунгом. Степень автономности — от «агент предлагает, человек нажимает кнопку» до «агент делает и уведомляет постфактум». Scope доверия — читать данные не то же самое, что их менять, обратимое действие не то же самое, что необратимое. И continuous monitoring — проверка при запуске недостаточна, качество может тихо деградировать со временем, как мы видели у retrieval.
Усиливает это отчёт MIT NANDA: около девяноста пяти процентов корпоративных пилотов не дали измеримого эффекта. Подаю как заголовок отчёта с методологией, не как закон. Причина — не в качестве моделей, а в провале интеграции. «Запустить ИИ» не равно «получить ценность».
[Переходим к финалу.]
Мост к Лекции 4¶
Лекция третья закрывает обзорный модуль. Первая — что такое ИИ и как устроен промпт. Вторая — почему промпт работает. Третья — как собрать систему и как выбрать, какую собирать.
Эта рамка — лестница, маршрут, чек-лист, правило «когда не ИИ», стартовый комплект агента — база для всех последующих лекций, а не материал, который заканчивается сегодня. Совет на остаток курса: услышав «здесь применяют RAG или агента», мысленно прогоняйте маршрут — требование задачи действительно поднимает на эту ступень, или это инерция.
Лекция четвёртая берёт этот аппарат и прикладывает его к первой отраслевой теме — AI в разработке программного обеспечения. Те же coding-агенты, которые мы разобрали через рамку экипировки, там встретятся снова уже со стороны инженерной практики.
Домашнее задание — Семинар 3, «Архитектурный выбор: три кейса».
[Переходим к Q&A.]
Вопросы (буфер Q&A)¶
Темп-нота (для WPM-учёта). Произносимый текст этого слайда — только короткое закрытие ниже (≈25 слов; это не таймированный 5-минутный монолог, а открытие свободного Q&A). Блок «Резерв» — НЕ скрипт: это реактивное меню, из которого лектор берёт пункт по запросу зала. WPM-правило к нему не применяется.
Произносимое закрытие (≈0.3 мин):
На этом — содержательная часть закончена. Спасибо за внимание. Теперь — ваши вопросы. Семинар 3 — на следующей неделе.
Резерв на этот блок (реактивно, по запросу аудитории — не зачитывается подряд): - Workflow против агента на конкретной задаче слушателя — диагностический вопрос «можно ли выписать шаги заранее». - Почему prompt injection не лечится фильтрацией ввода, как SQL-инъекция (нет архитектурной границы «данные/код»). - Разбор двух кейсов провала памяти (Letta / Anthropic Memory Tool) — какие механизмы отказа повторяются и в RAG, и в fine-tuning, и в памяти агента. - Presence paradox: почему файл-инструкция иногда всё-таки помогает, а когда — нет. - Открытый вопрос про OpenHands/«OpenClaw» — честно обозначить: гипотеза, не факт, если кто-то попросит подтверждения. - Граница «корпус влезает в окно»: откуда ~200k и почему важно число не запоминать, а уметь оценить. - Разбор задачи из чек-листа (если группа уже сформулировала свои ответы — сверка с ориентиром из главы). - Запасной материал при технических вопросах по слайдам: все опорные кейсы есть в главе (части 1–5) с атрибуцией.