Практичні нотатки: Понад RAG: чому системам ШІ потрібен семантичний шар

У цьому посібнику детально описано шлях від сировини до функціональної системи для проекту «Beyond RAG: Чому системам штучного інтелекту потрібен семантичний шар». Основна увага приділяється конкретним крокам виконання, чітким перевіркам та коду, який можна просто додати до репозиторію, не намагаючись здогадатися про його призначення. На етапі огляду необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись зрозуміти прихований стан системи. Краще використовувати невеликі, тестовані одиниці коду замість об’ємних скриптів. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну структуру обробки даних.

RAG є потужним інструментом — але він вирішує лише частину проблеми

Під час роботи над етапом «RAG Is Powerful But» спочатку складіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безпроблемного часткового виконання завдань. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко вирішує проблеми слабкого пошуку інформації.

1. Фрагментований пошук

Під час роботи над етапом 1 «Фрагментоване отримання даних» спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли система переходить від демо-режиму до спільних середовищ. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити якість отримання даних.

Chunk 1: Atlas Enterprise — vendor, category
Chunk 2: Pricing — base fee, usage fee
Chunk 3: Risks — lock-in, migration, data residency

2. Відсутність перетину взаємозв’язків

Під час роботи над другим етапом обробки без встановлення зв’язків спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність подальших змін у коді. Тримайте конфігурацію окремо від коду програми. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь граф. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко виправляє проблеми з недостатньою ефективністю пошуку. Під час роботи над другим етапом обробки без встановлення зв’язків спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність подальших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед величезними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.

NVIDIA
   ↓ HAS_STRATEGIC_PARTNER
Company
   ↓ HELD_BY
ETF

?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .

3. Неоднозначність ентитетів

Етап 3 «Неоднозначність ентитетів» працює найкраще, якщо його розглядати як вимірювану характеристику. Збережіть один ідеальний варіант транскрипції, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику часткової обробки даних від політики їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

NVIDIA     → Company
NVIDIA International  → Subsidiary
NVIDIA AI Enterprise    → Product

4. Відсутність точного числового фільтрування

Підхід 4 «Без точних числових показників» найкраще функціонує, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний результат, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних середовищ. Розділяйте політику часткової обробки даних та політику їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу, коли змінюються показники якості.

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

Картування

Під час роботи на етапі картування спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Перед налаштуванням запитів вимірюйте рівень точності на фіксованому наборі запитань. Часта зміна формулювань запитів рідко вирішує проблеми слабкої системи пошуку.

NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET

Переходьте до семантичного шару

Під час виконання етапу «Введення семантичного шару» спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успішне виконання та наслідки часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням промптів. Часта зміна промптів рідко допомагає покращити ефективність пошуку.

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

Етап «Від семантичного шару» функціонує найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику часткової обробки даних від політики їх отримання. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

User → LLM → Tools

User
 ↓
Semantic Resolution
 ↓
Logical Query Plan
 ↓
Validated Execution
 ↓
Evidence
 ↓
LLM

Етап «Чому відкритий семантичний обмін» функціонує найкраще, якщо його розглядати як вимірювану поверхню. Зафіксуйте один ідеальний зразок транскрипції, один випадок невдачі та примітку про скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних. Розділяйте політику часткової обробки даних та політику їх пошуку. Зміна однієї з них не повинна змушувати переписувати іншу, коли змінюються показники якості.

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)

┌→ BI
                  ├→ Analytics
Semantic Model ───┼→ AI Agents
                  ├→ Data Catalogs
                  └→ Data Applications

Customer is an Organization
Company HAS_SUBSIDIARY Company
Company OWNS_PRODUCT Product
Document DESCRIBES Entity

Об’єднання всього воєдино

Етап «Об’єднання всього» функціонує найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь граф. Розділяйте політику часткового оброблення даних від політики їх отримання. Зміна однієї з них не повинна змушувати переписувати іншу, коли змінюються показники якості. Етап «Об’єднання всього» функціонує найкраще, якщо його розглядати як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Віддавайте перевагу малим, тестованим одиницям перед величезними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.

Більша зміна

На етапі The Bigger Shift необхідно визначити вхідні дані, відповідальну особу за крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Призначте назви документам, визначте критерії успіху та не допускайте мовчазного часткового завершення. Наводьте цитати з тексту, які фактично лежать в основі відповіді. Без цитат оператори не зможуть відрізнити галюцинацію від проблем із індексуванням.

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

Чек-лист операцій

Етап чек-листу операцій працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи.

Документуйте як успішний, так і відновлювальний сценарії роботи. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої доробки.

Розділіть політику чанкування від політики отримання даних. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

Додайте тест на працездатність, який буде перевіряти критичний шлях у процесі інтеграційного тестування за допомогою фікстур, а не реальних платних API, коли це дозволяють бюджетні обмеження.

Віддавайте перевагу невеликим, тестованим одиницям перед складними скриптами. Якщо якийсь крок зазнає невдачі, причина має бути пов’язана з конкретною функцією, а не з усією заплутаною системою.

Розділіть політику чанкування від політики отримання даних. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

Перш ніж переходити на нову версію стеку, заморозьте існуючі версії, зафіксуйте ідеальний варіант виконання для критичного шляху та підтвердьте кроки для відкату. У спільних середовищах необхідні обмеження на кількість запитів, перевірки прав доступу та чіткий власник для зміни секретних даних. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.

Примітка до пакету 9b6fa92e9bf6: не включайте ключі постачальників у репозиторій, встановіть ліміт токенів на сеанс та зберігайте транскрипції поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.