В течение последних двух десятилетий принципы проектирования API были сосредоточены вокруг человека-разработчика. Мы создали системы, оптимизированные для их удобства, с гибкими конечными точками и обширной документацией, которую они могли интерпретировать.
Но новый и мощный класс потребителей уже совершает прорыв в виде автономных агентов искусственного интеллекта, которые действуют на фундаментально другом наборе принципов, что требует нового подхода к тому, как мы создаем и описываем наши услуги.
«Это означает новую парадигму для нас, как разработчиков: теперь мы должны создавать API, оптимизированные для использования машинами, что требует принципиально иной философии проектирования, чем та, которую мы используем для человекоориентированной разработки», — говорит Шринивасан Секар, технический директор LambdaTest, платформы для тестирования программного обеспечения, основанной на искусственном интеллекте.
Этот растущий сдвиг в сторону философии проектирования «ИИ прежде всего» отдает приоритет явной ясности и предсказуемости, которые необходимы машинам для эффективного мышления и действий. Это лежит в основе четкой основы для перепроектирования систем для нового агентного мира.
Переход от «разработчик прежде всего» к «ИИ прежде всего»
В основе этого нового манифеста лежит основной культурный сдвиг, который должен предшествовать любым архитектурным изменениям: переход от дизайна «сначала разработчик» к дизайну «сначала ИИ». Как объясняет Секар, на протяжении многих лет мы оптимизировали наши API для удобства разработчиков.
Этот подход способствует гибкости, что часто приводит к меньшему количеству многоцелевых конечных точек и использованию внешней документации для устранения двусмысленности. Разработчик-человек может прочитать руководство, чтобы понять, что определенный параметр требуется только тогда, когда присутствует другой — нюанс, который мы уже давно воспринимаем как должное.
«Теперь мы должны создавать API, оптимизированные для использования машинами, что требует принципиально иной философии проектирования, чем та, которую мы используем для разработки, ориентированной на человека».
— Шринивасан Секар, технический директор LambdaTest
Однако агенты ИИ — это принципиально разные потребители. Они не могут читать внешнюю документацию или определять неявные связи между параметрами. ИИ работает исключительно на основе явного машиночитаемого контракта, предоставляемого схемой API. В этом, по его мнению, и заключается суть философии «ИИ прежде всего»: подхода к проектированию, который отдает приоритет абсолютной, однозначной ясности, необходимой машинам, не оставляя места для интерпретации в контракте.
Сай Кришна, работающий вместе с Секаром, добавляет к этому сдвигу практическое измерение: «В LambdaTest мы усвоили это на собственном горьком опыте. У нас был идеально функциональный API для настройки тестовых сред, который разработчики любили за его гибкость. Но когда агенты ИИ начали его использовать, мы увидели 40% отказов, потому что агенты не могли интерпретировать неявные правила, которые мы задокументировали отдельно. Нам пришлось полностью переосмыслить наш подход».
Это означает предпочтение более конкретным, одноцелевым конечным точкам и явное определение всех ограничений внутри самой схемы. Такое мышление является непререкаемым фундаментом для построения любой успешной и надежной агентской системы.
Отказ от трех привычек человекоориентированных API
Принятие на практике философии «ИИ прежде всего» означает активный отказ от некоторых укоренившихся привычек традиционного, ориентированного на человека проектирования API. Секар выделяет три распространенных шаблона, которые, хотя и удобны для разработчиков-людей, создают критические сбои при использовании агентами ИИ.
Во-первых, это привычка перегружать отдельные конечные точки множеством вариантов поведения. Разработчик может справиться с такой гибкостью, но агенту ИИ приходится бороться с двусмысленностью. Подход, ориентированный на искусственный интеллект, требует отдельных, одноцелевых конечных точек, в которых функция является явной.
- До: Одна конечная точка POST/user будет неоднозначно обрабатывать как создание, так и обновление пользователя в зависимости от того, присутствует ли идентификатор в полезных данных.
- После: Подход AI-first использует две отдельные и предсказуемые конечные точки: POST /users для создания нового пользователя и PUT /users/{id} для обновления существующего.
Во-вторых, это зависимость от неявных контрактов и внешней документации. Чтобы агент действовал надежно, все связи и зависимости параметров должны быть явно объявлены внутри самой машиночитаемой схемы.
- До: Традиционная схема указывает user_type и admin_level как необязательные, что вынуждает разработчика читать внешнюю документацию, чтобы узнать их условную связь.
- После: Схема AI-first делает эти отношения явными с использованием условной логики, позволяя машине понимать контракт без какого-либо внешнего контекста.
Наконец, команды должны отучиться от привычки предоставлять общие ответы об ошибках. API, ориентированный на искусственный интеллект, должен предоставлять структурированные и подробные ответы на ошибки, которые позволяют агенту самостоятельно исправлять ошибки.
- До: Общий ответ JSON, например {«message»: «Bad Request»}, остановит автоматизированный рабочий процесс.
- После: Структурированная ошибка JSON предоставляет специальные поля для кода ошибки, сообщения и сведений, указывающих, какой именно параметр является недопустимым.
Эти изменения имеют общую цель – устранение двусмысленности. Делая явными конечные точки, контракты и ошибки, разработчики обеспечивают предсказуемую основу, необходимую автономным агентам для надежной и эффективной работы.
Новые основы проектирования на основе искусственного интеллекта
Помимо простого отказа от старых привычек, создание API, ориентированного на искусственный интеллект, требует принятия нового набора позитивных принципов проектирования, основанных на ясности и предсказуемости.
«Все начинается с семантической ясности», — говорит Шон Фалконер, старший директор по продуктам и стратегии искусственного интеллекта в Confluent. По-настоящему ориентированный на искусственный интеллект API должен делать больше, чем просто описывать свою техническую функцию; его машиночитаемый контракт должен также описывать его деловую цель, предварительные условия и любые потенциальные побочные эффекты. Это обеспечивает богатый контекст, в котором агент ИИ должен рассуждать не только о том, как использовать инструмент, но и о том, когда и почему.
По-настоящему ориентированный на искусственный интеллект API должен делать больше, чем просто описывать свою техническую функцию; его машиночитаемый контракт должен также описывать его деловую цель, предварительные условия и любые потенциальные побочные эффекты.
Это означает, что разработчики должны расширять свои схемы API, выходя за рамки простых типов данных. Например, в спецификации OpenAPI каждый параметр и конечная точка должны включать подробное описание, объясняющее не только «что» (например, целочисленный идентификатор), но и «почему» (например, уникальный идентификатор клиента, используемый для выставления счетов и заявок в службу поддержки).
Такого уровня ясности лучше всего достичь путем разработки того, что Фальконер называет небольшими, специально созданными инструментами, а не путем раскрытия больших, общих поверхностей API. Йони Майкл, технический директор Typedef, согласен с этим принципом, выступая за «минимальную площадь поверхности», то есть API должен предоставлять только то, что абсолютно необходимо для конкретной задачи.
Для архитекторов это означает четкий мандат на проектирование: не поддавайтесь желанию создавать монолитные универсальные конечные точки. Вместо этого сложные бизнес-процессы следует разбивать на мельчайшие логические компоненты с выделенным ограниченным API, разработанным для каждого из них. Например, обширный API /orders можно преобразовать в целенаправленные, специализированные инструменты, такие как /create-order, /check-order-status и /request-refund. Создание этих четко определенных инструментов снижает двусмысленность и когнитивную нагрузку на ИИ, облегчая управление и оценку его поведения.
Все эти принципы служат одной важной цели: достижению того, что Майкл называет детерминированным поведением. Автономный агент не может позволить себе сюрпризов, когда он объединяет несколько инструментов для выполнения сложного рабочего процесса. Система должна быть предельно надежной и предсказуемой.
Чтобы добиться этого, инженеры должны уделять приоритетное внимание тщательному тестированию и проектированию без сохранения состояния, где это возможно. Каждый вызов API с одинаковыми входными данными должен последовательно выдавать один и тот же результат, без скрытых зависимостей или непредсказуемых побочных эффектов. Это предполагает предоставление понятных идемпотентных интерфейсов для любых операций, изменяющих данные, гарантируя, что повторные вызовы не будут иметь непредвиденных последствий.
Создавая API с семантической ясностью, минимальной площадью поверхности и четкой целью, архитекторы обеспечивают основу доверия, которая позволяет агенту ИИ эффективно использовать их.
Препятствия преобразования данных для ИИ
Даже при наличии этих дальновидных принципов проектирования существует последняя, более глубокая архитектурная задача, которая лежит в основе всех проектов, ориентированных на искусственный интеллект. Секар из LambdaTest называет это самым серьезным препятствием из всех: трудная, но необходимая задача выравнивания модели данных.
Он объясняет, что большинство существующих корпоративных API отражают глубоко укоренившиеся проблемы платформы данных, поскольку они были разработаны на основе сложных внутренних схем баз данных или вложенных объектных моделей. Хотя разработчик-человек может ориентироваться в этих сложных структурах, они создают значительные «когнитивные издержки» для агента ИИ.
Глубоко вложенная структура данных вынуждает модель ИИ тратить ценные ресурсы, просто понимая форму данных и взаимосвязи между их частями, прежде чем она сможет даже начать воздействовать на информацию.
Эта сложность приводит к высокой вероятности ошибки и делает поведение агента менее предсказуемым. Решение, ориентированное на искусственный интеллект, состоит в том, чтобы сгладить и нормализовать эти модели данных, преобразовав их в более простые и предсказуемые форматы, оптимизированные для машинного использования.
«Компании, создающие самые надежные агентные системы, не обязательно имеют самые сложные модели искусственного интеллекта. Это те, кто проделал тяжелую работу по перепроектированию своих основ API, чтобы они могли говорить на языке, понятном машинам».
— Шринивасан Секар
И это обычно самая ресурсоемкая часть пути к тому, чтобы стать «нативным» ИИ. Секар утверждает, что эта задача выходит далеко за рамки простого документирования существующих систем. Часто требуется фундаментальная переработка уровня доступа к данным и создание совершенно новых параллельных поверхностей API, специально созданных для агентов ИИ.
Кришна разделяет практическую реальность этой трансформации: «Сейчас мы поддерживаем два уровня API: наш устаревший API для разработчиков и наш API, оптимизированный для ИИ. Версия ИИ берет объект результата теста, который ранее был вложен в четыре уровня, и сглаживает его в одноуровневую структуру с явными идентификаторами отношений. Это утроило размер нашей схемы, но сократило время обработки агента на 70%. Инвестиции были значительными, но необходимыми». Это гарантирует, что контекст, предоставляемый ИИ, не только семантически ясен, но также структурно прост и сразу полезен.
Будущее — это «поведенческий контракт»
В совокупности эти принципы — культурный сдвиг в сторону подхода, ориентированного на искусственный интеллект, отказ от старых привычек и глубокая архитектурная приверженность ясности и простоте моделей данных — образуют новый манифест проектирования API. Но влияние этой новой философии выходит за рамки первоначального проектирования наших систем и охватывает весь их жизненный цикл.
Секар прогнозирует, что это в конечном итоге изменит основные практики DevOps, такие как управление версиями API. В мире, где автономные агенты являются основными потребителями, фокус управления API сместится с отслеживания простых изменений синтаксиса на обеспечение «поведенческих контрактов». Обещание ИИ больше не будет состоять только в том, что структура API будет стабильной, но и в том, что его поведение будет последовательным и предсказуемым, гарантируя, что одни и те же входные данные всегда будут давать ожидаемый тип результата.
Кришна подробно описывает, как это происходит в оперативном плане: «Мы начали создавать версии наших поведенческих контрактов отдельно от наших версий API. Агент подписывается на поведенческий контракт, скажем, «возможность поиска с нумерацией страниц», и мы гарантируем поведение этого контракта, даже когда мы развиваем базовую реализацию. Если нам нужно изменить поведение, мы вводим новую версию контракта, давая агентам время на адаптацию».
И Секар, и Кришна подчеркивают, что эта приверженность явным, предсказуемым и поведенчески согласованным API является высшим выражением философии «ИИ прежде всего».
«Компании, создающие самые надежные агентные системы, не обязательно имеют самые сложные модели искусственного интеллекта», — отмечает Секар. «Именно они проделали тяжелую работу по перепроектированию основ API, чтобы они говорили на языке, понятном машинам».
На этой основе будет построено следующее поколение надежных агентных приложений искусственного интеллекта.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Сакиб Ян — технологический аналитик с опытом разработки приложений, FinOps и облачных технологий. Подробнее от Сакиба Джана
