Чаму RAG недастаткова: семантычны пласт для графавых, SQL- і вектарных запытаў

Мадэлі мовы спрабавілі зробіць простым выражэнне корпаратывых запітанняў простымі словамі. Адпаведна адпаведзь ўжо не тое ж самае, што розумеўце значэнне запітання ў разных сістэмах дадзенаў. Возьмімо такое:

Уявіце аналітыка, які запытае: калія ETF-і володзяюць компаніямі, якія стратэгічна супрацоўнуюць з NVIDIA, каліруюць падараджэнняяў у розмерзе ад мільярда долераў і атрымуюць позытывныя адгукі ў недзеўніх даследжэннях?

Гэта выглядае як адна запытанне, але на самай працэ патрабуеяцца тры відменныя задачы:

• NVIDIA, стратэгічны партнер, ETF-і: аналізацыя звязкаў у графе.
• Актываўны капітал падараджэнняяў вышы ў 1 мільярд долераў: точная чысловая фарматаванне.
• Позытывныя недзеўнія даследжэння: аналізацыя неструктураванага тэксту.

Падае глыбэйшая проблема. Што значыць AUM у асновнай модэлі дадзейнаў, і які істочнік ёсць аўтарытэтны для гэтага? Ёнколі сістэма можа правільна адпаведзець, яй неабходна зрозумець значэнне дадзейнаў, а не толькі сабе дадзейны. Семантычная інжынерыя спрамована на заполненне гэтага прыему.

Дзе заканчваецца RAG

Тыповая схема RAG адзysкае рэлевантныя фрагменты і дазваляе модэлю адпаведзець на пытанні на ўснове іх. Гэта чудова, калі задача — знайсці рэлевантны тэкст і адпаведзець на пытанні на ўснове яго. У корпаратыўных пытаннях часта трэбуецца больш, чым проста сяродзіцтва, і чыстая вектарная адзысковае методыка зазнае нядач у чатыро відзначальныя способы.

Фрагментаваная адзысковае

Уявіце інструкцыю да продукту, разрэзаную на тры часткі:

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

Kalikie еў тэканыя концепцыя? Аналогуза, ETF маге быць fund:ETF у графі, dim_fund.fund_id у SQL і metadata.product_id у векторным індэксе. Сістэма павярбаець мосты між бізнесовым слоўваром і фізычныяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя

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 чы да вектарнага пошуку.

Конкрэтныя файлы залежаць ад рэалізацыі. Гэта, што важна — чыткай напісаць значэння, фізычныя супяжнення і правільныя шляхі выканання, замест таго каб LLM зноў аднаходзіў іх за кожны запіт. Чатыры задачы выгадваюць безпосерэднія перавагі:

• Разгледжэнне неоднозначнасцяў: компанія і продукты з аднаковым называм належаць да разных класаў аб’ектаў.

Маршрутызацыя: адносіны партнераў і ўтрымальнікаў выкалічваюцца з графа, тады як AUM выкалічваецца з складу.

Узгадка схемы: показнік Assets Under Management ператвараецца на fund_metrics.net_asset_amt.

Мнагаэтапныя выводы: NVIDIA → стратэгічны партнер → ETF.

Самэй таму семантычная інжынерыя ўжо шырэй, чым проста стварэнне онтологіі. Мета — зробіць бізнес-значэнні прыдатнымі для выкарыстоўвання пад час працы за дапамогою спакойнага слоўніку, онтологіі, апісаў показнікаў, адносінаў, схемных карэлей, бізнес-правіл, метадаў вучынніка і перакананняў у правядзімасці. Калі адносіцца да гэтага так, семантычны слой больш нагадвае стадыю компіляцыі для корпаратыўных дадзенняў, чым проста глосарый.

З слоя да часу выканання

Большасць сучасных дызайнаў агентаў выглядае так:

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 ёсць адна вызначэння, якая включае яго фізычны джэрэл, тып дадзеных, логіку метрык і сынонімы для AI, прычаму гэтае вызначэння перавозіцца як портатыўныя метаданы, а не перапісваецца ў кожным з інструментаў.

┌→ 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 должна сама выважваць значэння, кантэкст, схему і асоціяцыі на кожным кроку, і адна неправільная прыпуск можа зламаць весь ланцюг.

Большыя змены

Корпаратывныя сістэмы ШЫ праходзілі праз розныя этапы:

LLM + Prompt
     ↓
LLM + RAG
     ↓
LLM + Tools
     ↓
LLM + Federated Data
     ↓
Semantic Layer + Federated Execution + LLM

Сістэма адаптавання выбірае дакументы, якія здаюцца рэлевантнымі. Граф паказвае, як выступаюць у зв’язку разныя элементы. SQL вказывае, якія запісі падпадаюць під точныя умовы. Семантычны слой разглядае галоўны вопыт: як пераклаць гэты вопыт на слоўнік нашых дадзеных?

Сістэмы будуць прыбываць у колькасці баз дадзеных, графаў, дакументаў, API і інструментаў, і проста падключэнне большых кантэйнераў дадзеных недастатнья. Неабходна таксама падключыць значэнні. Корпоратыўскія AI-сістэмы можаць менш паслугоўвацца дадатковымі дадзеннямі для модэляў і больш паслугоўвацца чыткым розуменням таго, што означаюць гэтыя дадзенні.