Frank Coyle про онтологии: логика снаружи вероятностного агента (Рубрика #AI)

Посмотрел двадцатиминутный доклад Фрэнка Койла «Why Agentic Systems Need Ontologies» с AI Engineer World's Fair 2026. У меня со словом «онтология» долго были сложные отношения: в разговорах об архитектуре оно было почти стоп-словом. Слишком часто этой терминологией пользовались люди, очень далёкие от практики: вместо работающего контракта получалась попытка сначала классифицировать весь мир.

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

Фрэнк Койл - это преподаватель School of Information в UC Berkeley; среди прочего он ведёт курс по представлению знаний для интеллектуальных приложений. Главный тезис его выступления простой: вероятностное рассуждение нужно оставить внутри LLM, а формальную логику - вынести наружу. Модель хорошо интерпретирует неструктурированный запрос, собирает контекст и предлагает следующее действие. Но она не обязана каждый раз заново угадывать, что такое заказ, кто имеет право получить выплату и какие состояния допустимы у доставки. Это уже знание конкретного домена.

В упрощённом виде таксономия отвечает на вопрос, какие типы объектов у нас существуют. Онтология добавляет отношения и правила: клиент оформляет заказ, заказ содержит товар, возврат относится к заказу, сотрудник поддержки и покупатель - разные роли. Поверх этого можно задавать ограничения и выводить новые факты.

В докладе эта идея превращается в два шлюза вокруг вызова инструмента:
- До вызова Pydantic проверяет форму запроса: типы, обязательные поля и диапазоны значений;
- Результат сверяется с моделью домена: допустимы ли роли, связи, состояния и кардинальность;
- Только после проверок изменение должно попадать в реальный мир; сомнительный результат возвращается в цикл или передаётся человеку.

Койл показывает очень приземлённые ошибки: повторный возврат денег по одному заказу, выплату сотруднику поддержки вместо покупателя и статус доставки probably shipped там, где система ожидает только paid, shipped или refunded. Описывать такие инварианты абзацами в системном промпте можно, но промпт остаётся просьбой к модели. Формальное правило становится общим машинно-проверяемым контрактом для разных агентов и инструментов.

Для меня именно здесь слово «онтология» перестаёт быть стоп-словом. Речь не о том, чтобы построить окончательную модель всей компании. Достаточно локальной онтологии операции: какие сущности участвуют, какие переходы разрешены и что должно быть истинно до необратимого действия. В этом смысле она оказывается рядом со схемой API, движком политик (policy engine), машиной состояний и ограничениями базы данных, а не рядом с красивой архитектурной картинкой.

Есть, правда, важная оговорка. В докладе OWL (Web Ontology Language) местами выглядит как готовый валидатор бизнес-правил, но семантика OWL работает в открытом мире: отсутствие факта не означает его ложность, а FunctionalProperty при двух значениях может привести к выводу, что значения обозначают один объект, а не к привычной ошибке валидации. Для закрытых проверок вида «не больше одного возврата» или «только одно из трёх состояний» обычно нужен отдельный слой: SHACL, код, ограничения базы данных, движок политик или их комбинация. И, конечно, идемпотентность и транзакционные гарантии онтология тоже не заменяет.

Но это не отменяет главного тезиса доклада. Наоборот, делает его практичнее: полезен не термин сам по себе, а явная исполняемая модель домена, которую можно версионировать, тестировать, назначить ей владельца и поставить перед действием агента.

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

#AI #Agents #Architecture #Engineering #KnowledgeGraphs #Data