Иерархическая карта концепций инженерии ИИ и ситуаций, когда они имеют значение
Узнайте, какие концепции инженерии искусственного интеллекта определяют, будет ли система вообще работать, какие из них важны при разработке для производства, а какие можно отложить.
Список существительных рассматривает все двадцать пунктов как эквивалентные, хотя на самом деле это не так. Шесть из них определяют, будет ли ваша система вообще функционировать. Ещё семь становятся значимыми, когда вы начинаете создавать что-то для производства. Последние семь — это вещи, которые вы должны уметь распознавать в разговоре, но их изучение можно безопасно отложить на год; к сожалению, именно их люди обычно изучают в свободное время.
В следующем тексте рассматривается то же самое, но к каждой концепции добавляются три аспекта: что она на самом деле даёт, в какой момент она начинает иметь значение и способ проверки того, действительно ли вы её понимаете, а не просто знаете термин.
Именно проверки заслуживают внимания. Большинство людей понимают, что месяцами просто кивали в знак согласия, только тогда, когда пытаются объяснить тему вслух впервые.
Уровень 1: Шесть элементов, определяющих работоспособность вашей системы
1. Эмбеддинги и векторный поиск
Что это даёт: Почти всё, что связано с поиском информации, зависит от этой концепции, и её неправильное применение приводит к сбоям, которые не вызывают ошибок.
Проверка: Два моделя эмбеддингов генерируют векторы размером 1024 измерения. Объясните, почему классификатор, обученный на результатах работы одной из моделей, всё равно будет выдавать некорректные результаты при обработке векторов от другой модели.
Если казалось, что совпадение размерностей — признак совместимости, это именно такое заблуждение. Модель эмбеддингов определяет собственную геометрию. Две разные модели поместят один и тот же текст в совершенно разные места в пространствах, которые лишь случайно имеют одинаковую форму. Ничто в вашей системе не предупредит вас об этом.
2. Качество поиска, которое не является тем же, что RAG
Что это дает: Почти весь уровень качества ответов в системе на основе поиска — причем почти никакого качества не исходит от самой языковой модели.
Проверка: Укажите три аспекта, при которых процесс RAG может сорваться ещё до того, как будет вызвана языковая модель.
Этими аспектами являются разбиение документа на фрагменты, генерация векторных представлений и их ранжирование. Если документ разделить не по правильным границам, можно потерять именно те предложения, которые отвечали на вопрос. Если использовать модель генерации векторов, обученную не для соответствующей области, терминология окажется в неправильной части векторного пространства. Если пропустить этап ранжирования, поисковый механизм вернёт результаты, тематически близкие, но фактически несвязанные с вопросом. Команды, которые считают, что у них проблема с галлюцинациями, как правило, имеют проблемы с поиском информации; они часто тратят месяцы на настройку запросов, прежде чем это проверить.
3. Оценка
Что это дает: возможность определить, действительно ли изменение улучшило ситуацию, что и отличает инженерный подход от угадывания.
Проверка: опишите эталонный набор, по которому вы проводите оценку — сколько примеров, откуда они взяты, по чему оцениваются и кто проверяет результаты.
Если вы не можете ответить конкретными цифрами, то у вас нет настоящей оценки — это лишь предположения плюс демонстрация, которая произвольно сработала во вторник. Разумная отправная точка — от двухсот до пятисот реальных пар «запрос-ответ», взятых из фактического трафика, оцененных по нескольким определённым критериям, при этом человек проверяет часть результатов. Также стоит знать, что если в качестве оценщика вы используете модель, то у этого оценщика тоже должна быть собственная оценка — рекурсивная проблема, которая вызывает дискомфорт, но неизбежна.
4. Структурированный вывод и использование инструментов
Что это дает: связь между системой, генерирующей текст, и системой, которая фактически выполняет действия.
Проверка: модель возвращает JSON, который не проходит верификацию по вашей схеме. Требуется точно описать, что будет делать ваша система дальше.
Большинство людей останавливаются на фразе «мы попробуем снова», но именно здесь начинаются настоящие вопросы. Сколько попыток, какая стратегия отсрочки, и включает ли попытка повтора информацию об ошибках верификации, чтобы у модели был шанс исправить собственную ошибку? Что происходит после окончательной неудачи — пользователь видит сообщение об ошибке или ухудшенный, но пригодный для использования ответ? Вызов инструмента по сути является вызовом функции через границу, которая может выдавать ложную информацию, поэтому здесь с той же степенью строгости применяются все стандартные практики проверки недостоверных данных.
5. Контроль затрат и задержек
Что это дает: понимание разницы между функцией, которая действительно выпускается, и демо-версией, отклоненной из-за финансовых ограничений.
Критерий оценки: укажите текущую стоимость одного запроса, затем перечислите пять способов сократить её вдвое, расставив их по степени влияния каждого из них.
Стоит иметь под рукой пять подходов. Отправляйте простые запросы более дешевой и меньшей модели вместо стандартной. Храните в кэше ответы на запросы, семантически близкие к уже обработанным, а не только идентичные им. Удаляйте или сжимайте всё то, что вы вставляете в промпт. Группируйте всё, что не требует мгновенного ответа, в пакеты и обрабатывайте их офлайн. Также сокращайте вывод модели, поскольку генерируемые ею токены обычно стоят дороже, чем токены, которые вы отправляете. По сообщениям, в этом месяце Stripe заплатила более 7 миллиардов долларов за OpenRouter — компанию, основной продукт которой по сути автоматизирует первые два из этих подходов, — что указывает на то, что отрасль больше не рассматривает контроль затрат как второстепенный момент.
6. Управление контекстом
Что это дает: предсказуемое поведение при превышении размера окна контекста, что постоянно происходит в реальных системах и практически никогда — в демо-версиях.
Проверка: когда окно контекста заполняется, что исключается из обработки и кто принимает это решение?
Четкий ответ указывает на конкретную стратегию: сначала удаляются самые старые сообщения, затем фрагменты с наименьшей оценкой, суммируется средняя часть или запрос отклоняется полностью. Беспокоящий ответ заключается в том, что фреймворк сам с этим справляется, поскольку это обычно означает тихое удаляние чего-то важного, и никто на самом деле не проверял, что именно.
Уровень 2: семь аспектов, которые вы узнаете при разработке реальных систем
Эти аспекты становятся важными тогда, когда система запущена и с ней начинают взаимодействовать реальные пользователи. Нет ничего плохого в изучении их раньше, но заниматься ими до первого уровня разработки означает направлять усилия не в том порядке.
7. Пromptы как версионированные объекты
Умение составлять эффективные promptы привлекает гораздо больше внимания, чем это заслуживает, тогда как инженерные аспекты, связанные с ними, получают гораздо меньше внимания. На самом деле необходим реестр, фиксированные версии, возможность сравнения и способатость к отката, поскольку prompt фактически является кодом, который попадает в производство, так и не пройдя через компилятор.
8. Стратегия разбиения на части
Разделение текста на окна фиксированного размера, разбиение по семантическим границам и добавление перекрытия между фрагментами — всё это различные компромиссы между воспроизводимостью и точностью. Правильный выбор зависит от структуры исходных документов, а не от того, что рекомендует учебное пособие по умолчанию.
9. Переупорядочивание
Обычный подход заключается сначала в получении широкого списка кандидатов с низкими затратами, а затем в проведении более ресурсоемкой процедуры оценки этого списка. Игнорирование второй процедуры, вероятно, является самой распространенной причиной того, что система поиска выдает результаты, которые кажутся почти правильными, но не совсем.
10. Ограничения и внедрение промптов
Это требует многоуровневой защиты: дешевые фильтры на входе и более дорогие проверки ближе к самой модели. Любой текст, поступающий от пользователя или из документа, загруженного вашей системой, следует рассматривать как потенциально враждебный ввод, а не как надежные инструкции.
11. Возможность наблюдения за недетерминистическими системами
Здесь вам нужны трейсы, а не просто логи. На самом деле важен вопрос о том, какие фрагменты данных были загружены и какая версия запроса использовалась, когда три дня назад появился конкретный плохой ответ, и только детали на уровне трейсов могут на него ответить.
12. Выбор между формированием запросов, поиском данных и тонкой настройкой
Это решение имеет гораздо большее значение, чем овладение какой-либо одной техникой. Получение информации обеспечивает знания, настройка форм и формата вывода — это то, что можно управлять без нее, а инструкции помогают с всем остальным. Распространенная ошибка — пытаться использовать настройку для решения проблем, которые на самом деле связаны с недостатками в получении информации.
13. Циклы агентов и выбор инструментов
Один агент, оснащенный тщательно подобранным набором инструментов и ограниченным циклом выполнения, способен решить удивительно большую часть проблем, которые люди пытаются решить с помощью многокомпонентных архитектур.
Уровень 3: Семь аспектов, которые стоит знать и отложить
На этом уровне достаточно хорошо знать словарный запас, чтобы следить за диалогом на данную тему. Более глубокое изучение можно отложить до тех пор, пока конкретная проблема не заставит с этим разобраться, но у многих специалистов такой момент так и не наступает.
14. Оркестрация многокомпонентных систем
Это самый преувеличенно оценённый пункт в списке. Все больше работ анализируют причины сбоев этих систем после внедрения, и повторяющийся вывод заключается в том, что издержки координации и растущие темпы ошибок зачастую приводят к худшей производительности по сравнению с одним хорошо спроектированным агентом в большинстве случаев использования. Знайте, к чему относится этот термин, и обращайтесь к данному подходу только в крайнем случае.
15. Квантизация и оптимизация обслуживания
Это имеет огромное значение, если вы сами храните веса модели, но практически не имеет значения, если вы просто вызываете API.
16. Внутренняя структура Transformer
Механизмы внимания, позиционные кодировки и остальная часть архитектуры встречаются гораздо чаще на собеседованиях, чем в повседневной работе. Стоит изучить их один раз, но глубокое понимание на удивление мало влияет на способ создания систем.
17. Дистилляция
Это становится полезным тогда, когда у вас уже есть рабочая, но дорогостоящая система, и вам нужно сократить расходы — это проблема, которая возникает со временем, а не изначально.
18. Семантическое кэширование
Мощная техника с серьезными недостатками: успешный поиск в кэше для почти совпадающего запроса возвращает неверный ответ, причем с полной уверенностью.
19. Графы знаний и GraphRAG
Они действительно приносят пользу, когда основные данные имеют истинно реляционную структуру, но для получения этих преимуществ требуется значительное дополнительное усложнение.
20. Настройка предпочтений и семейство RLHF
Это в основном касается команд, которые фактически обучают модели, а не тех, кто создает приложения на основе уже существующих моделей.
Неприятная часть
Если взглянуть на все три уровня, вы заметите что-то не такое.
Оркестрация множества агентов, внутренняя структура трансформеров и формулировка промптов — это темы, которые требуют наибольших усилий от людей в процессе обучения, причем все три относятся к уровню 2 или 3. Тем временем оценка, качество поиска и контроль затрат — вот что на самом деле определяет, будет ли реальная система работать, однако им уделяется лишь незначительное внимание, главным образом потому, что ни одна из этих составляющих не позволяет создать убедительную демонстрацию.
У этого разрыва есть ясная причина, и её стоит сказать прямо, а не в виде критики. Темы уровня 3 легко воспринимаются: вы можете прочитать о многоканальной оркестрации во время поездки и уйти с чувством, что что-то узнали. Оценка же заставляет вас создавать идеальный набор данных, спорить с коллегой о том, что вообще значит «хорошо», и иногда смиряться с тем, что ваша система никогда не была настолько сильной, как казалось в демонстрации. Одна из этих задач приносит комфорт, а другая действительно помогает.
Как на самом деле изучить эти темы, а не просто собрать информацию о них
Ловушка любого подобного списка заключается в том, что его начинают рассматривать как учебную программу, которую нужно прочитать. Чтение позволяет лишь распознавать информацию, но это распознавание исчезает сразу, как только кто-то задаёт дополнительный вопрос.
Два привычных подхода работают гораздо лучше, чем простое чтение.
Сначала постройте одну небольшую систему от начала до конца, затем умышленно нарушите её работу. Направьте процесс поиска на документы, которые вам действительно важны, и намеренно сорвите каждый этап. Плохо разделите текст на фрагменты и посмотрите, как ухудшится качество ответов. Удалите механизм переранжирования и обратите внимание на происходящие изменения. Попробуйте ввести в систему попытку инъекции запроса и посмотрите, что она выдаст. Один такой уик-энд принесёт больше знаний, чем месяц чтения, потому что у вас останутся воспоминания о конкретных сбоях, а не абстрактные определения.
Во-вторых, протестируйте этот словарный запас на реалистичных вопросах. Проверки, описанные в этой статье, основаны на типах вопросов, которые действительно возникают на практике, и решение реальных задач в стиле проектирования систем — это самый быстрый способ выявить пробелы в вашем понимании, поскольку реальные вопросы сопровождаются дополнительными уточнениями, и именно в этих моментах поверхностное понимание уже недостаточно.
Где я могу ошибаться
Эта классификация представляет собой субъективную оценку, сформированную на основе конкретных систем, рассмотренных здесь, а не результат формального опроса; поэтому честнее назвать её обоснованным порядком, а не окончательным.
Есть два пункта, по которым стоит открыто обсуждать их расположение. Оркестрация многих агентов находится в третьем уровне отчасти потому, что существующие данные о поведении таких систем в реальных условиях не очень обнадёживающие, и появление действительно надёжной платформы в ближайшем будущем может легко поднять её на более высокий уровень. Внутренние механизмы Transformer занимают низкое положение здесь, поскольку работа с ИИ-моделями всё чаще является задачей интеграции, а не моделирования, и те, кто работает непосредственно с самими моделями, должны поднять этот пункт на несколько позиций выше.
Пунктом, который следует защищать наиболее решительно, является оценка, занимающая третье место, однако есть веские основания для того, чтобы поставить её на первое место. Без неё все остальные пункты этого списка превращаются в догадки, поскольку невозможно улучшить то, что нельзя измерить, и сегодня лишь немногие команды, разрабатывающие на основе моделей, могут с уверенностью сказать, улучшила ли прошлой неделе внесённая изменение ситуацию или ухудшила её.
Если бы вы переустроили этот рейтинг, наиболее интересные разногласия, скорее всего, возникли бы на границе между уровнями 1 и 2. Более полезным будет обсуждение того, какие позиции стоит поднять выше и что на самом деле принесет эта изменение, а не создание ещё одного списка из двадцати позиций.
Связанные статьи
- Управление LLM в роли судьи как живой производственной системы — Узнайте, как четырехэтапный цикл жизни Netflix — использование проверенных данных, обучение с учётом критериев оценки, безопасное внедрение и постоянный мониторинг — позволяет сохранять точность LLM в качестве судьи в масштабах.