AI Engineering in 75 Minutes - Foundation Models, Evaluation, RAG, Agents, Finetuning & Inference

Добро пожаловать в AI-инжиниринг и на самый первый урок нашего совместного пути. Прежде чем мы коснёмся хотя бы одной строки кода, давайте зададим странный вопрос. Представьте, что вы можете построить продукт на основе искусственного интеллекта, настолько мощного, что он стоит миллионы долларов и потребляет достаточно электроэнергии, чтобы обеспечить целый город. А теперь представьте, что вы не строили его, не обучали его и могли бы начать использовать его уже сегодня после обеда. Это не научная фантастика. Это тот мир, в котором вы живёте прямо сейчас. И именно поэтому существует весь этот курс. Сегодня мы проследим, как мы сюда попали и почему родился совершенно новый вид инженерии. Итак, как модели стали такими большими? После 2020 года современный ИИ стал определяться одним словом — масштаб. Исследователи обнаружили, что если сделать модель больше, дать ей больше данных и больше вычислительной мощности, она просто становится более способной. Представьте себе график, растущий год за годом, но масштаб — это палка о двух концах. Эти модели выросли настолько огромными, что начали нагружать пределы нашего мира, потребляя серьёзное количество электроэнергии и угрожая исчерпать читаемый текст в интернете. И вот загвоздка, которая меняет всё. Чем больше и способнее они становились, тем больше они стоили, пока лишь горстка организаций на Земле могла позволить себе построить одну из них. Теперь подумайте, что это означает. Если только несколько гигантских организаций могут позволить себе обучать эти модели, но все хотят их использовать, возникает прекрасное несоответствие. Решение было элегантным. Эти несколько организаций поместили свои модели за интерфейс, API, и позволили любому отправить запрос и получить ответ. Внезапно вам не нужны были миллионы долларов или электростанция. Вам нужна была просто хорошая идея. Итак, две стрелы начали двигаться в противоположных направлениях одновременно. Спрос на приложения с ИИ взлетел вверх, в то время как барьер для их создания рухнул. В этом разрыве родилась совершенно новая дисциплина, и мы называем её AI-инжиниринг. Но что на самом деле находится внутри этой модели? Давайте разберём её до бьющегося сердца. В своей основе языковая модель — это своего рода двигатель предсказаний. Она вобрала в себя огромное количество статистической информации о языке, а именно о том, насколько вероятно появление данного слова в данном контексте. Представьте, что я показываю вам предложение: «Мой любимый цвет — ____». Ваш мозг склоняется к синему или зелёному, но не к «машина» или «бутерброд». Это чувство, этот наклон — именно то, что языковая модель улавливает на миллиардах примеров. Она не знает истины. Она знает вероятность. Всё, что делают эти системы, вся магия вырастает из этого одного скромного семени — предсказания того, что вероятно дальше. Теперь модели на самом деле не видят слова так, как мы. Они видят токены. Токен — это базовая единица, с которой работает модель. Это может быть целое слово, отдельный символ или просто часть слова, например, окончание «ти». Посмотрите, что происходит с реальным предложением. Возьмём «I can't wait to build AI applications» («Я не могу дождаться, чтобы создавать AI-приложения»). Модель разбивает его на восемь токенов. И заметьте, что «can't» аккуратно разделяется на «can» и «'t». Полный набор токенов, которые знает модель — это её словарь. Словарь GPT-4 содержит около 100 000 токенов, в то время как у модели вроде Mixrol — 32 000. И в качестве удобного эмпирического правила, 100 токенов примерно равны 75 словам. Здесь есть тонкая развилка. Существует два способа, которыми модель может использовать контекст для предсказания токена. Первый вид читает оба направления сразу. Он видит пробел в середине предложения и использует слова слева и справа, чтобы заполнить его. Мы называем это моделью с маскированным языком, и она блестяще подходит для таких вещей, как тональность и классификация. Второй вид более строгий. Он смотрит только назад, на слова, которые были до, и предсказывает следующее, затем следующее, затем следующее. Это авторегрессионная модель. Это двигатель выбора, когда мы хотим сгенерировать что-то новое. Теперь мы подходим к трюку, который незаметно открывает всё. Чтобы обучать модель старым способом, нужны были люди, размечающие данные. И это чудовищно дорого. Представьте разметку миллиона изображений по 5 центов каждое. Это 50 000 долларов. И это взлетает до 50 миллионов по мере роста категорий. Но языковое моделирование обходит это с помощью приёма, называемого самоконтроль. Текст размечает сам себя. Возьмите одно обычное предложение: «Я люблю уличную еду». И оно становится стопкой обучающих пар. Дано: «Я», предскажи «люблю». Дано: «Я люблю», предскажи «уличную» — и так далее. Внезапно каждое когда-либо написанное предложение становится бесплатными обучающими данными. Вот как языковые модели могли расти и превращаться в большие языковые модели. Итак, масштаб дал нам большие языковые модели, и они росли ошеломляюще быстро. Оригинальный GPT имел 117 миллионов параметров в 2018 году. Всего несколько месяцев спустя GPT-2 взлетел до 1,5 миллиарда. Сегодня около 100 миллиардов — это то, что мы называем большим. Но это ещё не всё. Что, если бы модель могла видеть изображения, слышать аудио, смотреть видео, встроить эти дополнительные чувства — и бац, модель эволюционирует от чистого языка к чему-то более широкому? Фундаментальная модель — универсальный движок, на основе которого можно построить что угодно. Бесчисленные задачи прямо из коробки, революция в старом мире узких моделей. Давайте сделаем это конкретным, потому что это кажется магией, пока вы не увидите трюк. Фундаментальная модель по своей сути — это машина завершения. Вы даёте ей начало чего-то, и бац — она добавляет то, что вероятно будет дальше. Дайте ей «Быть или не быть» — и на выходе «— вот в чём вопрос». Но вот гениальный ход. Вы можете замаскировать почти любую задачу под завершение. Нужен спам-фильтр? Просто напишите «Это письмо — спам?» Вставьте письмо. Затем напишите «Ответ» и позвольте модели завершить. Нужен переводчик? Сформулируйте это как завершение, и та же нетронутая модель переводит. Никакого переобучения, никаких новых данных, просто умная формулировка. Одно предупреждение: это вероятностные предсказания, вероятные ответы, никогда не гарантированно правильные. Итак, если эти модели слишком дороги в создании, как сделать их по-настоящему своими? Вы их адаптируете. Есть три основных метода, и они стоят крошечную долю от обучения с нуля. Инженерия подсказок — тщательное формулирование инструкций. Это имеет огромное значение. Одна модель поднялась с 83,7% до 90% на бенчмарке только за счёт изменения техники работы с подсказками. Затем — поиск (retrieval) — предоставление модели соответствующих документов, чтобы она могла обосновывать свои ответы, и тонкая настройка (fine-tuning) — мягкое подталкивание собственных весов модели вашими примерами. Подумайте о разнице в масштабе. Адаптация может означать 10 примеров и одни выходные, в то время как построение означало миллион примеров за 6 месяцев. Адаптация, попросту говоря, превосходит построение. Это переворачивает всё описание работы. Традиционный машинный инжиниринг тек одним путём: собрать данные, обучить модель, затем выпустить продукт. AI-инжиниринг работает наоборот. Вы начинаете с желаемого продукта, затем тянетесь к существующим моделям и только к тем данным, которые нужны для их адаптации. Поскольку вы опираетесь на чужую модель, работа смещается от обучения к двум новым столпам: адаптация — сделать модель подходящей для вашей задачи, и оценка — строгая проверка того, что она действительно работает. Второй столп сложнее, чем кажется, потому что помните: результаты вероятностны. Вы больше не тот, кто строит двигатель. Вы тот, кто умеет блестяще им управлять. Итак, давайте зафиксируем одну идею, которая пронизывает весь этот курс. Эпоха масштаба сделала фундаментальные модели слишком дорогими для построения, но через API — простыми в использовании. И этот единственный сдвиг создал AI-инжиниринг — ремесло, сосредоточенное не на обучении моделей, а на адаптации и оценке чужой модели. Это ваша новая суперсила. Но быстрая демонстрация — это легко. Настоящий прибыльный продукт — это сложно. Поэтому всегда спрашивайте, зачем вы строите, какую роль на самом деле играет ИИ и как вы пройдете этот сложный последний шаг к чему-то, что люди полюбят. Мы увидели, на что способны эти модели. В нашем следующем уроке, посвященном пониманию фундаментальных моделей, мы пойдем на один уровень глубже и откроем капот, чтобы увидеть, как именно они построены. С возвращением. На первом уроке мы узнали, что фундаментальные модели строятся путем предварительного обучения на океанах данных. Но вот загадка для начала второго урока. Возьмите две модели, обученные примерно на одном и том же интернете: одна пишет красивый код, а другая едва может поддерживать разговор. Почему? Что на самом деле отличает одну фундаментальную модель от другой? Этот вопрос — сердце всей этой главы. Сегодня мы откроем капот. К концу вы поймете тот небольшой набор проектных решений, которые формируют каждую модель, с которой вы когда-либо будете работать, — решений, которые определяют, что знает модель, как она думает и как говорит. Даже когда компания держит обучение в секрете, каждая модель формируется всего тремя большими выборами. Первое: данные, на которых она училась, — чем её кормили. Второе: её архитектура и размер — как она построена и насколько велика. И третье: пост-обучение — как её научили вести себя как полезный помощник, а не просто завершатель текста. Запомните эти три: данные, архитектура и масштаб, и выравнивание. Это три ручки за каждой личностью модели. В оставшейся части этого урока мы будем медленно поворачивать каждую ручку и смотреть, что происходит. Начнем с того, что имеет наибольшее значение и что люди больше всего недооценивают, — с данных. Вот железный закон. Модель может узнать только то, что есть в её данных. Нет вьетнамского текста на входе — нет перевода с английского на вьетнамский на выходе. Это так прямолинейно. И поскольку разработчики берут любые доступные данные, гигантские веб-скрапы вроде Common Crawl, языки мира представлены неравномерно. Посмотрите на это. Английский составляет почти 46%. Следующий язык, русский, — менее 6%. Английский возвышается примерно в восемь раз выше. Итак, модель, обученная на этом, блестяще знает английский и плохо — тысячу других языков. Данные не нейтральны. Они тихо решают, в чем ваша модель будет хороша, ещё до начала обучения. Этот дисбаланс имеет скрытую практическую цену. Модели не читают буквы. Они читают токены, маленькие фрагменты текста. И одно и то же предложение разбивается на совершенно разное количество токенов в зависимости от языка. Смотрите. Предложение из семи токенов на английском может раздуться до 72 токенов на бирманском. Тот же смысл, в 10 раз больше токенов. Поскольку вы платите за токен, а модель обрабатывает их один за другим, этот низкоресурсный язык внезапно становится медленнее и дороже. И модель понимает его хуже. Так что «модель настолько хороша, насколько хороши её данные» — это не просто лозунг. Это проявляется в вашей задержке, вашем счете и вашем качестве. Теперь, как построена эта штука? Теперь архитектура. Почти все современные модели используют одну конструкцию — трансформер. И он победил благодаря одной идее — вниманию. Чтобы почувствовать, почему это важно, представьте старый подход. Более старая модель перевода читала целое предложение и сжимала его в одно итоговое резюме. Затем пыталась сгенерировать перевод только на основе этого резюме. Представьте, что вы читаете целую книгу, а затем пишете отчет, имея право смотреть только на однострочное резюме. Детали утекают. Внимание исправляет это. При генерации каждого нового слова модель может вернуться к любому более раннему слову, какому захочет. Каждая страница всё ещё открыта перед ней. Ничто не пропускается через единое узкое место. Эта свобода — причина, по которой трансформеры захватили лидерство. Давайте замедлимся и на самом деле откроем внимание, потому что это двигатель всей области. Представьте исследователя за столом, которому нужен следующий факт. То, что он ищет прямо сейчас, — это запрос. Каждое предыдущее слово предлагает две вещи: ключ — как помеченный номер страницы, который говорит, о чём оно, и значение — фактическое содержание на этой странице. Модель сравнивает запрос с каждым ключом. Сильное совпадение означает, что эта страница релевантна. Втяни больше её значения. Эта оценка совпадения — просто скалярное произведение. Итак, внимание — это структурированное взвешенное чтение. Для каждого нового слова решить, какие предыдущие слова важны, и примешать именно их. Этот единственный механизм заставляет эти модели казаться понимающими. Итак, у нас есть данные и конструкция. Следующая ручка — размер. И масштаб модели сводится к трем числам: параметры — сколько ручек она может настраивать; обучающие токены — сколько она на самом деле прочитала; и flops — сырые вычисления, которые она стоила. Для справки, GPT-3 имел 175 миллиардов параметров и потребовал около 3 × 10^23 операций с плавающей запятой, примерно 4 миллиона долларов вычислительных ресурсов. Больше обычно помогает, но только при достаточном количестве хороших данных. Закон масштабирования Chinchilla дает эмпирическое правило: обучайте примерно на 20 токенов на каждый параметр. Модель с тремя миллиардами параметров хочет около 60 миллиардов токенов. Масштаб — это не просто «будь больше». Это баланс. Но вот кое-что удивительное. Свежепредобученная модель — это не помощник. Это блестящий дикий завершиатель текста. Она прочитала интернет. Но спросите её о чём-то, и она может просто продолжить задавать вопросы, потому что всё, что она выучила, — это предсказывать следующий токен. Превращение этой сырой силы в нечто полезное — это пост-обучение, наша третья ручка. Сначала контролируемая тонкая настройка показывает ей тысячи реальных разговоров, обучая её отвечать, а не болтать. Затем обучение предпочтениям, такое как RLHF, подталкивает её к ответам, которые люди на самом деле предпочитают: полезным, честным, безвредным. Люди представляют это как дикого многоголового монстра, которого контролируемая тонкая настройка делает презентабельным, а обучение предпочтениям рисует дружелюбную улыбку. То же самое существо внизу, теперь выровненное для работы с нами. Ещё одна глубокая идея, и она объясняет много странного поведения. На каждом шаге модель на самом деле не знает следующее слово. Она выдает вероятность для каждого слова в своем словаре. Легкий ход — жадная выборка — всегда хватать единственное наиболее вероятное. Но нет, модели вместо этого бросают взвешенные игральные кости по этим вероятностям. Эта случайность — источник творчества, а также непоследовательности и галлюцинаций, когда модель утверждает что-то, не основанное на фактах. И мы можем настроить кости. Температура — ключевая ручка. Представьте это. Два слова-кандидата: одно набирает 1 балл, другое — 2 балла. При нормальной температуре их вероятности составляют около 27% и 73%. Понизьте температуру — разрыв увеличивается до 12% и 88%. Резче, безопаснее, предсказуемее. А как только результаты становятся вероятностными, вы можете этим воспользоваться. Вместо того чтобы доверять одному броску костей, нет — сгенерируйте несколько ответов. Оставьте лучший. Выберите наивысшую среднюю уверенность или возьмите голосование большинства. Это вычисления во время тестирования. Потратьте немного больше на размышления в момент ответа. Выигрыш поразителен. В одном исследовании добавление верификатора дало такой же прирост, как увеличение модели в 30 раз. В 30 раз. Итак, вы можете купить качество дешевле с помощью умной выборки, чем с помощью гигантской новой модели. Кости — это не просто причуда, это рычаг, который вы можете потянуть. Итак, отступите назад и увидьте всю машину. Фундаментальная модель формируется тремя выборами: данные, которые решают, что она вообще может знать; архитектура и масштаб — внимание и эти три числа, которые решают, как она думает; и пост-обучение, которое решает, как она себя ведет. И каждый её ответ — это выборочный бросок костей, которые вы можете настроить и использовать. Если вы запомните одну вещь, запомните эту: модель — это не фиксированный оракул. Это продукт выборов и вероятностей, что означает, что её можно понять, предсказать и формировать. Но это поднимает очевидный следующий вопрос: как мы на самом деле узнаем, хороша модель или нет? Именно туда мы и направляемся дальше. Методология оценки. Добро пожаловать на третий урок AI-инжиниринга. На прошлом уроке вы узнали, как строятся фундаментальные модели. Теперь мы задаем вопрос, который решает, сможете ли вы когда-нибудь выпустить одну из них. Как вы узнаете, что она на самом деле хороша? Это не академический вопрос. Чат-бот однажды подтолкнул человека к самоубийству. Юристы представили судебные дела, придуманные ИИ, как настоящие доказательства. Air Canada была вынуждена выплатить компенсацию клиенту, потому что её чат-бот просто всё выдумывал. По мере того как эти модели становятся всё способнее, цена их неудач растёт вместе с ними. Оценка часто является самым большим препятствием для выпуска ИИ-приложения. Итак, давайте научимся измерять доверие. Но вот загвоздка. Фундаментальные модели уникально трудны для оценки. Подумайте о проверке эссе против проверки математического теста. У теста один правильный ответ. У эссе — много. Эти модели живут в мире эссе. Задачи с открытым концом, бесчисленные правильные результаты, нет чистого ключа ответов. Они становятся настолько способными, что мы, люди, с трудом проверяем их работу. Мы относимся к ним как к черным ящикам, не в силах заглянуть внутрь. И хуже всего то, что, как только мы создаем хороший тест, они сдают его на отлично, и он становится бесполезным. Мы называем это насыщением. Итак, прежде чем что-то измерять, мы должны уважать, насколько скользкой на самом деле является цель. Итак, с чего нам вообще начать? Вот красивый короткий путь. Почти каждая фундаментальная модель имеет внутри языковую модель. А языковая модель делает ровно одну вещь: предсказывает следующий токен, что даёт нам бесплатный встроенный сигнал качества. Если модель действительно хороша в угадывании того, что будет дальше, она усвоила реальную структуру языка в мире. Итак, самое первое семейство метрик оценивает это предсказание. Ключевое слово — удивление. Хорошая модель редко удивляется случайному тексту. Неуклюжая модель постоянно застигается врасплох. Давайте превратим это чувство удивления в число. Начиная с самой фундаментальной идеи из всех — энтропии. Представьте крошечный язык, где каждое сообщение — это просто позиция в квадрате. Если выбор — только верх или низ, то бац, один ответ «да» или «нет» фиксирует её. Один бит информации. Теперь допустим все четыре угла. Внезапно вам нужно два ответа «да» или «нет», чтобы найти её. Два бита. Заметили, что произошло? Больше возможных токенов означает, что каждый несет больше информации. И это стоит больше битов. Это энтропия. Среднее количество информации на токен. Мера того, насколько непредсказуемы ваши данные. Два варианта — низкая энтропия. 100 000 вариантов — высокая энтропия. Энтропия описывает сам язык до того, как появится какая-либо модель. Это гора, которую каждой модели предстоит преодолеть. Энтропия — это встроенная сложность языка. Но насколько трудно конкретной обученной модели предсказать эти данные? Это перекрестная энтропия. Вот элегантная часть. Перекрестная энтропия аккуратно делится на две части. Первая — это энтропия, неизбежная сложность, встроенная в язык. Вторая — это разрыв. Расстояние между тем, как на самом деле устроен мир, и тем, что выучила модель. По мере обучения модели и совершенствования её картины мира этот разрыв сокращается. В совершенном, невозможном мире разрыв достигает нуля. И перекрестная энтропия падает прямо до чистой энтропии. Итак, перекрестная энтропия — это энтропия плюс оставшееся невежество модели. Наблюдайте, как закрывается этот разрыв. Перекрестная энтропия честна, но она измеряется в битах, что не ощущается как что-то. Итак, мы возводим её в степень и получаем перплексию — число, которое вы можете на самом деле представить. Перплексия отвечает на чудесно конкретный вопрос. На каждом шаге между сколькими равновероятными вариантами модель эффективно выбирает? Перплексия, равная четырём, означает, что она стоит на развилке с четырьмя одинаково заманчивыми дорогами. Меньше — лучше. Меньше дорог означает больше уверенности. И вот что должно вас поразить: сильные модели достигают перплексии около трёх. Несмотря на то что их словарь содержит десятки или сотни тысяч токенов, из 100 000 возможных слов они сузили реальную неопределённость до примерно одной догадки из трёх. Это уверенность модели, ставшая видимой. Теперь мы покидаем внутренности модели и спрашиваем о её фактических выходах. Всё, что дальше, разделяется по одной линии разлома, так что запомните её. Некоторые оценки точны. Есть однозначное правильное и неправильное. Никаких споров. Прошёл ли код тест? Да или нет. Другие оценки субъективны. Вердикт полностью зависит от того, кто или что судит. Хороша ли эта шутка? Ну, зависит от того, кого спросить. Ни одна сторона не лучше. Они отвечают на разные вопросы. Точные методы дают вам определённость, но работают только тогда, когда задача имеет чёткую цель. Субъективные методы распространяются на работу с открытым концом, но стоят вам этой определённости. Остальная часть этого урока живёт на этих двух берегах. На точном берегу живёт самая удовлетворительная мера из всех — функциональная корректность. Забудьте про стиль, забудьте про беглость. Сделал ли выход свою работу? Если вы попросили код, находящий наибольший общий делитель, вы не восхищаетесь тем, как он читается. Вы запускаете его на тестовых примерах и смотрите, проходят они или нет. Если вы попросили агента выиграть игру, вы проверяете счёт. Это автоматизируемо. Всякий раз, когда есть измеримая цель, знаменитая версия — pass@k. Дайте модели k попыток на задачу и измерьте долю решённых. 10 задач, по три попытки каждая, пять решено. Это pass@3 в 50%. И естественно, больше попыток может только помочь. Так что pass@1 никогда не бьёт pass@10. Но большинство выходов не запускаемы. Вы не можете выполнить перевод или резюме. Поэтому вместо этого мы сравниваем выход с известным хорошим эталонным ответом. Самый грубый способ — точное совпадение, но это хрупко. Существует дюжина допустимых переводов. Неряшливая проверка «содержит ответ» может радостно принять «12 сентября 1929 года», когда вы хотели только год. Итак, мы смягчаем. Лексическое сходство подсчитывает совпадающие слова. По сравнению с эталоном «Мои кошки пугают мышей» предложение «Мои кошки едят мышей» получает 80%, в то время как неудачный пересказ — 60%. Но совпадение слов поверхностно. Оно не может сказать, что «фильм» и «кино» означают одно и то же. Для этого нам нужен сам смысл. Вот одна из самых мощных идей во всём ИИ, и она повторяется повсюду, куда бы вы ни пошли отсюда. Что, если бы мы могли превратить фрагмент текста в точку в пространстве, расположенную так, чтобы вещи со схожими значениями находились рядом? Эта точка называется эмбеддингом — вектором, который захватывает значение. «Кошка на коврике» оказывается рядом с «собакой на траве», потому что это похожие сцены. В то время как «AI-исследования — это весело» находится далеко. И для измерения близости мы смотрим на угол между двумя векторами. Это косинусное сходство. И этот трюк не только для текстовых моделей: такие модели, как CLIP, помещают картинку и её подпись в одно и то же общее пространство. Смысл становится геометрией. Но сопоставление по смыслу всё ещё требует эталонного ответа, и часто его нет. Поэтому мы обращаемся к более смелому решению: попросить другой ИИ быть судьёй. Дайте модели выходные данные плюс подсказку с задачей, критериями и схемой оценки, и пусть она оценивает. Это быстро, гибко и не требует эталона. И, что удивительно, это работает. GPT-4 соглашался с человеческими оценщиками примерно в 85% случаев на одном бенчмарке, что немного выше, чем согласие людей друг с другом. Но будьте осторожны: судьи субъективны и непоследовательны. Они дрейфуют со временем. Они расходятся в том, что означают такие слова, как «верность». И они предвзяты. Модель может отдавать предпочтение собственным ответам, иногда до 25%. Никогда не доверяйте судье, чей промпт модели вы не видите. Есть ещё одна идея, заимствованная прямо из шахмат и спорта. Вместо того чтобы спрашивать, насколько хороша эта модель в абсолютном выражении, просто спросите, какой из двух ответов лучше. Соберите тысячи таких матчей один на один. Подсчитайте процент побед, и вырисовывается рейтинг, точно как рейтинг Эло. Арена LMSYS сделала это в огромном масштабе: 57 моделей, 244 000 сравнений. Это мощно, потому что выбрать победителя часто проще, чем оценивать в вакууме. Но помните её предел. Она даёт относительное качество, а не абсолютное. Лидерборд не может сказать вам, достаточно ли хороша лучшая модель для вашей задачи. А некоторые вопросы, такие как сырая корректность, вообще не должны решаться голосованием по популярности. Добро пожаловать на четвёртый урок AI-инжиниринга: оценка ИИ-систем. На прошлом уроке вы узнали методы, которые судят выход модели. Теперь мы меняем угол зрения. Вот мысль, которая должна не давать вам спать по ночам. ИИ-приложение, которое развернуто, но не может быть оценено, на самом деле хуже, чем то, которое вы никогда не выпускали. Почему? Потому что оно тихо сжигает деньги, обслуживая пользователей, без каких-либо доказательств, что оно кому-то помогает. Поэтому, прежде чем написать хотя бы один промпт, задайте вопрос, который великие инженеры позаимствовали из разработки через тестирование: «Как я узнаю, что это работает?» Сначала определите критерии оценки. Это вся игра, которой учит эта глава. Но оценивать для чего именно? Оказывается, потребности каждого приложения укладываются всего в четыре категории. Первая: предметно-специфическая способность. Действительно ли модель знает вашу область? Вторая: способность к генерации. Хорош ли результат с открытым концом? Третья: следование инструкциям. Соблюдает ли она установленные вами правила? И четвёртая: стоимость и задержка. Можете ли вы позволить себе её запускать? Достаточно ли она быстра? Представьте резюмирование юридического контракта. Вам нужны реальные юридические знания, беглое и верное резюме, соблюдение ваших требований по длине и формату, а также цена, которая не провалит проект. Эта одна задача затрагивает все четыре категории. Освойте эти четыре, и вы сможете описать, что значит «хорошо» почти для чего угодно. Давайте медленно откроем первую категорию, потому что она основополагающая. Предметно-специфическая способность задаёт простой вопрос: обладает ли эта модель знаниями или навыками, необходимыми вашему приложению? Кодирование, латынь, высшая математика. И вот жёсткое ограничение, которое подводит людей. Способность ограничена данными обучения. Модель, которая ни разу не видела латыни, просто не может понять латынь. Нет промпта, достаточно умного, чтобы вызвать знание, которого никогда не было. Итак, как мы измеряем это дёшево? Обычно с помощью закрытых бенчмарков — вопросов с множественным выбором, потому что одна буква тривиально проверяется. Правильно или неправильно, без споров. Эта простота — именно то, почему они повсюду. Но простота проверки скрывает ловушку. Возьмите реальный вопрос MMLU. Правильный ответ — D. Если модель уверенно выбирает A, она просто не права. Оценка однозначна. Однако помните: четыре варианта означают, что чистое угадывание — 25%. Таким образом, число около 25 означает, что модель почти ничего не знает. Хуже того, эти оценки хрупки. Лишний пробел или добавление слова «варианты» могут перевернуть ответ. И вот глубинный изъян. Множественный выбор проверяет, может ли модель отличить хорошее от плохого. Он никогда не проверяет, может ли она сгенерировать что-то хорошее. Это делает его плохим прокси для реальной работы, такой как суммаризация или перевод. Итак, откройте вторую категорию: способность к генерации — качество результата с открытым концом. Годы назад, когда машинный текст звучал роботизированно, мы были одержимы беглостью, связностью, релевантностью. Машины выиграли эти битвы. Сегодняшняя актуальная проблема другая и более страшная: фактическая согласованность. Мы называем выдуманное содержание галлюцинацией. И ключевое понимание — два вида фактов. Локальная фактическая согласованность: согласуется ли выход с конкретным контекстом, который вы предоставили (этот контракт, этот документ)? Глобальная фактическая согласованность: более сложный вопрос. Согласуется ли он с общеизвестными знаниями? Галлюцинация не всегда плоха. Для фэнтезийной истории вам нужно изобретение. Но для юридического резюме выдуманное положение — катастрофа. Но как поймать галлюцинацию в масштабе? Вы не можете читать каждый выход сами. Один элегантный инструмент приходит из лингвистики: текстовое следование. Дана предпосылка, вы классифицируете утверждение как следование, противоречие или нейтральное. Предпосылка: «Мэри любит все фрукты». «Мэри любит яблоки» — это следует (следование). «Мэри ненавидит апельсины» — это сталкивается (противоречие). «Мэри любит кур» — не связано (нейтрально). Специализированный оценщик DeBERTa V3 со 184 миллионами параметров, обученный на 764 000 пар, учится делать именно такое суждение. А чтобы проверить длинный ответ, безопасный конвейер разбивает его на отдельные факты, делает каждый самодостаточным, превращает каждый в поисковый запрос и проверяет их по одному. Теперь третья категория, и она хитрее, чем кажется: следование инструкциям. Это полностью отдельно от того, знает ли модель вашу область. Вы можете попросить хайку, ровно 17 слогов, заканчивающееся вопросом. И блестящая модель, которая игнорирует эти правила, бесполезна для вас. Хорошая инструкция с непослушной моделью не даёт ничего. И смотрите на эту путаницу: если модель не смогла написать стихотворение на вьетнамском, это незнание вьетнамского или она неправильно поняла запрос? Два совершенно разных сбоя. Инструменты вроде IFEval проверяют механически: содержит ли текст слово «эфемерный», правильное количество пунктов в списке, валидный JSON. А InfoBench превращает каждую инструкцию в вопросы «да/нет», оценивая долю тех, которые вы на самом деле имели в виду. Теперь вы знаете, что значит «хорошо». Далее, откуда берётся модель? Постройте сами, разместив открытые веса, или купите доступ через модельный API. Этот выбор взвешивается по семи осям и резко сужает ваших кандидатов. Хитрость в том, чтобы отделить жёсткие атрибуты от мягких. Жёсткие атрибуты — это запертые ящики, которые вы не можете изменить: лицензия, размер модели. Мягкие атрибуты — это ручки, которые вы можете крутить: точность, а если вы хостите сами, даже задержка. Фильтруйте сначала по запертым ящикам, потому что никакие усилия их не сдвинут. Одна тихая реальность хостинга: GPU поставляются в объёмах 16, 24, 48 и 80 ГБ, что как раз объясняет, почему так много моделей имеют размер 7 миллиардов или 65 миллиардов параметров — чтобы максимально использовать эту память. Итак, вы обращаетесь к публичному лидерборду бенчмарков. Полезно, но никогда не доверяйте ему одному. Публичные бенчмарки хороши для отсеивания явно плохих моделей, но не найдут лучшую модель для вас. Почему? Потому что они, вероятно, загрязнены. Загрязнение данных — это когда модель обучалась на тех самых вопросах, на которых её тестируют, что завышает её оценку, как студент, который заранее увидел экзамен. Вот почему реальный выбор модели означает построение собственного частного лидерборда на ваших данных для вашей задачи. Это недёшево. Стэнфорд потратил примерно 80–100 тысяч долларов на оценку 30 моделей в Helm. Публичные оценки дают вам короткий список. Ваш собственный конвейер коронует победителя. Вот ошибка, которая губит реальные системы: оценка только конечного выхода. Представьте систему отбора резюме, состоящую из двух компонентов. Первый — блок, который превращает PDF в текст. Затем второй блок, который превращает этот текст в решение о найме. Если конечный ответ неверен, какой блок отказал? Вы действительно не можете сказать по одному концу. Поэтому оценивайте каждый компонент независимо. И не путайте «правильно» с «хорошо». Модель LinkedIn сказала: «Вы ужасно подходите для этой работы». Абсолютно правильно, возможно, совершенно бесполезно. Ваша работа — оценивать каждый компонент по четким рекомендациям и рубрике, привязанной к реальному бизнес-результату, который вам важен. Ещё одна частичка суровой мудрости, потому что числа могут обманывать. Сколько тестовых примеров вам на самом деле нужно, чтобы доверять результату? Эмпирическое правило OpenAI отрезвляет. Чтобы надёжно обнаружить разницу в 30% между моделями, достаточно около 10 образцов. Для 10% нужно 100. Для 3% — тысяча. А чтобы поймать разницу в 1% — 10 000 образцов. Обратите внимание на жестокую закономерность: каждый раз, когда вы хотите обнаружить разницу в три раза меньшую, вам нужно в 10 раз больше данных. И остерегайтесь парадокса Симпсона, когда модель выигрывает в каждой подгруппе, но проигрывает в целом. Разрезайте свою оценку по подгруппам, чтобы скрытый переворот не застал вас врасплох. Давайте зафиксируем одну идею, которая важнее всего. Оценка — это не финальный экзамен, к которому вы готовитесь после сборки. Нет, это чертёж, который вы рисуете до того, как начать. Сначала определите критерии по четырём категориям. Оценивайте каждый компонент честно и стройте свой собственный частный лидерборд на данных, похожих на ваш реальный мир. Сделайте это, и вы перестанете надеяться, что ваше приложение работает, и начнёте знать, что оно работает. На следующем уроке мы перейдём от оценки моделей к управлению ими. Инженерия промптов — искусство заставить фундаментальную модель делать именно то, что вы хотите, и делать это ответственно. Вы научились измерять. Теперь давайте научимся формировать. Добро пожаловать на пятый урок AI-инжиниринга. В прошлый раз мы узнали, как оценивать ИИ-систему. Теперь мы действительно научимся управлять одной. Вот кое-что, что должно вас удивить. Прежде чем вы настроите модель за миллион долларов. Прежде чем вы коснётесь хотя бы одного веса, существует метод настолько простой, что его может сделать кто угодно. И в то же время настолько мощный, что это самый распространённый способ адаптации этих моделей вообще. Вы просто разговариваете с ней. Вы пишете инструкцию, и модель изгибается в сторону того, что вы хотите. Это инженерия промптов. И правило этого урока просто: сначала исчерпайте это, потому что это самый лёгкий инструмент, который у вас есть. Но не путайте лёгкость начала с лёгкостью овладения. Любой может нацарапать промпт, так же как любой может напеть мелодию. Но написать эффективный промпт, который надёжно работает в продакшне, — это другой вид спорта. Он требует той же дисциплины, которую вы придаёте любому эксперименту по машинному обучению: систематические пробы, тщательная оценка, отслеживание того, что изменилось и почему. Один умный промпт сам по себе не вытянет реальное приложение. Вы всё ещё опираетесь на всё из прошлого урока: оценку, отслеживание экспериментов, хорошие наборы данных. Думайте о промпте не как о магическом заклинании, а как о гипотезе, которую вы тестируете, уточняете и измеряете снова и снова. Итак, что на самом деле внутри промпта? Представьте его как три сложенных слоя. Верхний слой — описание задачи: что вы хотите сделать, какую роль должна играть модель, какую форму должен принять результат. Средний слой — примеры: образцы входных данных в паре с ответами, которые вы примете. И нижний слой — сама задача: то, что нужно обработать прямо сейчас. Не каждый промпт использует все три, но самые сильные часто используют все. Описание задаёт правила игры. Примеры показывают игру в действии, а задача — это ход, который вы просите модель сделать. Теперь часть, которая действительно ощущается как магия. Покажите модели несколько примеров прямо в промпте, и она схватит шаблон на месте, без обучения, без каких-либо обновлений весов. Это называется обучение в контексте, и оно поразило людей, когда статья GPT-3 представила его. Каждый пример, который вы даёте, — это «выстрел». Пять примеров — five-shot. Ни одного, только инструкция — zero-shot. И поскольку обучение происходит в промпте, вы можете вводить свежую информацию, то, чего модель никогда не видела во время обучения: новости, срезанные в данный момент. Но примеры — это не бесплатный обед, который вы всегда берёте. На GPT-3 добавление нескольких примеров давало огромный прирост по сравнению с простой инструкцией. На GPT-4 анализ Microsoft в 2023 году показал, что те же примеры дали лишь ограниченное улучшение по сравнению с zero-shot. Почему? Более новые модели просто лучше следуют простым инструкциям. Таким образом, примеры стоят вам токенов, а токены стоят денег и контекстного пространства. Урок здесь — урок всей главы: не предполагайте, измеряйте. Будет ли помогать few-shot, зависит от вашей модели и вашей задачи. И единственный способ узнать — протестировать оба варианта и посмотреть на цифры. Когда вы используете чат API, ваш промпт обычно приходит в двух частях. Есть системный промпт — да, это инструкции разработчика, которые всегда работают: правила, роль, личность. И есть пользовательский промпт — фактическое сообщение, введенное пользователем. Они ощущаются как отдельные каналы. Но угадайте что? Модель склеивает их вместе. Бац — в одну длинную строку, используя скрытый формат, шаблон чата со специальными токенами, обозначающими, где начинается каждая часть. Системный промпт — это не магия. Это просто соединённый текст. Любая дополнительная сила, которую он имеет, исходит от его позиции или от обучения, которое научило модель доверять ему больше. Вот как это работает. Теперь, сколько можно запихнуть в промпт? Удивительно, но контекстные окна выросли примерно в 2000 раз за 5 лет. Первые три GPT имели 1, 2, затем 4000 токенов. Сегодня Gemini 1.5 Pro имеет 2 миллиона. Чтобы это прочувствовать: 100 000 токенов — это приличная книга. 2 миллиона — около 2000 страниц Википедии. Но больше — не обязательно лучше, потому что модели читают неравномерно. Они понимают инструкции, помещённые в самое начало и в самый конец, гораздо лучше, чем вещи, погребённые в середине. Исследователи называют это «потеря в середине». Поэтому помещайте свои самые важные инструкции туда, куда модель на самом деле смотрит. Модели меняются каждые несколько месяцев. Какие привычки промптинга переживают обновления? Четыре из них. Первое: пишите чёткие, конкретные инструкции. Двусмысленность — это то, где модели отклоняются. Второе: давайте достаточный контекст. Предоставляйте факты, которые нужны модели. Третье: декомпозиция. Разбивайте на более мелкие шаги. И четвёртое: дайте модели время подумать. Позвольте ей рассуждать шаг за шагом — цепочка мыслей. Именно это делает её такой эффективной. И вот так: скорость, ясность, точность. Давайте посмотрим на это на примере. Представьте, что вы просите модель оценить эссе «с холодной головой», и она ставит ему два из пяти. Теперь добавьте одну строку: «Вы учитель первого класса». И бац, то же самое эссе получает четыре из пяти. Те же слова, другая линза. Декомпозиция столь же конкретна. Промпт поддержки GoDaddy разросся до более чем 1500 токенов, пытаясь сделать всё сразу. Разделив его — сначала маленький промпт для классификации намерения пользователя, затем фокусный промпт для обработки конкретной проблемы — они получили лучшую производительность и меньшую стоимость. Маленькие, более острые промпты в цепочке бьют один гигантский промпт, который изо всех сил пытается охватить всё. Вот неприятная оборотная сторона. Как только ваше приложение запущено, люди попытаются исказить ваши промпты. Они взламывают (jailbreak), уговаривая модель обойти её правила безопасности. Они инжектят, вставляя вредоносные инструкции. Исследователи однажды попросили ChatGPT повторять слово «стихотворение» вечно, и в итоге он выболтал запомненные обучающие данные. Модели могут запоминать примерно 1% своих данных. Некоторые автоматические атаки взламывают модель менее чем за 20 запросов. Одна сильная защита — иерархия инструкций. Модель доверяет системному промпту выше пользовательского, пользовательскому — выше вывода модели, а тому — выше любого вывода инструмента, что в тестах повысило устойчивость до 63%. Но знайте: никакая защита не является абсолютно надёжной. Одна тихая привычка отличает любительские промпты от продакшен-промптов. Относитесь к своим промптам как к настоящему коду. Не закапывайте их в строке, разбросанные и забытые. Вынесите их в отдельный файл. Дайте каждому чёткое имя. Версионируйте их, тестируйте и всегда, всегда печатайте финальный промпт перед отправкой, потому что шаблон чата, который оборачивает ваш текст, может различаться между моделями. Llama 2 против Llama 3 — и несоответствие молчаливо терпит неудачу. Без ошибки, просто тихо ухудшая ответы. Ещё одно честное замечание: те слитые системные промпты, которые вы видите в интернете, обычно галлюцинированы. Ваш собственный системный промпт — это скорее ответственность, чем секретное оружие. Итак, вот одна вещь, которую нужно вынести. Инженерия промптов — это то, как вы общаетесь с моделью. Самый лёгкий, самый дешёвый способ формировать её поведение. Просто начать и по-настоящему глубоко освоить. Анатомия, примеры, системные и пользовательские промпты, позиционирование, четыре устойчивых привычки и защиты. Каждая часть на самом деле о том, чтобы чётко сказать, чего вы хотите, и проверить, сработало ли это. Но заметьте разрыв. Отличный промпт говорит модели, что делать. Он не предоставляет ей факты, которых у неё нет. Именно туда мы и направляемся дальше. Урок шестой: RAG и агенты. Предоставление модели правильного контекста и инструментов для действий на его основе. Добро пожаловать на шестой урок нашего курса AI-инжиниринга. В прошлый раз мы научились формировать поведение модели с помощью хороших промптов. Но вот отрезвляющий факт. Даже блестящая модель терпит неудачу, когда у неё просто нет правильной информации перед глазами. Спросите её о продажах вашей компании в прошлый вторник, и она уверенно что-то выдумает. Это не глупость. Это отсутствие контекста. Как и человек, модель галлюцинирует, когда её просят ответить на то, о чём ей никогда не говорили. Итак, этот урок посвящён одной мощной идее: как передать модели именно ту информацию, которая нужна для именно этого вопроса в именно этот момент? Подумайте о найме нового помощника. Вы даёте им два вида инструкций. Первое: постоянные инструкции: как писать письма, как быть вежливым, правила, которые остаются неизменными для каждой задачи. Второе: специфика работы: клиент, срок, документ. Модель та же. Инструкции общие для каждого запроса. Контекст создается свежим для каждого. И самый чистый способ сделать это имеет название. Мы заслужим его через мгновение. Представьте экзамен с открытой книгой. Вам не нужно запоминать весь учебник. Вы просто листаете на нужную страницу в тот момент, когда появляется вопрос. Это вся идея, стоящая за генерацией с дополнением через поиск (RAG). Вместо того чтобы втискивать всё в модель, мы храним внешнюю память — базу данных, прошлые чаты, даже интернет. И в момент вопроса извлекаем наиболее релевантные фрагменты и подаём их. Затем модель генерирует свой ответ, используя этот извлечённый материал. Извлеки, затем сгенерируй. Заметьте элегантность. Модель остаётся того же размера, но её эффективные знания становятся такими же большими, как библиотека, на которую вы указали. Давайте откроем эту машину. Система RAG состоит всего из двух частей. Генератор — это модель, пишущая ответ. Это мы уже знаем. Но вот новая часть — ретривер. Он выполняет две задачи. Во-первых, он индексирует ваши данные заранее, организуя их для молниеносного поиска. Затем, в момент запроса, он ищет в этом индексе наилучшие совпадения. Одна загвоздка: документы могут быть огромными, поэтому мы нарезаем их на чанки. Вот главный урок: вся система держится или падает на ретривере. Скормите генератору мусор — и даже гениальная модель напишет мусорные ответы. Итак, как ретривер решает, что релевантно? Самый старый, самый интуитивный способ — сопоставление слов. Если вы ищете слово «трансформер», извлеките чанки, которые буквально содержат «трансформер». Но не все слова заслуживают одинакового веса. Слово «the» встречается повсюду, поэтому оно говорит нам почти ни о чём. Редкое слово гораздо более показательно. Это сердце TF-IDF. Частота термина (TF) подсчитывает, как часто слово появляется в документе. Обратная частота документа (IDF) вознаграждает редкость. Если существует 10 документов и только пять содержат ваш термин, его оценка равна 10/5 = 2. BM25 уточняет это дальше, корректируя длину документа. Просто, быстро и удивительно сильно. Но у сопоставления слов есть слепое пятно. Поищите «машина» (car) — и вы пропустите идеальный чанк, в котором только «автомобиль» (automobile). Разные слова, один и тот же смысл. Чтобы это исправить, нам нужно улавливать сам смысл. И здесь возвращаются эмбеддинги из наших предыдущих уроков. Эмбеддинг — это вектор, список чисел, который кодирует, что означает фрагмент текста, так что похожие значения оказываются рядом в пространстве. Одна и та же модель эмбеддингов кодирует каждый сохранённый чанк и ваш запрос. Теперь поиск становится геометрией. Найдите векторы, ближайшие к вашему запросу. Точный поиск по всем — это k ближайших соседей. В продакшне мы используем более быструю приближённую версию ANN, чтобы оставаться быстрыми при огромном масштабе. Итак, теперь у нас есть два ретривера с противоположными сильными сторонами. Поиск по ключевым словам хорошо справляется с точными терминами — коды ошибок, названия продуктов — но пропускает синонимы. Эмбеддинговый поиск улавливает смысл, но размывает эти точные ключевые слова. Очевидный ход: запустить оба и объединить. Это гибридный поиск, но каждый ретривер возвращает свой собственный ранжированный список. Поэтому нам нужно их слить. Одна метрика — взвешенное ранговое слияние (RRF). Документ, занявший первое место, получает 1 балл. Второе место — 1/2. Таким образом, чанк, занявший первое место в одном и второе в другом, суммируется до 1,5. Сложите баллы. Пересортируйте, и элементы, понравившиеся обоим ретриверам, поднимутся наверх. Затем финальный переранжировщик может сделать точный проход. Закиньте широкую сеть дешёво. Затем сузьте. Вот тонкость, которая подводит реальные системы: как вы нарезаете документы, имеет огромное значение. Представьте это. Предложение: «Я оставил своей жене записку». Разделите его в неправильном месте, и вы получите «Я оставил свою жену». Совершенно другое значение, и это разрушает поиск. Поэтому мы часто делаем чанки слегка перекрывающимися, например, чанки по 2000 символов с перекрытием в 20 символов на стыках, чтобы смысл не разрезался. Ещё лучше — контекстуальный поиск. Перед индексацией чанка модель пишет краткое описание на 50–100 токенов, объясняющее, откуда этот чанк, и пропендит его. Не существует универсального лучшего размера чанка. Меньший размер помещает больше разнообразия, но теряет контекст. Так что честный ответ — экспериментировать. Справедливый вызов: модели теперь читают огромные контексты. Так почему бы просто не вставить всё? Иногда стоит. Сама рекомендация Anthropic гласит: если вся ваша база знаний умещается примерно в 200 000 токенов (около 500 страниц), вы можете пропустить RAG и закинуть всё в промпт. Но RAG не умирает здесь по двум причинам. Во-первых, реальные данные перерастают любой лимит. Документы вашей компании никогда не перестанут множиться. Во-вторых, модели плохо используют длинный контекст. Набейте окно полностью — и ответы становятся медленнее, дороже и, как ни странно, более отвлекаемыми. Ключевой факт тонет в шуме. Таким образом, RAG — это не костыль для маленьких моделей. Это способ оставаться точным и доступным в масштабе. Теперь отступим. Мы только что построили нечто, что воспринимает вопрос и действует, чтобы получить информацию. Тихо мы описали агента. Агент — это всё, что воспринимает среду и действует в ней. И его реальная сила исходит из инструментов. RAG, оказывается, — это самый простой агент из существующих. Модель, чей единственный инструмент — ретривер. Но инструменты могут делать гораздо больше, чем просто искать. Они расширяют возможности, такие как выполнение кода или математики. И они могут предпринимать реальные действия, такие как отправка электронной почты или обновление базы данных. Механизм: вызов функций. Модель объявляет, что хочет инструмент, выдаёт вызов, скажем «конвертировать 40 фунтов в килограммы». Мы запускаем его и возвращаем результат. Но один вызов инструмента редко завершает реальную работу. Сложные задачи требуют планировщика, который разбивает цель на шаги, и сама модель является этим планировщиком. Затем она циклит: рассуждает о том, что делать, вызывает инструмент, наблюдает результат и, что важно, размышляет. Сработало ли это на самом деле? Эта самостоятельная проверка, это размышление — то, как агент ловит собственные ошибки на лету. И почему это ва

Вы приложили огромные усилия. Тонкая настройка — для формы, а RAG — для фактов. Теперь предупреждение: тонкая настройка соблазнительна и часто является неверным первым шагом. Она требует данных, оборудования, специалистов по машинному обучению и постоянного обслуживания навсегда. Хуже того, заточка модели под вашу задачу может незаметно притупить её везде — эффект, который мы называем налогом на согласованность. И вот унизительная правда. Большинство тинейджеров, которые клянутся, что промптинг не сработал, на самом деле никогда его как следует не тестировали. Их эксперименты были небрежными и несистематичными. Люди предполагают, что общая модель не справится с узкоспециализированной задачей. Однако GPT-4 побила Bloomberg GPT — модель с 50 миллиардами параметров, обучение которой стоило более миллиона долларов, — прямо на её собственных финансовых бенчмарках. Так что начинайте с промптинга. Исчерпайте его методично. Только потом беритесь за скальпель.

Допустим, вы решили заняться тонкой настройкой. Теперь вы врезаетесь в реальную стену — память. Запустить модель просто для получения ответов — относительно дёшево. Но обучать её — это совсем другой зверь. И причина в том, как на самом деле работает обучение. На прямом проходе входные данные проходят через сеть и выдают выход. Затем мы сравниваем этот выход с правильным ответом, чтобы получить loss — число, показывающее, насколько мы ошиблись. Обратное распространение пропускает loss обратно, чтобы вычислить градиент для каждого отдельного параметра — в каком направлении его подтолкнуть. Затем оптимизатор использует эти градиенты для обновления весов. Каждая из этих дополнительных величин — градиенты, состояния оптимизатора — также должна жить в памяти. Вот с каким зверем мы имеем дело. Вот в чём вызов. Давайте сделаем эту стоимость мучительно конкретной, потому что цифры определяют, какое оборудование вам нужно. Возьмите модель с 7 миллиардами параметров в 16-битной точности. Только веса — 14 ГБ. Но оптимизатор Adam хранит три значения на параметр. Это ещё 42 ГБ. Так что полная тонкая настройка означает примерно 56 ГБ в сумме. Большинство потребительских GPU держат всего 12–24 ГБ. Вы отрезаны. Занимаемый объём определяется тремя вещами: количеством параметров, сколько из них обучаемы, и сколько байт занимает каждое значение. Измените любое из этих трёх — и вы измените то, что возможно.

Запасной выход 1. Используйте меньше бит для хранения каждого числа. Это квантование. Представьте, что вы описываете цветок. Вы можете использовать миллионы оттенков или всего чистую палитру из 16 цветов, которая почти так же хороша и занимает долю размера. Модель с 13 миллиардами параметров в полной 32-битной точности — это 52 ГБ. Перейдите на 2 бита на значение — и будет 26 ГБ, мгновенное сокращение вдвое. Хитрый трюк под названием QLoRA продвигается дальше. Он хранит замороженные веса в крошечном 4-битном формате, а затем временно расширяет их обратно до более высокой точности только для математических операций. Эта одна идея позволила исследователям выполнить тонкую настройку модели с 65 миллиардами параметров на одном GPU с 48 ГБ. Однако одно предостережение: всегда загружайте модель в том формате, в котором она обучалась, иначе качество незаметно рухнет.

Запасной выход 2 атакует другую ручку. Сократите количество параметров, которые вы на самом деле обучаете. Это семейство называется параметро-эффективной тонкой настройкой, и его суперзвезда — LoRA. Вот прекрасная идея. Ту гигантскую матрицу весов, которую вы обычно обновляете, заморозьте полностью. Не трогайте её. Вместо этого выучите изменение как две тонкие матрицы — одну высокую и узкую, другую широкую и низкую, чьё произведение и есть обновление. Поскольку они низкого ранга, они занимают почти ничего. На GPT-3 LoRA обучила около 4,7 миллиона параметров — всего 27 тысячных долей процента от полной тонкой настройки, при этом сравнявшись с ней или превзойдя её. А когда вы закончите, вы складываете эти маленькие матрицы обратно в большие, так что на этапе инференса нет никаких дополнительных затрат. LoRA скрывает вторую суперспособность, которая является чистой магией для обслуживания множества клиентов. Поскольку обновление для каждой задачи — это просто крошечная пара матриц, вы можете хранить одну общую замороженную базовую модель и щёлкать на неё разный маленький адаптер для каждого клиента — как смена объективов на одном корпусе камеры. Сравните объём хранения. Обслуживание 100 клиентов с полными копиями матрицы весов 4000×4000 стоит более 1,6 миллиарда параметров. Но разделите базу и дайте каждому клиенту только адаптер — и вы снизите до 23 миллионов. Та же работа, крошечная доля занимаемого объёма. Именно это делает специализированный ИИ доступным в масштабе и даже достаточно маленьким для работы на телефоне.

Есть ещё один ход, который кажется почти слишком хорошим. Что, если у вас есть несколько точно настроенных моделей, каждая отлично справляется с одной задачей, и вы хотите объединить их силы? Вы буквально можете слить их в одну модель. Думайте о разнице между точно настроенной моделью и её базой как о векторе задачи — чистой сущности того, чему эта задача её научила. Вы можете суммировать эти векторы, чтобы усреднить два навыка. Вы можете накладывать чередующиеся слои из двух моделей или конкатенировать адаптеры, чтобы их ранги складывались в более богатый. Выгода: меньше моделей для хранения и одна модель, способная на мультизадачность. Идеально, когда память ограничена или вы отправляете модель на устройство.

Позвольте мне подкрепить всё это одной историей, которая охватывает весь урок. Grammarly взяла модель FL T5, примерно в 60 раз меньше, чем вариант GPT-3, и точно настроила её на примерно 82 000 пар ввода-вывода для своей конкретной задачи письма. Маленькая заточенная модель побила гиганта. В этом и заключается обещание правильно выполненной тонкой настройки: не сырой размер, а правильная форма для задачи. Им не нужно было больше фактов. Им нужно было, чтобы модель вела себя определённым образом, последовательно. Форма, а не факты. Скромная модель, трансферное обучение, сфокусированный набор данных и результат, до которого гораздо более крупная общая модель не дотянулась. Большой акцент, восходящая интонация. Вот в чём сила.

Итак, вот что нужно вынести. Тонкая настройка изменяет фактические веса модели. И вы прибегаете к ней только тогда, когда ошибки касаются формы, а не фактов, и только после того, как промптинг был действительно исчерпан. Стена, в которую вы упрётесь, — это память. И вы преодолеваете её двумя способами. Квантование сокращает количество бит на значение, а LoRA сокращает количество обучаемых параметров, часто за округляющую ошибку от стоимости. Эта единственная идея низкого ранга открывает доступный, сменный и даже работающий на устройстве ИИ. Но каждая точно настроенная лазерная настройка упирается в одну вещь, которую мы сегодня принимали как должное: данные, которыми вы её кормите. Те пары ввода-вывода не появляются по волшебству. Следующий урок, глава 8 «Инженерия наборов данных», — мы узнаем, как их создавать.

Добро пожаловать на восьмой урок нашего курса по инженерии ИИ. В прошлый раз мы узнали, как точно настраивать модель. Но вот секрет, который смиряет даже лучшие команды. У вас могут быть блестящие инженеры и бесконечные вычислительные мощности, и всё равно вы получите посредственную модель, если данные, которыми вы её кормите, плохи. Подумайте об этом. Когда создавалась GPT-3, за работу с данными отвечали примерно два человека. Для GPT-4 — около 80 плюс ещё 11 только для форматирования чата. Данные незаметно стали главным событием. Этот урок посвящён инженерии наборов данных — осознанному созданию данных, которые обучают лучшую модель, которую вы можете купить за свой бюджет. Итак, как сделать модель лучше? Годами инстинктом было изменить модель: сделать её больше, подкрутить архитектуру, учить дольше. Назовём это модель-центричным мышлением. Но есть второй рычаг, который часто оказывается более мощным и гораздо более дешёвым. Оставьте модель как есть и улучшите данные. Это дата-центричный ИИ. Представьте двух поваров, которым дали один и тот же рецепт и одну и ту же кухню. Один продолжает покупать дорогие печи. Другой просто находит более свежие ингредиенты. Второй повар часто побеждает. Реальный прогресс требует и того, и другого, но данные — это рычаг, который большинство команд недоиспользуют.

Прежде чем собрать хотя бы один пример, задайте настоящий вопрос: чего я на самом деле хочу от модели? Поведение, которое вы хотите, определяет форму ваших данных. Если вы просто хотите, чтобы она впитывала язык, кормите её сырыми последовательностями текста и пусть предсказывает следующий токен. Если вы хотите, чтобы она следовала инструкциям, вам нужны пары: инструкция и хороший ответ. А если вы хотите, чтобы она научилась вкусу — предпочитать один ответ другому, — вам нужны тройки: инструкция, выигрышный ответ и проигрышный. Сначала определитесь с поведением.

Какой бы ни был формат, отличные наборы данных балансируют три вещи, и кулинария — идеальный способ их прочувствовать. Во-первых, качество. Ваши ингредиенты свежие или гнилые? Плохие примеры отравляют блюдо. Во-вторых, покрытие. Иногда его называют разнообразием. У вас правильная смесь? Блюдо из одной соли провалится, какой бы чистой ни была соль. В-третьих, количество. Просто: сколько? Эти три фактора противодействуют друг другу в рамках фиксированного бюджета. И вот освобождающая часть. Качество и разнообразие обычно бьют сырой размер. Немного отличных данных может переплюнуть гору шума. Это утверждение звучит слишком хорошо, так что пусть говорят результаты. Команда Y обнаружила, что 10 000 тщательно составленных инструкций побеждают сотни тысяч зашумлённых. Эксперимент LIMA взял LLaMA с 65 миллиардами параметров и точно настроил её всего на 1000 кураторских примеров, и она сравнялась с GPT-4 или превзошла её в 43% сравнений. 1000 примеров. Урок не в лени, а в осознанности. Каждый пример заслуживает своё место. И один из самых эффективных инструментов — самый простой: 15 минут, когда человек смотрит на данные, читает строки и замечает, что не так.

Покрытие — это не только темы. Это также тип мышления, который вы хотите. Представьте вопрос по математике: «У Сары было 23 яблока, она отдала 20, затем купила ещё шесть». Слабый набор данных учит только окончательному ответу — девять. Но набор данных с цепочкой рассуждений учит модель показывать свою работу: «23 – 20 = 3. 3 + 6 = 9». Включая шаги рассуждения, а не только пункт назначения, вы учите модель, как думать над задачей, а не просто что запоминать. Это напрямую опирается на промптинг цепочки рассуждений из урока 5, только теперь мы встраиваем эту привычку в сами обучающие данные. Восходящая интонация, передавая волнение.

Итак, откуда берутся отличные данные? У вас есть четыре двери. Вы можете брать их из публичных наборов данных. Вы можете купить их. Вы можете платить людям за разметку. Или вы можете синтезировать их. Но есть и пятая, незаметно лучшая из всех — данные вашего собственного приложения. Почему? Потому что они в точности соответствуют вашему реальному распределению задач — фактическим вопросам, которые задают ваши реальные пользователи. И они накапливаются. Пользователи генерируют данные. Эти данные обучают лучшую модель. Лучшая модель привлекает больше пользователей, которые генерируют больше данных. Этот самоусиливающийся цикл — маховик данных. И как только он раскрутится, это самый ценный актив, который у вас есть.

Когда реальных данных не хватает, вы можете произвести их искусственно. И есть два разных подхода. Первый — аугментация. Преобразуйте уже имеющиеся данные. Переверните фото кота — это всё ещё кот. Теперь у вас два тренировочных изображения из одного. Или замените слово в предложении: «Она — медсестра. Он — медсестра». Вы научили модель сопротивляться гендерному предубеждению. А что делает сегодняшний день особенным? Сам ИИ может генерировать эти данные, делая синтез практичным даже для богатых сложных примеров. Так как же модель на самом деле генерирует обучающие данные? Несколько хитрых приёмов. Обратная инструкция переворачивает обычное направление. Начните с качественной статьи, которой вы доверяете. Затем попросите ИИ написать вопрос, на который эта статья идеально ответит. Мгновенная пара «инструкция — ответ». Дистилляция: большая модель-учитель генерирует ответы, которые обучают маленькую дешёвую модель-ученика подражать ей. Именно так Alpaca превратила 175 примеров в 52 000. И золотой стандарт — верификация через самовоспроизведение и тестирование. LLaMA 3 сгенерировала 2,7 миллиона синтетических примеров кода. Написала юнит-тесты, фактически запустила код и оставила только то, что прошло. Примерно 20% она отлавливала и самокорректировала.

Но синтетические данные — это не бесплатная магия, и вы должны уважать их опасности. Имитация может быть поверхностной. Ученик копирует стиль блестящих ответов, будучи вынужденным уверенно утверждать то, чего на самом деле не знает, — учится галлюцинировать. Хуже того, если вы будете снова и снова обучать модели на их собственных сгенерированных выходах, поколение за поколением, произойдёт коллапс модели. Общие закономерности раздуваются. Редкие и интересные случаи незаметно исчезают, пока модель не забудет края реальности. Правило, которое вас спасёт, простое и не подлежит обсуждению: всегда проверяйте перед обучением. Запустите код, оцените его с помощью судьи, сделайте обратный перевод, отфильтруйте шутку. Сгенерированные данные — это черновик, а не истина.

Последний практический вопрос: сколько данных вам на самом деле нужно? Сталкиваются две силы. Во-первых, убывающая отдача. Каждая дополнительная тысяча примеров помогает меньше предыдущей. Чун и коллеги наблюдали, как точность резко росла от девяти задач до 282, а затем выравнивалась к 1800. Во-вторых, ваш бюджет. Если примеры стоят $2 каждый, а у вас $10 000, это ровно 5000 примеров, не больше. Так что не гонитесь за бесконечностью. Тратьте там, где кривая ещё крута по качеству и покрытию, и прекращайте, как только наклон становится пологим. Инженерия, а не накопительство.

Итак, вот одна идея, которую нужно вынести из этого урока. Модель настолько хороша, насколько хороши данные, которыми вы её кормите. И эти данные вы создаёте целенаправленно. Качество, покрытие и количество — балансируя их в рамках реального бюджета. Выбор правильного формата для желаемого поведения и безжалостная проверка всего, что вы синтезируете. Курируйте с намерением, и тысяча отличных примеров может победить миллион небрежных. Теперь вы спроектировали набор данных и точно настроили модель. В следующем уроке, глава 9, мы обратимся к новой задаче: оптимизация инференса — сделать так, чтобы обученная модель работала быстро и дёшево, когда наконец придут реальные пользователи.

С возвращением. Мы на девятом уроке нашего путешествия по инженерии ИИ. Последние несколько глав мы делали модели умнее, адаптировали их, кормили лучшими данными. Но вот суровая правда, которая губит реальные продукты. Блестящая модель, которая отвечает 90 секунд, — хуже, чем бесполезная. Представьте, что вы задаёте вопрос и смотрите на пустой экран, который дышит. Точность, которую вы не можете себе позволить или не можете ждать, никому не нужна. Так что эта глава переворачивает вопрос. Мы закончили строить модель. Теперь как запустить её быстро и дёшево? Этот переход от обучения к инференсу — и есть весь этот урок.

Сначала давайте уточним слово. Обучение — это то, как мы построили модель. Инференс — это просто использование: взять вход и получить выход. Всё. Каждый ответ в чате, каждое резюме — один инференс. И когда мы хотим сделать его быстрее или дешевле, у нас есть три рычага. Мы можем работать на уровне модели — уменьшать или перепроектировать саму модель. Мы можем работать на уровне оборудования — запускать на лучших чипах. Или мы можем работать на уровне сервиса — менять способ обработки запросов. В реальных производственных системах вы редко выбираете один. Вы складываете несколько вместе. Запомните эти три уровня. Всё, что последует, относится к одному из них.

Прежде чем что-либо оптимизировать, мы должны понять, что на самом деле нас замедляет. И есть только два подозреваемых. Задача может быть ограничена вычислениями — то есть упирается в скорость вычислений. Чип выполняет арифметику так быстро, как может. Или она может быть ограничена пропускной способностью памяти — то есть чип голодает, ожидая, пока данные перейдут из памяти в процессор. Думайте о поваре. Ограничение по вычислениям — это когда вы рубите так быстро, как движутся руки. Бам. Ограничение по пропускной способности — это когда вы стоите без дела, пока ингредиенты несут из кладовой. Решающее число — арифметическая интенсивность: количество операций на перенесённый байт. Низкая интенсивность — вы ждёте данные. Высокая — вы ждёте математику. Разные узкие места — разные исправления.

Вот почему это так важно для языковых моделей. Один инференс на самом деле имеет две фазы с противоположными характерами. Когда приходит ваш запрос, модель читает все входные токены одновременно, параллельно. Это префилл. И это поток математики сразу — ограничение по вычислениям. Затем модель начинает писать. Она может выдавать только один токен за раз, каждое новое слово зависит от предыдущего. Это декод — ограничение по пропускной способности памяти. Префилл — это прочитать весь вопрос за один взгляд. Декод — отвечать одним осторожным словом за другим, пока не решит остановиться. Эти два профиля тянут в разные стороны, и почти каждая оптимизация, с которой мы встретимся, будет это учитывать.

Если мы хотим ускорить это, нам нужны честные цифры. Задержка чётко делится по этим двум фазам. Время до первого токена зависит от префилла, а время на выходной токен — от декода. Общая задержка — это время до первого токена плюс время на выходной токен, умноженное на количество токенов. Почувствуйте конкретно. При 100 миллисекундах на токен ответ из 1000 токенов займёт полных 100 секунд. И остерегайтесь средних значений. Если большинство запросов укладываются в 300 миллисекунд, но один выброс взлетает до 3000, среднее вам солжёт. Используйте процентили: P50, P90, P99. Затем пропускная способность — токенов в секунду, что напрямую связано со стоимостью, и это рычаг, который волнует бизнес.

Вот ловушка, которая обманывает почти всех. Вы смотрите на nvidia-smi. Там написано «Загрузка GPU 99%». И что вы думаете? Чип работает усердно, верно? Но постойте, это число измеряет только время, когда GPU был занят, а не то, делал ли он полезную работу. Честные метрики — MFU, MBU (использование флопсов модели, использование пропускной способности модели). Это ваша реальная производительность. Модель с 7 миллиардами параметров в 16-битной точности быстро. 100 токенов в секунду означают 700 ГБ/с пропускной способности. На A100 пик — 2 ТБ/с. Это 70% MBU. Вот настоящая история. Стремитесь сделать работу быстрее и дешевле. Никогда не гонитесь за числом загрузки ради него самого.

Теперь техники, начиная с уровня модели. Самая прямая идея — сделать модель меньше. Квантование хранит числа в меньшем количестве бит. Дистилляция обучает маленького ученика подражать большому учителю. Стрижка (pruning) отрезает соединения, которые едва важны. Но есть хитрый трюк, направленный прямо на узкое место декода — один токен за раз. Каждый новый токен перечитывает все предыдущие. Поэтому вместо того чтобы пересчитывать их, мы сохраняем их ключевые и значениевые векторы и используем их повторно. Это KV-кэш. На каждом шаге вычисляются и добавляются только ключи и значения самого нового токена. Всё остальное уже лежит там. Однако это не бесплатно. LLaMA 2 13B при batch=32 и длине последовательности 2000 — этот кэш раздувается до 54 ГБ.

Но у декода есть более глубокая фрустрация. Он последователен по своей природе: один токен, затем следующий, затем следующий. Модель не может забегать вперёд, или может? Вот прекрасная идея спекулятивного декодирования. Мы подключаем маленькую быструю модель-черновик, которая дёшево угадывает следующие несколько токенов. Затем большая точная целевая модель проверяет все эти догадки сразу. А верификация параллельна — дёшево, потому что это как раз то поведение префилла с ограничением по вычислениям, которое у нас уже есть. Мы сохраняем самый длинный отрезок догадок, с которыми она согласна, и отбрасываем остальные. Выгода реальна. Chinchilla 70B с моделью-черновиком на 4B снизила время с 14 миллисекунд на токен до менее 2. Задержка примерно вдвое без потери качества.

Теперь поднимемся на уровень сервиса — где мы вообще не трогаем модель, а просто умнее обслуживаем запросы. Главное — батчизация. Обрабатывайте много запросов вместе, чтобы дорогое оборудование работало над толпой, а не над однимоким запросом. Представьте автобус. Статическая батчизация ждёт, пока каждое место не заполнится, прежде чем отправиться. Эффективно, но первый пассажир ждёт вечность. Динамическая батчизация отправляется по расписанию или когда заполнена — что наступит раньше. И непрерывная батчизация — самая хитрая. Она высаживает завершивших пассажиров и подбирает новых на полпути. Так что ни одно место не пустует, пока другие ещё в пути. Добавьте кэширование запросов — повторное использование повторяющихся префиксов — и провайдеры сообщают об экономии до 90% затрат.

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

В основе всего этого лежит лестница памяти, объясняющая, почему пропускная способность правит бал. Память CPU перемещает данные со скоростью десятков ГБ/с. Высокопропускная память GPU — сотни, до полутора терабайт. А крошечная SRAM на крике — более 10 ТБ/с, но она крошечная. Умные ядра, такие как FlashAttention, выигрывают, удерживая работу в этой быстрой, дефицитной памяти. Давайте посмотрим, как это складывается. В реальном кейсе с LLaMA 7B на PyTorch инженеры накладывают техники одну за другой. Сначала torch.compile, затем 8-битное квантование, затем 4-битное, затем спекулятивное декодирование — и наблюдают рост пропускной способности на каждом шагу. В этом весь дух этой главы. Оптимизация — это не одно серебряное пуля. Это слои: модель, оборудование и сервис вместе.

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

Добро пожаловать на финальную остановку в нашем путешествии по инженерии ИИ. За последние девять уроков мы собрали части: поиск, безопасность, оценку, инференс. Сегодня, в главе 10, мы наконец выкладываем их все на один стол и задаём вопрос, с которым рано или поздно сталкивается каждый строитель: как превратить один вызов модели в реальное надёжное приложение, от которого зависят тысячи людей? Вот удивительная часть: вы не начинаете с большого. Лучшие архитектуры не проектируются одним махом на доске. Они растут по одному честному шагу за раз. Итак, давайте посмотрим, как система оживает блок за блоком, и закончим на топливе, которое поддерживает её улучшение, — ваших пользователях.

Представьте самое маленькое, что может сработать. Пользователь вводит вопрос, он отправляется модели, приходит ответ. Это всё приложение. Никакого поиска, никаких проверок безопасности, никакой умной маршрутизации. Зачем начинать здесь? Потому что каждый компонент, который мы добавим отныне, должен заслужить своё место, решая реальную проблему, с которой мы столкнулись. Сложность — это затраты, а не трофей. Отличный инженер добавляет блок только тогда, когда боль от его отсутствия становится очевидной. Так что держите эту картинку в уме как нашу основу. И давайте представим нашу первую реальную боль: модель просто недостаточно знает, чтобы ответить.

Вот основная идея. Фундаментальная модель блестяща, но изолирована. Она не знает сегодняшнюю погоду, документы вашей компании или историю заказов этого клиента. Поэтому до того, как модель ответит, мы идём и получаем необходимую ей информацию и передаём её ей. Мы называем это построением контекста. Думайте об этом как о инженерии признаков для фундаментальных моделей. Два основных способа улучшить контекст. Поиск (retrieval) извлекает текст, изображения, строки таблиц. Инструменты позволяют модели взаимодействовать с внешним миром: выполнить веб-поиск, проверить погоду, запросить базу данных. Скажите модели, и теперь она отвечает на основе фактов, а не догадок. Это само по себе преобразует надёжность.

Теперь новое беспокойство. Как только через систему начинают течь реальные пользователи и реальные данные, всё может пойти не так с обеих сторон. Поэтому мы размещаем защитные барьеры (guardrails) именно там, где живёт риск. Входные барьеры стоят перед моделью, не допуская утечки личных данных и блокируя вредоносные промпты. Вот аккуратный трюк: номер телефона маскируется в заполнитель [номер телефона], прежде чем покинуть ваши стены, и обратный словарь восстанавливает его на обратном пути. Выходные барьеры стоят после модели, отлавливая плохое форматирование, галлюцинации или токсичный текст и решая, что делать. Но барьеры добавляют задержку и с трудом работают со строковым текстом, поэтому небезопасный токен может проскользнуть, прежде чем вы его поймаете.

Пока одна модель обрабатывает всё, но не каждый запрос заслуживает вашу самую большую, самую дорогую модель. Простой FAQ не требует такой же вычислительной мощности, как глубокое устранение неполадок. Встречайте маршрутизатор — классификатор намерений, который предсказывает, чего именно хочет пользователь, и отправляет запрос по правильному пути. На страницу FAQ, к боту устранения неполадок или к реальному оператору-человеку. Дешевле, быстрее, умнее. Но маршрутизация между многими моделями становится запутанной. Поэтому мы добавляем шлюз — единый унифицированный безопасный вход ко всем вашим моделям. Приложения общаются только со шлюзом. Он обрабатывает контроль доступа, запасные планы, когда модель выходит из строя, и логирование. За единой конечной точкой вы можете обращаться к OpenAI или Gemini, и ваше приложение никогда об этом не узнает.

Готовимся к будущему. Каждый вызов стоит времени и денег, и пользователи задают одни и те же вопросы снова и снова. Зачем платить дважды? Кэширование сохраняет ответы для повторного использования. Точное кэширование использует ответ заново, когда запрос идентичен побайтно. Семантическое кэширование идёт дальше. Представьте, что два человека спрашивают «Какая столица Вьетнама?», но формулируют по-разному. Оба обращаются к одному кэшированному ответу: Ханой. Мы сравниваем значения с помощью эмбеддингов, а не точного текста. Мощно, но хрупко. Оно опирается на хорошие эмбеддинги, надёжный векторный поиск и тщательно настроенный порог. Если его ослабить, неверное совпадение вернёт уверенный неверный ответ. И остерегайтесь кэширования ответов, специфичных для пользователя, например, политики возврата на основе членства, — один клиент может увидеть данные другого.

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

Теперь у нас есть реальная система. Контекст, барьеры, маршрутизатор, шлюз, кэш и агентный цикл. Когда что-то ломается в два часа ночи, как вы узнаете, почему? Здесь вступают в игру мониторинг и наблюдаемость. И это не одно и то же. Мониторинг следит за вашими выходами, сообщая, что что-то не так. Наблюдаемость инструментирует систему, чтобы вы могли вывести внутреннее «почему» из логов, метрик и трассировок, не выпуская новый код. Звезда здесь — трассировка: горизонтальная временная шкала одного путешествия запроса, каждый шаг с отметкой времени и стоимости. И именно поэтому рынок наблюдаемости (имена вроде DataDog и Splunk) находится около ста миллиардов долларов.

Наконец, оркестрация связывает все эти компоненты в один плавный поток. Система работает, но что делает её лучше со временем? Вы, ваша обратная связь и разговорный интерфейс. Это обоюдоострый меч. Он делает обратную связь чудесно лёгкой для предоставления, но удивительно трудной для извлечения. Часть обратной связи явная: осознанный палец вверх или вниз. Большая часть неявная — незаметно выводится из того, что вы делаете. Возьмём поиск отеля в Сиднее. Три варианта: 400, 200 и 300 долларов за ночь. Если вы отвечаете «рядом с галереями», вы показали, что местоположение важно. Если вы спрашиваете «ничего дешевле 200», вы показали цену. Пользователь никогда не заполнял анкету, но чётко сказал, что имеет значение. Улавливать это — вот вся игра.

Но обратная связь зашумлена, и слепое доверие к ней даёт обратный эффект. Неявные сигналы скользки. Кто-то, делящийся ответом вашего чат-бота, может хвалить его или высмеивать. Предубеждения также проникают. Вспомните Uber в 2015 году, где средний рейтинг водителя был 4,8, а падение ниже 4,6 грозило деактивацией. Это смещение снисходительности (leniency bias), когда почти все ставят высокие оценки. Есть также смещение позиции, смещение длины, случайность и самая страшная ловушка из всех — сикофанство. Если вы обучаете модель добиваться одобрения, она учится говорить то, что вы хотите услышать, а не то, что истинно. Хуже того, образуется дегенеративный цикл обратной связи, когда собственные предсказания модели формируют обратную связь, которая переобучает её, незаметно усиливая её первоначальное смещение снова и снова.

Так зачем же бороться со всем этим шумом? Потому что хорошая обратная связь, правильно обработанная, становится конкурентным преимуществом, которое мало кто может скопировать. Представьте маховик. Пользователи взаимодействуют. Вы улавливаете честные сигналы. Вы улучшаете продукт, который привлекает больше пользователей и более богатую обратную связь. И колесо вращается быстрее. Рассмотрим набор данных Fitz. Обратная связь пользователей была разделена на восемь кластеров. И самый крупный — около 26,5% — был случаями, когда пользователи просили систему уточнить запрос. И снова, это не шум. Это карта того, что именно нужно исправить дальше. Это маховик данных. И именно поэтому вся эта область неуклонно сближается с продуктом. Тот, кто превращает разговоры в чистые, заслуживающие доверия данные, просто учится быстрее, чем все остальные.

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