Онтологии вместо RAG: как Palantir строит цифровых двойников, которых понимают и люди, и ИИ-агенты

У компании обычно десятки систем: ERP, CRM, SCADA, поток IoT-телеметрии и Excel, который формально «для служебного пользования», а по факту влияет на решения с крупным бюджетом. Данные есть. Общий смысл часто отсутствует: «клиент» в одной системе не совпадает по определению с «клиентом» в другой.

Последние годы эту проблему часто закрывают RAG: всё кладут в векторную базу и рассчитывают, что LLM разберётся. Для поиска по документам этого обычно хватает. Но агенту нужно другое: понять, что «Насос №14» - физический объект с историей отказов, связанный с «Линией 3», и корректно запросить его состояние через API. На этом этапе одного RAG недостаточно.

Один из подходов, который уже применяют в промышленных масштабах, - Ontology от Palantir. Ниже: как устроена эта архитектура и чем она отличается от поиска по похожим текстам.

Кто это такие

Palantir основали в 2003-м в Пало-Альто выходцы из «мафии PayPal»: Тиль, Карп, Лонсдейл, Коэн и Геттингс ^[1]. Первый продукт - Gotham, анализ разнородных данных для разведки. Среди ранних инвесторов - венчурный фонд ЦРУ In-Q-Tel. Компания изначально ориентировалась на государственные и оборонные сценарии, а не на retail-аналитику.

На биржу вышли в сентябре 2020-го через прямой листинг на NYSE, без классической IPO-процедуры с андеррайтерами ^[2]. С тех пор Palantir расширяет коммерческий Enterprise, сохраняя госконтракты.

В апреле 2023 года запустили AIP: LLM и агенты поверх уже существующей онтологии ^[3]. Формат внедрения - bootcamp: команда Palantir работает у заказчика и за 1-5 дней доводит конкретный кейс до рабочего прототипа на его данных ^[3]. За первые полгода через bootcamp прошли около 300 компаний, к концу 2024-го - больше 1300 ^[4].

По отчёту за Q3 2025: коммерческая выручка в США +121% год к году, 12-й квартал GAAP-прибыльности подряд, Rule of 40 на уровне 114% ^[4]. Цифры сами по себе не доказывают правильность архитектуры, но показывают, что модель востребована рынком. Дальше - что именно продаётся под названием Ontology.

Что такое Ontology

С OWL/RDF из Semantic Web нулевых у подхода Palantir мало общего, хотя набор понятий формально похож: классы, свойства, связи. Отличие в том, что онтология здесь участвует в рабочих процессах платформы, а не существует только как схема «на бумаге».

По документации, Ontology связывает цифровые активы (датасеты, таблицы, ML-модели) с сущностями предметной области: оборудованием, линиями, заказами, транзакциями ^[5]. По сути это исполняемый цифровой двойник организации из двух слоёв.

Семантика

Object types: схема сущности предметной области («Оборудование», «Транзакция», «Сотрудник»). Object - конкретный экземпляр.
Properties: характеристики объекта; для «Аэропорта» это, например, name и country ^[6].
Link types: связи между типами объектов: 1-к-1, 1-ко-многим, многие-ко-многим.

Действия и логика

Action types: набор изменений, который пользователь или агент применяет за одну операцию, включая побочные эффекты ^[7]. Важно: action делает write-back в исходную мастер-систему, то есть правки доходят до источника данных, а не остаются только в кэше платформы.
Functions: бизнес-логика поверх объектов, доступная как API.

Отличие от обычного DWH существенное. В DWH смысл часто живёт в голове аналитика, который пишет SQL по нормализованным таблицам. В онтологии Palantir смысл встроен в модель: «Насос» - объект с типом, свойствами, связями с «Линией» и историей событий, для которого задан допустимый набор действий. В таблице equipment от него обычно остаётся только строка без семантики поведения.

Почему это важно для агентов

RAG отвечает на вопрос, где искать текст, похожий на запрос. Ему не важны структура предметной области и список безопасных операций над найденным фрагментом. Для чат-бота с базой знаний этого часто достаточно. Для агента, который должен перепланировать маршрут, сменить статус заказа или отправить бригаду на объект, этого мало.

Онтология закрывает разрыв тремя свойствами:

Структура вместо текста. Вместо фрагмента с оценкой релевантности агент получает типизированный объект со свойствами и связями. Это сужает пространство произвольных интерпретаций.
Явный список действий. Агент выбирает из зарегистрированных Action types с заданными правами и побочными эффектами, а не конструирует API-вызов с нуля.
Прослеживаемость. Каждое действие агента фиксируется в модели и уходит write-back в исходную систему. Побочный эффект можно воспроизвести и разобрать.

Palantir описывает это как переход от Decision-Support к Decision-Execution: агент действует внутри заранее заданных ограничений.

Где это применяют

Энергетика. В одном из нефтегазовых кейсов цифровой двойник собирает около миллиарда точек данных в день с датчиков скважин и сводит их с симуляцией месторождения. Расчёт, который занимал 24 часа, сократился примерно до 20 минут ^[8]. Данные уже лежат в модели; не нужно сначала вручную сводить десяток источников.

Производство. В Foundry цифровые двойники считают себестоимость и маржинальность на уровне отдельного SKU: затраты, объёмы, логистика и производственные ограничения в одной модели ^[9]. Здесь онтология отвечает на прикладной вопрос: сколько реально стоит единица товара.

Диспетчеризация. Аномалия на одном датчике распространяется по графу связей на зависимые объекты без отдельного кода под каждый частный случай. Правило задаётся на уровне типа, а не вручную для каждого экземпляра.

Ограничения

У подхода есть цена:

Построение онтологии - инженерный проект. Нужно согласовать, что в конкретном бизнесе считается объектом, какие у него свойства и связи, и кто поддерживает модель, когда процесс меняется. Это совместная работа архитекторов данных и предметных экспертов; полностью автоматизировать её нельзя.
Vendor lock-in. Онтология, Action types и Functions живут внутри конкретной платформы. Перенос на другой стек означает повторное описание модели, а не простой экспорт CSV.
Высокий порог входа. Palantir - дорогая enterprise-платформа с длинным циклом продаж. AIP Bootcamp как раз сокращает путь от контракта до проверяемого прототипа на данных заказчика.

Сам паттерн шире одной компании: семантический слой между сырыми данными и потребителями (людьми и агентами) с явно описанными допустимыми действиями. В разных экосистемах его называют knowledge graph, digital twin или онтологией.