Чому 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
Модель не змушена самостійно розбиратися з кожною таблицею, метрикою, графічним предикатом та бізнес-правилом. Вона працює в межах обмеженого семантичного середовища. Метою є створення кращого інтерфейсу між моделлю та корпоративними даними, а не просто розробка більшої моделі.
Чому важливий відкритий формат обміну
Самі семантичні визначення схильні до фрагментації. Компанія може визначати чистий дохід окремо у своїй платформі даних, інструменті аналітики, каталозі, додатку для аналітики та AI-агенті, і з часом ці визначення починають відрізнятися одне від одного.
Проєкт Open Semantic Interchange (OSI) створений для вирішення цієї проблеми. Цей проєкт приєднався до Apache Incubator у червні 2026 року та продовжує існувати як Apache Ossie (у стадії інкубації). Його метою є надання системам нейтрального способу обміну семантичними метаданими. Основна специфікація написана на YAML та охоплює набори даних, поля, взаємозв’язки, метрики та контекст AI. Скорочена версія моделі виглядає так:
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 та інструменти, і лише підключення більшої кількості даних недостатньо. Необхідно також підключити значення цих даних. Корпоративний ШІ може все менше покладатися на надання моделі додаткових даних та більше — на створення у неї чіткого розуміння того, що означають ці дані.