Почему RAG недостаточен: семантический слой для графовых, SQL- и векторных запросов
RAG не справляется с многократными прыжками в поиске, числовыми данными и неоднозначными корпоративными вопросами. Семантический слой обеспечивает разбиение данных, маршрутизацию и сопоставление схем, при этом для обеспечения портабельности используется Apache Ossie.
Модели языка сделали возможным простое формулирование корпоративных вопросов на понятном языке. Получение ответа — это не то же самое, что понимание смысла вопроса в контексте нескольких информационных систем. Возьмем этот пример:
Представьте, что аналитик задаёт вопрос: какие фонды, торгуемые на бирже, владеют компаниями, стратегически сотрудничающими с NVIDIA, управляют активами на сумму свыше миллиарда долларов и получают положительные оценки в недавних исследовательских отчётах?
Это выглядит как один вопрос, но на самом деле он включает три этапа обработки:
- NVIDIA, стратегический партнёр, фонды-держатели активов: анализ связей в виде графа.
- Активы свыше 1 миллиарда долларов: точная числовая фильтрация.
- Положительные последние исследования: анализ неструктурированного текста.
Под этим кроется более глубокая проблема. Что означает AUM в основной модели данных, и какой источник является авторитетным по этому вопросу? Прежде чем система сможет дать правильный ответ, она должна понимать смысл данных, а не просто сами данные. Семантическая инженерия направлена на преодоление этого разрыва.
Где заканчивается RAG
Типичная схема RAG извлекает релевантные фрагменты текста и позволяет модели отвечать на основе них. Это отлично подходит, когда задача заключается в поиске релевантного текста и ответе на его основе. Однако вопросы корпоративного уровня часто требуют большего, чем просто сходство, и чистый векторный поиск терпит неудачу четырьмя очевидными способами.
Фрагментированный поиск
Представьте руководство к продукту, разделенное на три части:
Chunk 1: Atlas Enterprise — vendor, category
Chunk 2: Pricing — base fee, usage fee
Chunk 3: Risks — lock-in, migration, data residency
Кто-то спрашивает о ценах и рисках Atlas Enterprise. Название продукта может появляться только в первом фрагменте. Во втором и третьем фрагментах содержатся ответы, но после разделения на фрагменты они теряют контекст сущности. Обогащение метаданных, поиск связей «родитель-дочерний» и переранжирование помогают, однако фрагментация остается основной слабостью.
Отсутствие возможности прослеживания связей
Теперь зададимся вопросом: какие ETF владеют компаниями, сотрудничающими с NVIDIA? Путь вывода ответа не сводится к простому совпадению одного ключевого слова:
NVIDIA
↓ HAS_STRATEGIC_PARTNER
Company
↓ HELD_BY
ETF
Поиск по векторам позволит найти документы, в которых упоминаются NVIDIA, её партнеры или ETF-фонды. Однако он не может надёжно утверждать, что эти упоминания образуют определённые многократные связи. Граф может явно проследить этот путь:
?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .
Похожий текст не является тем же, что и связь между сущностями.
Неоднозначность сущностей
Название вроде «NVIDIA» может относиться к нескольким вещам:
NVIDIA → Company
NVIDIA International → Subsidiary
NVIDIA AI Enterprise → Product
Их эмбеддинги могут находиться рядом друг с другом, но это разные сущности разных типов. Онтология обеспечивает информацию об идентичности, типе и связях, чего не может сделать анализ сходства текстов.
Отсутствие точного числового фильтрации
Запрос вроде "клиенты с годовым доходом выше 1 млн долларов и вероятностью ухода ниже 5%" — это обычный SQL:
SELECT customer_id
FROM customer_metrics
WHERE annual_revenue > 1000000
AND churn_probability < 0.05;
Эмбеддинги отражают степень сходства. Они не всегда способны выполнять операции типа «больше чем», «меньше чем», «между», агрегацию или ранжирование.
Один вопрос, несколько движков
Для решения поставленной задачи требуется более одной стратегии поиска, причем каждый движок подходит для определенного типа рассуждений:
Vector → meaning and unstructured text
BM25 → exact lexical matching
Graph → relationships and multi-hop traversal
SQL → filters, numbers and aggregation
Задача перестала быть поиском информации и превратилась в выполнение федеративных запросов. Федерация порождает три более сложные проблемы: декомпозицию, маршрутизацию и сопоставление.
Декомпозиция
Системе необходимо разделить вопрос на натуральном языке на элементы, которые она может обработать:
1. Resolve NVIDIA as a Company
2. Find its strategic partners
3. Find ETFs holding those companies
4. Filter AUM > $1B
5. Retrieve the latest research reports
6. Identify positive views
Маршрутизация
Каждый узел должен обращаться к источнику, который является для него авторитетным:
relationships → Graph
AUM → SQL
research view → Vector Search
Одного подключения к базам данных недостаточно. Система должна знать, какой источник отвечает за какую часть.
Сопоставление
Это часто самая сложная часть. Пользователь вводит AUM, тогда как в базе данных могут быть такие поля:
NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET
Какая из них является управляемым понятием? Аналогично, ETF может представляться как fund:ETF в графе, dim_fund.fund_id в SQL и metadata.product_id в векторном индексе. Системе необходим мост между бизнес-терминологией и физическими схемами. Это называется привязкой схемы к реальности, и без неё LLM может генерировать вполне правдоподобный SQL для столбцов, которых на самом деле нет.
Семантический слой
Семантический слой находится между тем, что имеют в виду люди, и способом хранения данных. Вместо того чтобы показывать LLM сотни необработанных таблиц и свойств, вы предоставляете концепции:
Company
Strategic Partner
ETF
Constituent
Assets Under Management
Research Report
и придать смысл каждому из них:
Assets Under Management
├─ business definition
├─ currency / unit
├─ effective date
├─ authoritative source
└─ physical column
Таким образом, этот слой может напрямую участвовать в жизненном цикле запросов. Это меняет предназначение онтологии: она перестаёт быть статической документацией и превращается в исполняемый контекст для системы ИИ.
Как это может быть организовано
Для системы, сочетающей реляционную базу данных, граф знаний и векторный поиск, слой может быть структурирован следующим образом:
semantic_layer/
├── ontology/
│ ├── tbox.ttl # classes and relationships
│ └── vocabulary.yaml # business terms and synonyms
├── schemas/
│ ├── rdb.yaml # tables, columns, types
│ ├── graph.yaml # entities, predicates, graph paths
│ └── vector.yaml # indexes and document metadata
├── semantics/
│ ├── metrics.yaml # governed metrics such as AUM
│ ├── mappings.yaml # concept → physical source mapping
│ └── relationships.yaml # cross-domain relationships
├── query/
│ ├── routing.yaml # Graph vs SQL vs Vector routing
│ └── examples.yaml # representative query plans
└── validation/
└── rules.yaml # allowed fields and business rules
В такой структуре tbox.ttl — это место, где объявляются классы вроде Company и ETF, а также связь HAS_STRATEGIC_PARTNER между ними, в то время как rdb.yaml описывает сами таблицы и столбцы. mappings.yaml связывает понятие управляемых активов со столбцом fund_metrics.net_asset_amt. Наконец, routing.yaml позволяет системе планирования решать, следует ли шаг направлять в граф, в SQL или в векторный поиск.
Конкретные файлы зависят от реализации. Важно явно описывать смысл, физические соответствия и допустимые пути выполнения, вместо того чтобы заставлять большую языковую модель заново их находить при каждом запросе. Четыре задачи получают прямую выгоду:
- Разрешение неоднозначностей: компания и продукты с похожими названиями принадлежат к разным классам сущностей.
fund_metrics.net_asset_amt.Вот почему семантическая инженерия охватывает гораздо больше, чем просто создание онтологии. Цель заключается в том, чтобы сделать бизнес-значения пригодными к использованию во время выполнения программы с помощью общего словаря, онтологии, определений метрик, отношений, сопоставлений схем, бизнес-правил, исходных метаданных и проверок корректности. С такой точки зрения семантический слой больше похож на этап компиляции для корпоративных данных, чем на глоссарий.
Многие современные конструкции агентов выглядят именно так:
User → LLM → Tools
LLM получает описания инструментов и решает, как им дать название. Семантическая архитектура может иметь более строгие ограничения:
User
↓
Semantic Resolution
↓
Logical Query Plan
↓
Validated Execution
↓
Evidence
↓
LLM
Модели не нужно самостоятельно определять структуру каждой таблицы, показателя, графика, предиката и бизнес-правила. Она работает в ограниченной семантической среде. Цель заключается в создании лучшего интерфейса между моделью и корпоративными данными, а не просто в создании более крупной модели.
Почему важен открытый формат обмена
Сами семантические определения склонны к фрагментации. Компания может определять чистый доход отдельно в своей платформе для хранения данных, инструменте аналитики, каталоге, приложении для анализа данных и ИИ-агенте, и со временем эти определения начинают отклоняться друг от друга.
Проект Open Semantic Interchange (OSI) был создан для решения этой проблемы. В июне 2026 года он вошел в Apache Incubator и продолжает существовать как Apache Ossie (на стадии инкубации). Его цель — предоставить системам нейтральный способ обмена семантическими метаданными. Основные спецификации написаны на YAML и охватывают наборы данных, поля, связи, показатели и контекст ИИ. Упрощенная версия модели выглядит следующим образом:
version: "0.2.0.dev0"
semantic_model:
- name: investment_products
datasets:
- name: etf
source: analytics.dim_etf
fields:
- name: aum
datatype: Decimal
ai_context:
synonyms: ["assets under management", "net assets"]
metrics:
- name: total_aum
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(etf.aum)
Синтаксис имеет мало значения. Важно то, что aum получает одно определение, включающее его физическое происхождение, тип данных, логику измерения и синонимы для использования в ИИ, причем это определение передается в виде портабельных метаданных, а не переписывается в каждом инструменте.
┌→ BI
├→ Analytics
Semantic Model ───┼→ AI Agents
├→ Data Catalogs
└→ Data Applications
Каталог может отображать определение и происхождение AUM, а ИИ-агент может читать те же метаданные, чтобы правильно заполнить соответствующее поле для показателя активов, находящихся под управлением, вместо того чтобы делать предположения на основе сырых схем.
Кроме того, Ossie проверяет модели согласно JSON Schema, поддерживает несколько диалектов выражений и определяет модель конвертера для перевода между форматами поставщиков. В планах — добавление более подробных метрик, возможности композиции, интеграция с каталогами, улучшение семантики отношений и представления онтологии.
Направление развития в области онтологии особенно интересно для ИИ, поскольку одни лишь метрики и измерения не позволяют агенту узнать такие факты:
Customer is an Organization
Company HAS_SUBSIDIARY Company
Company OWNS_PRODUCT Product
Document DESCRIBES Entity
Если семантические модели и более сложные онтологии сольются, системы ИИ смогут получать переносимое бизнес-значение, а не только переносимые схемы.
Возвращаемся к вопросу о NVIDIA
Система семантических запросов может пошагово обрабатывать исходный вопрос, причем каждое решение основано на явных метаданных. Без семантического слоя большие языковые модели вынуждены на каждом этапе выводить значение, источник, схему и взаимосвязи, и одно неверное предположение может нарушить всю цепочку обработки.
Более широкие изменения
Корпоративные системы ИИ прошли через несколько этапов развития:
LLM + Prompt
↓
LLM + RAG
↓
LLM + Tools
↓
LLM + Federated Data
↓
Semantic Layer + Federated Execution + LLM
Механизм поиска определяет, какие документы кажутся релевантными. Графы показывают, как связаны между собой сущности. SQL указывает, какие записи соответствуют точным условиям. Семантический слой занимается первым вопросом: как преобразовать этот вопрос в термины нашей базы данных?
Системы будут продолжать получать новые базы данных, графы, документы, API и инструменты, и одного только подключения большего объема данных будет недостаточно. Необходимо также связать между собой их значение. Корпоративный ИИ, возможно, будет в меньшей степени полагаться на предоставление модели дополнительных данных и в большей степени — на формирование у нее четкого понимания того, что означают эти данные.