Transcription
Вы каждый день используете курсор, код, чат, ChatGPT. Но чем кодинг отличается от агентик workflow? В чём разница между промтами и контекст-инжинирингом? Когда нужен RAG, а когда файнтюнинг? Если на половину вопросов вы не ответили уверенно, это видео для вас.
И инструменты изменились. То, что год назад было экспериментом, сегодня — продакшн. Вот код, курсор, Win-GPT — это уже не игрушки. Но вот проблема. Разработчики используют эти инструменты вслепую, не понимая базовых концепций. Многие думают, ChatGPT работает из коробки. Научились писать промты — и готово. А вот и нет. Промт-инженерия — это как руль в машине. Важно, да? Достаточно? Нет, вам ещё нужно понимать, как работает двигатель, тормоза, чтобы не врезаться в стену на полном ходу.
В продакшн ошибка может стоить дорого. Вы можете потратить недели на разработку системы, которая работает непредсказуемо, или сжигать бюджет на API, потому что не понимаете, где нужен был кэш, а где локальная модель. Не просто прикрутим LLM, а осознанная архитектура. Понимание фундаментальных концепций — это разница между "работает иногда" и "работает надёжно".
Привет, меня зовут Дмитрий Березницкий. Я в разработке с начала двухтысячных. Строил системы, проектировал архитектуры, запускал всё это в продакшн. Поэтому на ML я смотрю глазами инженера-практика, а не ML-исследователя. И вот хорошая новость. Для работы с production вам не нужна глубокая математика. Нужно понимание ключевых концепций и умение их применять.
Сегодня мы разберём:
* LLM или агент — что вы на самом деле используете?
* Контекст-инженерия. Почему это важнее промтов?
* LLM или агентик-кодинг — две философии ML-разработки.
* RAG или файнтюнинг — когда что использовать.
* Foundation Models, MLOps, MOE — архитектурные концепции.
* И AI Security — то, о чём редко говорят.
Поехали.
Окей, вы знаете, что такое LLM? Ну, как эта штука работает на самом деле? Давайте откроем капот. Многие думают, один токен равно одному слову. Верно? Нет. Токен — это базовая единица текста, с которой работает LLM. Это может быть слово, часть слова или даже символ. Вот как это работает. Давайте возьмём разные токенайзеры и сравним. Для начала возьмём слово "программирование". И посмотрите, в разных токенайзерах оно может разбиваться совершенно по-разному. Где-то из него получится три токена, где-то — шесть, где-то — 17. А если мы пойдём по всем моделям, мы увидим абсолютно разное разбиение по токенам. И давайте возьмём слово "слово". Оно же будет разбиваться или на один, или на два токена.
Токенизация — это первый шаг обработки. Текст разбивается на токены. Каждому токену присваивается уникальный числовой идентификатор, а затем эти ID преобразуются в векторные представления — эмбеддинги, которые модель уже может обрабатывать.
Почему же это важно? У каждой модели свой токенайзер. Одна и та же фраза в GPT, Claude, Gemini займёт разное количество токенов, а это влияет на стоимость API. Вы платите за токены, размер контекстного окна — сколько информации видит модель — и скорость обработки. Русский текст часто требует больше токенов, чем английский, в популярных моделях. В среднем, примерно от полутора до двух раз, местами выше.
Почему популярные LLM-модели преимущественно обучены на английском языке? Английских данных в разы больше, чем русских, в тренировочных датасетах. Почему же это критично при работе с ними? Все API тарифицируются по токенам. Больше токенов — больше денег. Если у модели контекст 128 000 токенов, то для английского текста это примерно 250–300 страниц, а для русского — это только 100–150 страниц эквивалентного объёма информации.
Attention-механизм. Как модель понимает контекст. Представьте предложение: "Сеньор-разработчик посмотрел на код, он сломался". Стоп, кто сломался? Кот или синьор? Вы автоматически понимаете, что относится к коду, а не к разработчику. Хотя, конечно, бывает по-разному. Как же модель это делает? Self-attention-механизм, который для каждого токена вычисляет, насколько важны для меня остальные слова. Токен смотрит на все предыдущие слова и вычисляет веса связи и получает максимальный вес для слова "код". Модель понимает контекст. Для тех, кто хочет копнуть поглубже, есть формула из статьи "Attention Is All You Need".
Multihead attention — параллельная обработка. Но модель не просто один раз смотрит на текст, она смотрит множество раз одновременно через разные головы внимания, или attention heads. Представьте, что вы читаете код на ревью, и у вас три головы. Одна голова ищет синтаксические связи: какие переменные с чем связаны. Другая голова следит за типами данных: что куда передаётся. Третья же ваша голова анализирует логику: какие условия от чего зависят. И все головы работают параллельно, результаты объединяются, и получается полное понимание. Современные модели используют десятки голов внимания на каждый из десятков слоёв. Точные цифры не так важны. Важно понимать принцип — параллельная обработка в масштабе. Но если кому интересно, из известных моделей Llama 3.1 — 64 головы внимания на слой, 80 слоёв. А для GPT, Claude архитектура закрыта, но я думаю, что величины примерно такие же. Важно: специализация голов не задана заранее, она формируется случайно во время обучения.
Трансформер — революция. Всё, что мы обсудили — self-attention, multihead attention — это ядро архитектуры трансформеров. GPT, Claude, Llama, Gemini — все построены на трансформерах. Что сделало трансформеры революционными? До них были рекуррентные сети. Они читали текст последовательно: первое слово, потом второе, потом третье. Медленно. Трансформеры обрабатывали все токены одновременно благодаря attention-механизму. Это радикально ускорило обучение и дало возможность обучать модели с сотнями миллиардов параметров. Именно поэтому за несколько лет AI сделал такой скачок.
Звучит круто, но есть фундаментальная проблема. Attention вычисляет связь каждого токена с каждым. 2000 токенов — 4 миллиона операций. 4000 токенов — 16 миллионов операций. Удвоили контекст — вычисления выросли в четыре раза. Вот почему длинный контекст медленнее и дороже. Вот почему модели с миллионами токенов контекста — это всё ещё челлендж. Так что трансформеры захватили мир AI. Огромная инфраструктура. Лучшее качество на большинстве задач стало стандартом индустрии. Но квадратичная сложность — это узкое горлышко. И сообщество активно ищет решение. И сейчас стали появляться гибридные модели — комбинация трансформеров и альтернативных механизмов. Трансформеры сейчас — это стандарт де-факто, но их ограничения уже ощутимы. Следующие 2–3 года покажут, останутся ли трансформеры доминировать или гибридные архитектуры станут новой нормой. А пока понимание трансформеров критически важно. Именно они под капотом у Cursor, Claude, Code, ChatGPT — всех инструментов, которые вы используете каждый день.
Так вот, теперь, понимая ограничения и механику, вернёмся к контекстным окнам. Представьте, вы работаете с AI-ассистентом над большим проектом. Договорились об архитектуре? Всё отлично. Через 20 сообщений модель вдруг игнорирует ваши изначальные инструкции. Что случилось? Проблема с контекстным окном. Но почему это происходит и, главное, как этого избежать? Давайте разбираться.
Начнём с самого начала. Что же такое контекстное окно? Это рабочая память вашей модели. Сколько токенов она видит одновременно. Представьте ваш стол. Маленький стол — 4000 токенов: ноутбук плюс чашка кофе. Места больше нет. Большой стол на 200 000 токенов: два монитора плюс ноутбук, плюс книги, записки, наушники и так далее. Всё, что надо для работы, рядом. Но на практике токены заканчиваются быстрее, чем кажется.
Давайте посмотрим, что у нас находится в контекстном окне. Системный промт плюс история плюс ваш текущий запрос. На выходе нам даст что? Ответ, который при следующем запросе у нас будет помещён в историю. Так вот, это всё и должно влезть в наше контекстное окно. Но в AI-ассистентах к нам добавляются ещё tools — это определение функций, которые модель может вызвать. Чтение файлов, выполнение API, команды, поиск и результат их вызовов. А это содержимое открытых файлов, вывод bash-команд, результаты поиска по проекту, история действий. Что же сделано, какие файлы изменены. Реальный пример: Claude Code открыл пять файлов по 200 строк каждый, выполнил три bash-команды с выводом, сделал поиск по проекту. Итого 15 000 токенов только на Tools. И это всего за один вызов нашего агента.
Как понять, что контекст переполнен? Ответ обрывается на полуслове. Модель забывает начало разговора, начинает повторяться, игнорирует инструкции из начала диалога, запрашивает файлы, которые уже открывала.
Code, Cursor, Wn.GPT — они автоматически сжимают старые части разговора при переполнении контекста. Звучит удобно, но есть один подвох. При суммаризации теряются детали архитектурных решений, история изменений. Почему мы это так сделали? В контекст вызовов Tools модель может забыть, что она уже это делала до этого. Определение вспомогательных функций. Результат: модель начинает запрашивать уже открытые файлы или теряет понимание, почему код написан именно так.
Что же делать? Если вы работаете через API, то суммируйте историю самостоятельно и оставляйте в ней только то, что вам действительно надо в текущий момент. Если же работаете с AI-ассистентами, то следите за размером контекстного окна. При сложных задачах начинайте новый чат в подробном резюме. Не полагайтесь полностью на автосжатие. Это всё же больше костыль, а не решение.
Даже с огромным контекстным окном токены расходуются быстрее, чем кажется. Tools съедает контекст невероятно агрессивно. Каждый открытый файл, каждая команда, каждый результат поиска — это сотни или тысячи токенов. В AI-ассистентах вы упираетесь в лимит раньше, чем в обычном чате. Проактивно управляйте контекстом. Понимание контекста — это разница между "AI помогает" и "AI тупит".
Давайте разберёмся, почему же GPT печатает ответ. Вы когда-нибудь задумывались, почему ответ появляется слово за словом, а не всё сразу? Генерация происходит в два этапа, и они работают радикально по-разному.
Этап первый: префил, предзагрузка. Ваш промт — 500 токенов. Модель обрабатывает все 500 токенов параллельно за 1 секунду. Это как прочитать страницу текста одним взглядом.
И этап два — декод, генерация. Модель генерирует ответ: 200 токенов, но каждый токен генерируется последовательно, один за одним. Нельзя распараллелить. Это как писать текст. Каждое следующее слово зависит от предыдущих. Результат: 200 токенов генерируется за 3–5 секунд.
K-V Cache. Почему модель не пересчитывает всё заново? Проблема: при генерации каждого токена модель заново смотрит на все предыдущие. 1000 токенов — 1000 пересчётов, и это медленно. Решение называется K-V Cache. Модель сохраняет результаты attention для уже обработанных токенов в памяти.
Префил: обрабатываем промт, заполняем кэш. Декод: используем кэш, считаем только новый токен. Результат — ускорение в разы. Вот почему первый токен появляется медленнее остальных.
Почему же аутпут дороже, чем инпут? Разберём на примере Claude. Давайте посмотрим актуальные цены Claude Code на Sonar 4.5. Инпут — 3 доллара за 1 млн токенов. Аутпут — 15 долларов за 1 млн токенов, что в пять раз дороже. Причина: инпут или префил — параллельная обработка, быстро. Аутпут или декод — последовательная генерация, и это медленно. Кэш растёт с каждым токеном, больше памяти. Важно: у разных провайдеров цены, конечно же, сильно отличаются. Я как пример написал про GPT, но у всех аутпут будет дороже, чем инпут, примерно в 3–5 раз.
Давайте разберём практический пример, сколько же стоит ваш запрос. В сценарии у нас будет AI-ассистент с документацией. Наш промт будет состоять из системного промта плюс документация на 10 000 токенов. Добавим сюда вопрос нашего пользователя — ещё плюс 100 токенов. Итого наш инпут будет равен 10 100 токенов. Ответ модели, ну, пусть будет 500 токенов. Рассчитаем для тех цен, которые мы указали для Claude. Инпут: итого инпут у нас будет стоить 3 цента. Аутпут же будет стоить 7,5 цента. И итого за один этот запрос мы с вами получим практически 10,5 цента. 1000 же таких запросов в день нам с вами дадут сколько? 105 долларов в день. А в месяц это у нас получится 3150 долларов.
Вы меня спросите: зачем же мы с вами всё это посчитали? Для того, чтобы разобраться с очень важным пониманием, как можно снизить эту стоимость. И сейчас мы с вами поговорим про кэш. Claude предлагает работу с кэшем. И кэш делится на две части: запись кэша и чтение из кэша. Для записи в кэш нам придётся потратить немного больше, чем на обычный инпут. И это будет на 25% дороже. У нас получится на запись 3,75 доллара за 1 млн токенов. А вот чтение из кэша будет стоить 30 центов за 1 млн токенов. И это позволяет сделать всю нашу систему дешевле на 90%. При этом время жизни кэша — 5 минут, но обновляется при каждом использовании.
Давайте посмотрим, как же будет работать вся эта система, если мы будем использовать кэш. Запись будет немножко дороже — 3,75. Поэтому итоговая стоимость также будет чуть дороже — 3,75. И итоговая стоимость у нас изменится, станет чуть-чуть дороже. Но при этом чтение из кэша нашего документа на 10 000 токенов нам будет теперь стоить 3 доллара. Итоговая стоимость второго запроса у нас уже будет сильно меньше, примерно 4 доллара. И это получается, ну, не на 90%, как я сказал, ну, примерно на 70% дешевле. На 1000 запросов в день. Это у нас получается не 105 долларов в день, а уже 30 долларов в день или примерно 900 долларов в месяц. Вот мы только что с вами сэкономили 2250 долларов, просто правильно используя кэш.
При этом есть дополнительные способы экономии. У Anthropic есть такая штука, как Batch API, и она даёт пятидесятипроцентную скидку. Это используется для неспешных задач, где обработка в фоне. И там мы получаем скидку 50% на input и output токены. Это можно использовать для анализа какого-то фидбека от наших клиентов, генерация описания для товаров или самаризация документов, классификация больших массивов данных. Всё то, что нам надо неспешно. Важно: Batch есть не у всех провайдеров, так что нужно проверять актуальную документацию.
Понимание префил и декод и правильное использование кэширования — это не просто теория, это прямое влияние на ваш бюджет. Ведь если у нас эта задача не real-time, то мы в итоге с вами получим даже не 900, а уже 450 долларов в месяц, что в семь раз выгоднее, чем просто наивная реализация и использование API без понимания, как работает кэширование, что у нас input, что output и как всё это вместе можно оптимизировать. Поэтому инвестируйте время в архитектуру промтов и используйте кэширование, понимайте, какие у вас задачи, и это окупится в первый же месяц.
Почему ChatGPT не учится на твоих данных? Частое заблуждение. Если я много общаюсь с ChatGPT, модель учится на моих данных и становится лучше для меня. Нет. Давайте разберёмся, в чём разница между обучением и использованием.
Тренинг. Обучение модели. Это происходит один раз. Берутся терабайты данных. Процесс занимает недели или месяцы. На огромных кластерах GPU стоят десятки миллионов долларов. В результате веса модели обновляются и оптимизируются.
Inference. Использование модели — это каждый ваш запрос. Вы отправляете промт, модель обрабатывает его за секунды. Стоит это центы. И веса не меняются. Модель просто применяет то, чему научилась. Простая аналогия: тренинг — это как скомпилировать программу. Inference — это запуск этой самой программы. Программа выполняется, но код не меняется от использования.
Но ChatGPT же помнит факты обо мне из других бесед. Да, но это фича памяти. Это не обучение модели. ChatGPT использует различные типы памяти: явные факты, которые вы просили запомнить, и историю вашего чата. Система анализирует все ваши прошлые беседы для контекста, и в следующем чате система извлекает релевантные факты и добавляет их в контекстное окно вместе с вашим запросом. Но веса модели при этом не изменились. Это просто умная работа с контекстом.
Провайдеры также могут сохранять ваши запросы для обучения своих моделей в будущем. Для чувствительных данных проверяйте настройки приватности или используйте свои модели. Но как же кастомизировать свою модель? Для этого есть разные подходы: few-shot learning, RAG и fine-tuning. Об этом мы поговорим чуть позже.
Сначала разберёмся с креативностью модели. LLM — это предсказатель следующего токена. На каждом шаге модель может оценивать все возможные варианты. Давайте разберёмся на примере. У нас есть вход: "Я люблю". Какие могут быть варианты следующего слова? Программировать, проектировать, читать, гулять, пить. Но что именно пить, мы пока не знаем, потому что для начала мы должны определиться с текущим словом и только потом будем выбирать следующее. Для слова "программировать" у нас будет самая высокая оценка модели, для слова "пить" — самая низкая. И эти оценки превращаются в вероятности. И температура определяет, насколько модель будет придерживаться наиболее вероятных вариантов или позволит себе выбрать что-то другое.
Для педантов: математически это Softmax с коэффициентом T. Формула на экране. При T, стремящемся к нулю, почти всегда выбирается топ-1 токен. При T, стремящемся к бесконечности, распределение становится равномерным по всем токенам словаря. А их у нас может быть больше 50 000 или сколько там у нас их влезает в нашу модель. И это получится полный хаос. Оптимальное значение температуры зависит от конкретной модели, задачи и требований к балансу между логичностью и оригинальностью. Поэтому полезно экспериментировать. На практике большинство современных моделей показывает лучшие результаты при температуре от 0 до 1,2. Скажем так, креативность с сохранением адекватности. Многие API ограничивают максимальное значение температуры, которое мы можем указать, двойкой. И это не математическое, а практическое ограничение для защиты от полного хаоса.
Top P и Top K — это дополнительные фильтры. Top P: модель накапливает варианты от самого вероятного, пока сумма не достигнет, допустим, 90%. Остальное отбрасывается. Гибкий размер: иногда может быть пять вариантов, иногда — 50. Top K: модель берёт ровно K самых вероятных вариантов, например, 50. Остальные игнорируются. Фиксированный размер: всегда 50, даже если первые три дают вероятность 95%. Как пример: у модели 100 возможных слов. Top P 0,9 возьмёт топ-10 слов, если их сумма равна 90%. Top K, равный 50, всегда возьмёт ровно 50 слов. Большинство разработчиков вставляют дефолтные настройки и удивляются результату. Теперь-то вы знаете, как контролировать поведение вашей модели.
Подведём итог этого блока. Теперь вы понимаете:
* Токены не равны словам, и это влияет на итоговый счёт.
* Attention — это то, как модель понимает связи.
* Контекстное окно — это рабочая память с ограничениями.
* Префил/декод: почему ответ печатается?
* Тренинг или inference? Почему API не меняет модель?
* Температура — контроль креативности.
* И кто такие трансформеры?
И это не абстрактная теория. Это знания, которые помогают оптимизировать затраты, писать эффективные промты, понимать ограничения и выбирать правильные параметры для работы с API.
Окей, теперь вы понимаете, как работает LLM-движок под капотом, но что можно сделать с этим движком на практике? Простой вопрос-ответ, сложное рассуждение с пошаговым анализом, автономные действия через API и инструменты. И это три совершенно разных уровня. И вот в чём между ними разница. Вы поняли механику? Токены, attention, контекстное окно — это фундамент. Теперь практика: что можно строить на этом фундаменте.
Большинство людей думают: "AI, чаты, LLM-генты — это всё одно и то же, просто разные названия одного инструмента". Нет, это три совершенно разных уровня сложности, и понимание разницы — это ключ к профессиональной работе с AI. Представьте кухню. LLM — это шеф-повар, который готовит по рецепту. Один запрос приводит к одному результату. Reasoning model — это шеф, который может импровизировать и думать о вкусных сочетаниях. Агент или agent — это целая кухня с шефом, поварами, кладовщиками, которые работают вместе для создания банкета.
LLM — это базовая модель. Что делает? Получает текст, генерирует текст. Она stateless. Каждый вызов независим. Нет памяти между запросами. Когда она используется: простой вопрос-ответ, генерация текста, анализ одного документа. Ограничение: не может выполнять действия, не имеет доступа к инструментам. Каждый запрос с нуля.
Reasoning model — модель с рассуждениями. Что добавляется? Chain of thought — думает пошагово, разбивает задачу на промежуточные шаги. Дополнительные техники проверки: self-consciousness, множественная выборка, self-reflection — улучшение через критику. И у этих моделей увеличенное время ответа на сложные задачи. Более высокая стоимость за запрос. Некоторые модели показывают процесс мышления, другие скрывают его, когда мы их используем. Сложные логические задачи: математика, программирование, планирование с анализом вариантов. Преимущества: меньше ошибок на сложных задачах, прозрачность рассуждений (где это доступно).
А вот агент — это уже совсем другое. Это автономная система. И давайте посмотрим, что же она в себя включает. И первое, что мы рассмотрим — это observe. Он наблюдает текущую ситуацию. Следующий шаг — reason — рассуждает, после этого приходит к действию. Здесь может быть вызов для каких-то внешних API. И после этого он повторяет цикл для достижения целей. Очень часто называют это как ReAct: Reasoning плюс Action. Мысли, действия и наблюдения чередуются. Модель сама решает, когда нужно больше рассуждений, а когда переходить к действию. При этом в фазе action у нас может быть вызов tools — это доступ к внешним инструментам: вызов API, вызов внешних систем, файловая система (чтение или запись файлов), исполнение кода, выполнение команд. При этом важный момент: так как у нас множество циклов возможно, нам надо сохранять контекст между шагами. И для этого нам с вами нужен state-менеджмент. И он может быть в памяти для текущих сессий, в векторных базах для семантического поиска, файлах или базе данных для долгосрочного хранения. При этом агент у нас может планировать и рефлексировать. При планировании он разбивает сложные задачи на подзадачи, при рефлексии оценивает свои решения и улучшает их. При этом всё можно собрать в мультиагентскую систему из нескольких специализированных агентов. И они работают вместе. Один исследует, другой тестирует, третий пишет код.
Ключевое отличие агента. Давайте возьмём какой-нибудь пример из разработки. Допустим, у нас есть баг в системе авторизации, и вы закидываете это в ChatGPT или просто куда-то в чат-модель: "Вот код. Найди здесь баг и исправь его для авторизации". Модель находит проблему в строке 42 и говорит: "Вот здесь проблема, дальше действуйте сами". Всё. А агент может сделать полный цикл. Он может прочитать код, проанализировать, найти баг, исправить этот код, запустить тесты, потом создать коммит и запустить deployment в dev-environment. После этого может проверить, что там всё запустилось и работает исправно. Агент помнит состояние между шагами: "Я исправил код, тесты прошли, можно деплоить". LLM так сделать не может.
Простое сравнение:
* LLM как консультант: один вопрос приводит к одному ответу без действий.
* Reason как аналитик: думая вслух, проверяя логику, объясняя.
* Агент — это же инженер: планирует, действует, проверяет, корректирует.
Почему же важно понимать AI-чаты в браузере, такие как ChatGPT, Code Gemini? Базовая — это LLM + AI с псевдопамятью. История чата отправляется заново. Современные версии имеют много плюсов. Они могут вызывать какие-то функции, искать в интернете, выполнять код, загружать файлы. ChatGPT и Claude имеют функции памяти, но это управляется приложением, а не самой моделью. Контекст сбрасывается между отдельными сессиями.
AI-ассистенты, такие как Code, Cursor, Wn.GPT — они имеют полный доступ к окружению. Они работают со стейтом, могут посмотреть файлы, залезть в Git, вызвать команды терминала. Весь контекст в рамках сессии.
Когда же вы строите свою систему и у вас простой вопрос-ответ, LLM достаточно. Это дешевле и быстрее. Если же у вас сложная задача с анализом, воспользуйтесь Reasoning Model. Это будет точнее и надёжнее. Если же у вас мультишаговый процесс с множеством действий, то вам надо идти в сторону агентов. И это у нас будет автоматизация. У него будет стейт, у него будут тулы, он сможет планировать или делать рефлексию.
Теперь критический вопрос. Как агент узнает, что ему делать? Вы можете дать ему доступ к 100 инструментам, но если он не понимает контекст задачи, он бесполезен. Как правильно структурировать информацию? Как давать агенту именно то, что нужно? Вот тут начинается контекст-инжиниринг. Все помешаны на промт-инжиниринге. "10 магических промтов", "лучший промт для продуктивности", "один промт изменит вашу жизнь". И да, промт важен, но вот что никто не говорит: промт — это лишь вершина айсберга. Основа результата составляет контекст.
Пример: бронирует отель. Представьте, вы отправляете AI-агента забронировать отель. Промт: "Забронируй отель в Париже на конференцию на следующем месяце".
Попытка номер один. Результат: Best Western Paris Inn, город Париж, штат Кентукки. Проблема: недостаточно точный промт, не указали страну.
Попытка номер два. Улучшили промт: "Забронируй отель в Париже, Франция, на конференцию". Результат: Риц Карлтон. 900 евро за ночь. Шампанское, ужин включены. Проблема: промт идеальный, но AI не знает ваш бюджет. Это уже не промт-инжиниринг, это контекст-инжиниринг.
Попытка номер три. С контекстом: тот же промт, но теперь система знает до вашего вопроса: корпоративный лимит на отель — максимум 150 евро на ночь. Ваш календарь — конференция, 15–17 марта. Локация — центр Парижа. Результат: выбор отеля максимально рядом с вашей конференцией и в вашем бюджете.
В чём разница?
* Промт-инжиниринг: Что вы говорите? "Забронируй отель в Париже, Франции".
* Контекст-инжиниринг: Что система уже знает? Корпоративные правила: календарь, бюджет, локация.
Андрей Карпатый, бывший директор AI в Tesla: "Промты — это короткие описания задач, но в промышленных приложениях контекст-инжиниринг — это искусство и наука заполнения контекстного окна правильной информацией". Разница не в том, как вы спросили. Разница в том, что система знала до вашего вопроса.
На этот же счёт Тоби Лютке, CEO Shopify: "Контекст-инжиниринг — это искусство предоставления всего контекста для задачи, чтобы она могла быть решена".
LLM промт-инжиниринг — это техника формулировки. Как вы формулируете инструкцию для техники?
Первое — это role prompting. Назначение роли: "Ты сеньор-разработчик с десятью годами опыта".
Второе — few-shot examples. Обучение на примерах. Показать два-три примера: "Вот такой запрос. Вот такой ответ".
Третье — chain of thought. Цепочка рассуждений. "Думай пошагово" или "Давай по шагам".
Четвёртое — формат ответа. "Ответь в формате JSON".
Пятое — ограничения. "Используй только стандартную библиотеку".
Когда это работает? Изменить стиль ответа, уточнить формат, задать ограничения. Когда это не работает: если AI не знает информации, никакой промт ему не поможет; если нет доступа к инструментам; если контекстное окно переполнено.
Контекст-инжиниринг — это системная архитектура. Пять компонентов контекстной инженерии.
Компонент первый: memory management или управление памятью. Short memory — это последние сообщения диалога. Проблема: контекстное окно ограничено. Решение: суммаризация старых сообщений. Мы можем посмотреть, что
делает чат GPT за вас. Держит последние 20-30 сообщений, суморизирует начало при переполнении. Вы этого не видите, но это контекстная инженерия.
Если же строите своего агента, то это будет полностью ваша задача. Long term memory - это знания между сессиями. Где мы это храним? Базы данных или файлы.
Компонент второй - retrieval. Рак - это какие документы релеванты? Динамическое добавление контекста. У вас 1.000 документов, контекстное окно только 100.000 токенов. Решение находить и добавлять только релевантные документы. И это часть контекстной инженерии.
Компонент третий. Управление состоянием. Где мы находимся сейчас в процессе? Многошаговой задачи требуют состояния. Давайте рассмотрим пример. Шаг первый. Нам надо проанализировать код. И в этом процессе мы можем просматривать всю кодовую базу. Это может занять всё наше контекстное окно. Но как выход, мы можем найти баг. И этот баг будет в файле на строке 42. Далее мы передаём эту информацию в шаг номер два, и он у нас может быть в абсолютно чистом контекстом окне. Шаг будет заключаться в том, чтобы исправить этот баг. На выходе у нас будет состояние зафиксили баг. Далее мы стартуем третий шаг. Какой же это шаг? Правильно, это шаг тесты. И дальше у нас есть два варианта. Тесты у нас были успешными. И тогда мы завершаем наш цикл, говорим, что всё исправлено. Либо у нас тесты зафейлились. И тогда мы начинаем с самого начала. Мы начинаем искать проблему, почему были зафейлены тесты. Это может стартануть новый шаг. Дальше исправляем, дальше тестируем. Итак, до тех пор, пока наши тесты не пройдут. Так что state - это часть нашего контекста.
Компонент четвёртый. Tools или инструменты - это какие инструменты доступны? Агент знает о своих возможностях. Работа с кодом. Прочитать файл, запустить тесты. Может быть внешней системы поиск в интернете, запрос к базе данных или интеграции. Может создать пулреквест или отправить уведомление в ск. Список инструментов - это контекст.
Компонент пятый - это динамическая сборка нашего промта. Давайте напишем наш финальный промт. Что входит в финальный промт? Это у нас будет статическая часть. В неё у нас входят системные инструкции и динамическая часть. В неё у нас входит память и история плюс извлечённый контекст плюс текущее состояние. И, конечно же, наш запрос, который написал пользователь. Так вот, промнжениринг - это и есть вот этот самый последний запрос, самая последняя строка, что написал наш пользователь. А контекст инжениринг - это всё остальное. Почему я говорю всё это контекстная инженерия? Потому что промт - это просто триггер. Результат определяется контекстом.
Две философии работы CI. Первая философия вайпкодинг. Контекст собрали за вас. Если работаешь чат GPT или код в режиме чата и говоришь: "Напиши функцию авторизации", после этого просто копируешь свой проект или, возможно, используешь уже полноценные платформы для этого Lavable, Replid и другие. Эти платформы уже настроили контекст. Структура проекта готова, база данных интегрирована, деплой в один клик. Вы просто промтите, сделай-дукейш с авторизацией. Какие же у этого преимущества? Быстрый старт. Можно сделать пof ofв concept за час. Не нужно думать о настройке. Работает из коробки. Но есть ряд ограничений. Фокус на веб-приложениях. Вы ограничены рамками платформы. Также происходит venderlog, и он варьируется между платформами.
Вторая философия агентик coding или agentic workflow. Вы управляете контекстом. Здесь у нас множество инструментов: квот-код, курсор, пенср и многие другие. Вы строите контекст, вы выбираете архитектуру, настраиваете окружение, управляете состоянием и памятью, контролируете каждый файл. И я и помогает, но вы контролируете. И у этого есть ряд преимуществ: полная гибкость. Это может быть любой стек, любая архитектура. Это может быть работа с продакшн кодовыми базами данных. При этом прозрачные подходы. Вы контролируете использование API или используете подписку. Ограничение: нужно понимание контекстной инженерии. Также нужна высокая инженерная культура, чтобы делать поддерживаемые проекты. Вай-кодинг - это значит контекст инжениринг сделали за вас. Удобно, но сильно ограничено по возможностям и качеству. агентин кодинг значит, что вы управляете контекстом. Сложнее, но мощнее. Оба используют агентов. Разница лишь в том, кто управляет контекстом.
Хорошо, контекст критичен, но откуда брать же этот контекст? Как дать и яй знания, которых у него нет? И есть для этого три способа. У вас есть LLM Foundation модель от Open AIP Elementa. Она знает много, но у неё три фундаментальных ограничения. Первое ограничение - данные до определённой даты. Пример расскажи проли GP5 приведёт к я не знаю мои данные до 2024. Второе ограничение нет специфических знаний в предметной области. Например, как наша компания обрабатывает возвраты, модель не знает. Третье ограничение. нет доступа к вашим приватным данным. Пример, сумморизируй последний отчёт груминга бэклога. Конечно же, он этого не видит. И как же нам решить эту проблему? Есть три способа. И вот в чём большинство ошибаются. Они думают, что есть лучший способ. Нет, есть правильные инструменты под конкретную задачу. Давайте разберём все три и поймём, когда какое использовать.
Способ первый: incext learning. Что же это такое? Это когда мы добавляем информацию прямо в контекст. Например, вот наша политика возвратов. Дальше идёт 500 слов текста. И потом мы задаём вопрос: могу ли я вернуть товар через 40 дней? Плюсы, это мгновенно. Ответ приходит за секунды. С точки зрения обучения это бесплатно. У нас нету дополнительных расходов на обучение. Также у нас полный контроль. Мы можем поменять всё это на лету. Есть прозрачность, видно то, что мы добавили. Но есть ряд минусов. Мы ограничены размером контекстного окна модели. Дорого при нагрузке и большом количестве запросов, потому что мы платим с вами за токены каждый раз. У нас нет обучения. Модель не запоминает между запросами. Когда это можно использовать? Когда у нас с вами есть несколько документов, и они не очень большие, и это разовые задачи. Или, возможно, мы тестируем подход прежде чем внедрять рак или findтюниing.
Способ второй RAК retrieval Augmented generation. Как же это работает? Первый шаг: мы храним десятки тысяч документов в векторной базе данных. Шаг второй. Для каждого запроса находим топ-пять релевантных фрагментов информации. Шаг третий: добавляем в пром только эти пять фрагментов. Шаг четвёртый. LM отвечает на основе найденного. Например, пользователь просит рассказать политику возвратов для электроники. И прежде чем отправить этот запрос в LM, мы ищем в нашей векторной базе релевантную информацию и находим несколько документов. Допустим, мы находим документ номер 23, в котором описана политика возвратов в нашей компании. Но также мы нашли документ 126, в котором написаны исключения для электроники. И после этого мы с вами собираем наш промт, который будет включать в себя что? Системные инструкции. Плюс мы добавим оба документа, которые мы нашли в нашей векторной базе данных. Плюс добавим сюда вопрос нашего пользователя, и LM генерирует ответ на основе найденной информации. Плюсы такого подхода: масштабируемость. Мы можем хранить миллионы документов. Актуальность: обновили документ и сразу его используем. Также есть прозрачность. Мы знаем, что откуда берётся, и это дешевле, чем файнтюнинг. У нас нету обучения модели. Но также есть минусы. Задержка ответа. Нам надо сделать запрос к векторной базе. Инфраструктура. Нам нужна векторная база данных. Нам нужна модель для создания эмбедингов. Нам надо следить за качеством нашего ретривал, потому что плохие документы дают плохой ответ. Когда же нам это использовать? Когда у нас большие базы знаний, когда у нас есть, может быть, временные знания или они часто у нас обновляются. Если хотите разобраться с этим подробнее, посмотрите моё предыдущее видео про prod продаction RCK для того, чтобы понять, как это работает в деталях.
Способ третий файнтюнинг или переобучение модели. Что это и для чего? Это значит, что мы дообучаем модель на наших данных, чтобы она запомнила знания или стиль. И основной подход для этого Lora. Low Run Adaptation. Как работает Lora? Базовая модель остаётся замороженной. Добавляются только маленькие адаптеры. 1,5% от параметров. Как пример, лама 70 млрд параметров, адаптер- 100 млн параметров. Это 0,14%. Плюсы: знания запекаются в модель. Быстрее при генерации ответов нет ретри. Мы можем глубоко изменить стиль ответов. Модель усваивает специализированную терминологию. Такой подход в 10, а то и в 100 раз дешевле полного файтюнинга. Минусы. В любом случае это дорого. Нам нужны GPU для обучения, часы или дни работы. Долго. Это требует переобучения при каждом обновлении. И есть риск катастрофического забывания. Когда же это использовать? Специализированная терминология, медицина, юриспруденция, финансы. Или, возможно, нам нужен какой-то особый стиль, формальный или краткий. При этом наши данные стабильны и редко меняются. Также есть продвинутые варианты, quantтаedст. Лора плюс квантизация модели, то есть четырёхбитная вместо шестнадцатибитной. Также есть ещё большой раздел о файнтюнинге. Это файтюниing бединг моделей. То есть мы обучаем не LM, а модели для имбедингов. И это очень надо, когда мы хотим улучшить качество рак. Это намного дешевле, чем файтюнинг полных моделей. Файтюнингбедингов заметно повышает релевантность, особенно на специализированной терминологии.
Итак, давайте же разберёмся, когда и что у нас использовать. И для этого нам надо будет ответить сначала на один вопрос: а данные у нас меняются часто или не очень? Если мы отвечаем на него да, то дальше будет вопрос: а насколько много у нас этих данных? Сколько это документов? Если их много или мало, то мы можем выбрать два разных подхода. Если много, то это у нас будет рак. Если же мало, то у нас это будет incontext learning. Если же данные меняются нечасто, то у нас будет дополнительный вопрос: нужна ли нам специфическая терминология или стиль? И если нам нужна терминология или стиль, то мы с вами выбираем, что файнтюнинг. Если же нам не нужна специфическая терминология или стиль, то у нас будет точно такой же вопрос: а много или мало у нас документов? И если у нас мало документов, мы приходим к инкокстлернингу. Если же у нас много документов, мы приходим с вами к рагу.
Итак, какой же приоритет техник по порядку внедрения? Давайте разберёмся. И первое - это будет incontext learning. Он нам подходит для того, чтобы мы могли тестировать идеи или как-то с ним работать, проверять, что и как у нас пойдёт. Вторая у нас будет с вами рак. Здесь у нас будет база знаний, актуальные данные. И только в третью очередь мы выберем файнтюнинг, если он нам действительно нужен. И только после того, как мы выбрали, попробовали, пошли по этому пути, мы занимаемся оптимизацией, то есть по мере необходимости. И для раксистемы это у нас будет ранкинг либо файтюнинг edдинг модели или возможно гибридный поиск рак через векторную базу и bм25 через какую-то другую базу. При этом, если мы занимаемся файтюнингом, то можно его тоже по-разному файтюнить. Можно сделать лора, можно сделать кулора. Вот смотрите, что будет эффективней. При этом следуем золотому правилу. Начинаем с простого и потом усложняем. И при этом всё у нас должно быть измеримо. Приэтому не забываем покрывать всю нашу систему чем? Правильно, метриками.
Два подхода к использованию LM через API. Это использование API провайдеров Open AI, Antropic, Google. Плюсы: без настройки работает сразу. Автоматическое обновление модели, масштабирование за нас. Минусы: расходы часто бывают не совсем предсказуемые. Каждый запрос стоит денег. Мы платим за каждый токен в промте и в ответе. Данные при этом идут к провайдеру, и здесь встаёт вопрос приватности. Так вот, сехост модели, такие как Мистраль и другие, они дают нам множество плюсов. Предсказуемые расходы - это аренда GPU, и она фиксирована, приватность, данные остаются внутри нашей инфраструктуры. Кастомизация. Мы можем сделать файн под себя. Минусы: нам нужна инфраструктура, GPU-серверы, деплоймент. Надо за всем за этим следить. При этом эти модели, к сожалению, дают меньше качества. То есть open source они отстают отк или от GPT5. Когда же пользоваться этими моделями, когда у нас с вами высокий трафик и большие расходы или приватность для нас критична, а может быть и то, и то?
Давайте разберём с вами какой-нибудь простой пример. Например, юридический AI assistant. Из чего же он у нас будет состоять? Компонент первый - это базовая модель. Для него возьмём для примера лама. Но не просто, а мы сделаем файнтюнинг на юридических данных. Как результат, наша базовая модель знает юридическую терминологию и нужный нам стиль. Компонент второй - рак. И в эту базу данных мы поместим юридические прецеденты. Как результат, у нас будут актуальные судебные решения. И добавим сюда наш промтинг. И в нём мы будем указывать, что нам нужны ответы в определённом юридическом стиле. Итого, наша модель говорит на юридическом языке, потому что был файнтюнинг. Она знает свежие прецеденты, потому что у нас есть рак, и она отвечает в нужном нам юридическом формате.
Звучит хорошо, но откуда же берутся сами модели? Зачем нам нужны Foundation Models и почему нам не нужно обучать свою модель с нуля? Для обучения модели с нуля нужны питабайты данных 1.000 GPU от 50 до 300 млн долларов. И это только начало. Цена растёт каждые 3 года. Кто же это делает? Open AI, Antropic, Meta, Google. Только они могут себе это позволить. Вместо этого Foundation Models изменили правила игры. Вы берёте готовую модель и адаптируете. Так, что же такое Foundation Model? Это большая модель, обученная на огромном корпусе данных, которая понимает язык в целом и может быть адаптирована под конкретные задачи через файтюнинг или через пром.
Два мира Foundation Models. Первый мир - это закрытые. Они нам дают только. И основные провайдеры всё те же самые. Open AI, Antropic, Google, Meta. Плюсы: лучшее качество, постоянное улучшение, ненужна инфраструктура. Минусы: дорого при масштабе, зависимость от провайдера. и данные уходят наружу. И второй мир - это open source модели. Их можно разворачивать у себя. Основные провайдеры - это Metalлаama. От 8 млрд до 400 млрд параметров. Крупнейшие открытые модели. Страл- быстро и эффективный от 7 до 120 млрд параметров. Microsoft F4 млрд параметров. Конкурирует с моделями в пять раз крупнее. Также есть модели от IBM серии Гранит. Они тоже довольно-таки интересны. Плюсы полностью бесплатные, их можно скачать. Полный контроль и файтюнинг. Приватно, данные остаются при вас. Минусы: качество чуть ниже топовых моделей. Нужна своя инфраструктура и GPU.
Почему же Foundation Model - это революция? Раньше адаптировали только имбединги или последний слой, а сейчас адаптируют целую интеллектуальную систему. И три важных следствия. Первое следствие: файнтюнинг стал доступным. Раньше нужна была команда ML Resarchers месяцы работы. Сейчас разработчик может за выходные на своём ноутбуке слора. Второе следствие цены на модели. Да, старые модели дешевле. GPT4 упал на 90% за год, но новые флагманские дороже. Ризани модели в 10 раз дороже обычных. Рынок рассваивается. Дешёвые для всех, премиум для сложных задач. Третье следствие. Выбор базовой модели критичен. Плохая модель- плохой результат. Тоже после файтюнинг. Хорошая базовая модель- отличный результат с минимальной адаптацией. Главное, вы не обучаете модель понимать мир. Это уже сделано. Вы учите её понимать вашу конкретную задачу.
Итак, у нас есть с вами умная модель. Но как подключить её к реальным системам, допустим, Гитхабу или к базе данных или к вашим каким-то внутренним инструментам? Раньше для каждого инструмента писали отдельный адаптер, куча кода и хаос. В конце двадцать четвёртого года антроopic предложил решение model context протокол. И это стало единым стандартом подключения EI к системам. Это примерно как USBC, только для агентов. Один протокол и AI понимает, как общается с любым сервисом. MCP описывает три примитива: Tools, и это действия, которые мы можем совершать со внешней системой resources. И это данные только для чтения. Там могут быть документы, файлы, все любые данные абсолютно и prompts. Здесь же будут лежать шаблоны для типовых запросов. И главная фича всего этого: агент сам узнаёт, какие действия ему доступны. Никаких хардкодных интеграций, всё работает через Goner PC 2.0. У меня есть детальное видео про MCP, ссылка в описании. Правда, с того момента записи протокол уже сильно улучшился, но в целом все базовые концепции и определения можете там посмотреть.
Итак, у нас есть стандарт для подключения к системам. Модели становятся умнее, но есть проблемы. Чем больше модель становится, тем она дороже. И как сделать умнее нашу модель без роста стоимости? Последние две концепции - это взгляд в будущее. Вам не нужно их применять завтра, но понимать тренды критично, если вы хотите не остаться позади через год. Главный вопрос индустрии. Чем больше параметров, тем модель умнее. Но больше параметров - это значит дороже и медленнее. При каждом запросе активируются все параметры: дорого, медленно. Как сделать модель умнее без роста стоимости? Mixure of experts или MOA. В традиционной модели каждый запрос активирует все параметры. Моя модель, она работает по-другому. Она делится на экспертов. И есть маленькая сеть маршрутизатор. Соответственно, у нас есть пользователь, который отправляет нам запрос. Сеть маршрутизатор по запросу определяет, какие эксперты нужны, и активирует только их. Допустим, у нас будет 10 экспертов. И наша модель определяет, что для текущего запроса нам нужны эксперты по программированию и по математике, и отправляет им запрос. При этом все остальные эксперты остаются незадействованными. Если же у каждого эксперта будет по 20 млрд параметров, то вместе это всё будет 200 млрд всего. Но для каждого запроса мы используем только два или три эксперта, и это будет намного меньше с точки зрения активации количества параметров, которые нам нужны для решения конкретной задачи. Как результат, качество большой модели, цена для маленькой. Сейчас на рынке есть IBM Granit, который как раз-таки использует MOE и Mixtr от Mrл AI. и их уже можно потестировать в prodдаction.
Итак, следующая концепция AGI и ACI. И они нам говорят о том, куда мы с вами идём. AI artificial General Intelligence и который может делать любую когнитивную задачу на уровне человека. И он универсален, как человеческий мозг. Статус на текущий момент ещё не достигнуто, но близко. А CIй же - это artificial super intelligence. и я, и который превосходит человека во всём. То есть он у мне самого лучшего математика, самого лучшего физика, самого лучшего программиста. И во всём в этом сразу. Текущий статус - это полностью теоретическая концепция, и она пока не достигнута совсем. Итак, куда же мы с вами движемся? Мое текущая концепция, которая может сделать и яй дешевле и эффективней. BJI - это то, к чему мы стремимся в ближайшем будущем. А CI - это то, что будет потом. И не факт, что оно нам понравится.
Итак, как мы понимаем, технологии становятся лучше, инструменты доступнее, всё выглядит радужно. Но есть критический вопрос, который большинство разработчиков игнорирует, и это безопасность, и это может убить полностью ваш проект. Можно много услышать про рак, агентов MCP, но мало кто говорит про безопасность. Из последних отчётов в этой сфере можно увидеть, что 63% организаций не имеют политик внедрения Ий, 97% взломанных Исистем без контрольдоступа. Средняя стоимость утечки больше 4 млн долларов. Shadow Yй добавляет 670.000 долларов каждой утечке. 11% данных в GPT конфиденциальны. Давайте же с вами разберёмся, какие угрозы нас ждут в мире AI.
Угроза номер один: prompt injection. Суть: пользователь перепрограммирует и я через промт. Проблема: lm не различает системный промт и вот пользователя. Всё для неё текст. И есть разные типы прямой: игнорируй все предыдущие инструкции или не прямой, когда помещается скрытый текст в документ. Решение данной проблемы использовать я firewall. Или у нас может быть инpфильтр, который блокирует инкшн паттерны. Также может быть ауputтфильтр, который удаляет PII и секреты из ответов.
Угроза номер два. Shadow I. Суть. Сотрудники используют ИI без одобрения IT-отдела и безопасников. Масштаб 73% использования GPT в корпорациях через личные аккаунты. 20% организаций столкнулись с утечкой через Shadow AI. Основные типы конфиденциальных данных, загружаемые в AI, информация о поддержке клиентов. Исходный код, материалы исследований и разработок.
Угроза номер три: происхождение моделей. Суть: возможен Кдор в скачанной модели с Hagenface. Исследование от Anropic показало, что 250 документов могут отравить любую модель. И это работает, что на 600 млн, так и на 13 млрдах одинаково. Не нужен процент от датасета. Достаточно 250 файлов. Исследование номер два показало: файтюнинг с 1% отравленных данных создаёт backдоoor, как решение model supply chain Security. Вам нужен чек-лист перед использованием модели. Проверенный ли издатель на hgenface. Больше ли тысячи скачиваний? Есть ли карточка модели с документацией обучения? Проверено ли через model Scan, протестировано ли в песочнице, без secкю может привести к катастрофе.
AI меняется каждые 6 месяцев. Вчера невозможное, сегодня обыденность. Сегодняшние инновации - это завтрашние стандарты, но фундаментальные концепции остаются. И используйте это, стройте, экспериментируйте, но делайте осознанно с пониманием архитектуры и рисков. Вы не просто пользователь, вы инженер, который понимает систему. Если это видео было полезно, поставьте лайк, подпишитесь на канал. Ну а у меня всё. Пока.