Oracle-розширене покоління: з’єднання ШІ з перевіреними даними в реальному часі

У співпраці між Kamu та Brian ми раді представити нову техніку для підключення агентів на основі великих мовних моделей (LLM) до перевірених даних, яку ми називаємо Oracle-Augmented Generation.

Ви можете знайти швидкий огляд цієї техніки в цьому відео:

У цьому пості ми коротко розглянемо ситуацію, а потім детальніше зануримось у технічні та реалізаційні деталі.

Виклик фактичних даних у LLM

Великі мовні моделі (LLM) стали надзвичайно потужними інструментами для розмірковування та автоматизації. Навчені на великих обсягах даних, вони покладаються на узагальнення для вилучення понять, знаходження правил і патернів, а також для виведення зв'язків між ними.

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

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

Retrieval-Augmented Generation

Для вирішення цієї проблеми багато AI систем використовують Retrieval-Augmented Generation (RAG), поєднуючи LLM з векторними базами даних для отримання контекстуально релевантної інформації під час запиту.

Retrieval-Augmented Generation

Хоча цей підхід покращує фактичність і актуальність відповідей, він має суттєві недоліки:

• Застарілість і надійність джерел — основні компанії LLM використовують RAG здебільшого для пошуку релевантних веб-сторінок, багато з яких можуть містити застарілу або ненадійну інформацію. Хоча використовуються різні механізми ранжування для вибору кращих результатів, важко уявити сталий підхід до призначення та підтримки таких рейтингів на глобальному рівні.
• Складні умови запитів — RAG найкраще працює, коли необхідна інформація вже існує у бажаній формі, яку можна легко обробити за допомогою LLM. Але кількість запитів з нетривіальними умовами (наприклад, обмеження географічно чи за часом) настільки велика, що ми не можемо очікувати, що для кожного з них існує веб-сторінка — відповідь на запит може вимагати нетривіальних обчислень над великою кількістю даних, які повинні бути виконані унікально для цього користувача.
• Непрозорість вибору даних і централізований контроль — Оператор RAG має повний контроль над тим, які джерела включати в результати пошуку, а які ні, що викликає занепокоєння щодо прозорості та потенційних упереджень. Пропрієтарні канали збору даних, побудовані компаніями LLM для покращення навчання моделей і RAG, також мають негативний ефект, концентруючи тривожну кількість влади в дуже небагатьох руках.

Представлення Oracle-Augmented Generation

Ми пропонуємо нову техніку під назвою Oracle-Augmented Generation (OAG), яка поєднує агента AI з перевіреною аналітичною системою обробки даних, яка працює з набором надійних джерел даних.

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

На високому рівні OAG проходить через 4 етапи:

1. Збір контексту — де в найпростішій формі система Oracle запитується на надання топ N найбільш релевантних наборів даних до запиту користувача
   2.
   Генерація запитів — на цьому етапі LLM запитується, щоб використовувати метадані набору даних для генерації запиту (наприклад, SQL), який обчислює дані, що можуть відповісти на запитання
2. Виконання запиту — на цьому етапі Oracle виконує запит і повертає перевірений результат
3. Генерація відповіді — на цьому етапі LLM запитується, щоб інтерпретувати дані з результату запиту для користувача

Діаграма послідовності OAG

Ключова відмінність від типових підходів "Text-to-SQL" полягає в вимозі для oracle надавати криптографічні докази на етапах збору контексту та виконання запиту.

Приклад взаємодії

Використовуючи агента LLM Brian та Kamu Node як oracle, давайте подивимося, як може виглядати одна взаємодія користувача з OAG.

Запит користувача: Який був загальний обсяг торгівлі USDC з 10 жовтня по 20 жовтня 2024 року?

Збір контексту: Агента Brian передає запит до API пошуку Kamu Node без змін, і Kamu виконує семантичний пошук для знаходження найбільш релевантних наборів даних, повертаючи такі набори даних як:

• kamu/io.codex.tokens.olhcv — дані DeFi торгівлі, найбільш релевантні для нас
• kamu/com.cryptocompare.ohlcv.eth-usd — набір даних про криптовалютну біржу, що містить згадки про обсяги торгів
• kamu/com.defillama.tokens.prices — набір даних про ціни криптокоштів, що містить згадки про USDC

Агент Brian отримує багато метаданих про ці набори даних від Kamu, включаючи їхні схеми, описи стовпців, файли readme та популярні запити.

Хоча Brian природно надає пріоритет наборам даних DeFi, OAG в Kamu є доменно-агностичним.
Генерація запитів: Агент Brian передає вищезазначений контекст до основної мовної моделі, запитуючи її згенерувати SQL-запит, сумісний з Postgres, який відповідає на запит користувача.

Модель повертає:

select  
 sum(volume) as total_volume  
from 'kamu/io.codex.tokens.olhcv'  
where  
 symbol = 'USDC'  
 and event_time >= '2024-10-10'  
 and event_time < '2024-10-21'

Виконання запиту: Цей SQL-запит надсилається до кінцевої точки запиту Kamu і повертає відповідь у форматі JSON:

{  
 "input": {  
 "query": "select\n sum(volume) as total_volume\nfrom 'kamu/io.codex.tokens.olhcv'\nwhere ...",  
 "queryDialect": "SqlDataFusion",  
 "dataFormat": "JsonAoS",  
 "include": ["Input", "Proof"],  
 "datasets": [  
 {  
 "id": "did:odf:fed011b209e776577c1688affdab1db2d3bda4822852dcaf9d59d108df8b441544938",  
 "alias": "kamu/io.codex.tokens.olhcv",  
 "blockHash": "f16206ead4be7fd3c3efbaa3de1c15e303e2ce9f6c2bc605f11e033e83a0206573722"  
 }  
 ],  
 "skip": 0,  
 "limit": 100  
 },  
 "output": {  
 "data": [{ "total_volume": 4039963082.961011 }],  
 "dataFormat": "JsonAoS"  
 },  
 "subQueries": [],  
 "commitment": {  
 "inputHash": "f16207ad1730665365efa3acb77ea33a169e49b292c03a13ae01d2718b7d958afb46b",  
 "outputHash": "f1620510c1a4b28136b6f79c971e86c37e9b6ea77833ad511515c7a4e0133e47113b6",  
 "subQueriesHash": "f1620ca4510738395af1429224dd785675309c344b2b549632e20275c69b15ed1d210"  
 },  
 "proof": {  
 "type": "Ed25519Signature2020",  
 "verificationMethod": "did:key:z6MkkhJQPHpA41mTPLFgBeygnjeeADUSwuGDoF9pbGQsfwZp",  
 "proofValue": "uLaanvQHkx5w6yOcLmI-VH1IquEFTMjmlJRqqgd1Na1qYYcb6CIpxERLjtlYRasqiIwL2hg6NAEHMoNz68xwSBQ"  
 }  
}

Частина "output" відповіді — це фактичний результат запиту, в той час як решта полів формують криптографічне підтвердження цього запиту.

У цьому прикладі ми маємо підтвердження через відтворюваність, де конкретний вузол Kamu (ідентифікований як did:key:z6..fwZp W3C DID) підтверджує, що правильно виконав запит на наборі даних did:odf:fe..4938 на певному знімку стану (блоці) f1..3722.

Інші типи доказів, зокрема нульові знання, також можуть бути використані в OAG для досягнення бажаних ефектів.

Для детального огляду механізму доказів запиту та його властивостей ознайомтесь з нашою документацією.

Генерація відповіді: LLM запитується, щоб інтерпретувати результат для користувача на основі:

• Початкового запиту користувача
• Контексту з метаданими про набори даних
• Згенерованого SQL запиту
• Даних відповіді (в нашому випадку тільки [{ "total_volume": 4039963082.961011 }])

LLM повертає кінцеву відповідь: Загальний обсяг торгівлі USDC з 10 жовтня по 20 жовтня 2024 року склав приблизно 4 039 963 083 доларів.

Як кінцева відповідь, так і криптографічне підтвердження зберігаються в історії чату.

Підтвердження збережено разом з історією чату агента

Гіперпосилання, яке Brian додає до відповіді, дозволяє користувачам швидко декодувати підтвердження і перевірити запит в веб-інтерфейсі Kamu.

Аудит підтвердження в веб-інтерфейсі Kamu

Користувач може побачити:

• Який SQL-запит був виконаний
• Які набори даних і які знімки їхнього стану були використані при обчисленні
• Дані результату, які були відтворені ідентично минулому запиту
• Статус перевірки підтвердження, що пов'язує відповідь з одним або кількома вузлами, які виконали запит

Здатність Kamu забезпечити нескінченну відтворюваність запитів навіть для швидко змінюваних наборів даних залежить від структурованої даними системи протоколу Open Data Fabric.
Ви можете знайти більше деталей у специфікації ODF.

Поточні обмеження

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

OAG vs. RAG

У той час як у RAG модель повинна безпосередньо вивести відповідь з неструктурованих даних контексту, у OAG модель генерує код запиту і делегує виконання аналітичній системі. Таким чином, OAG може працювати з набагато більшими обсягами даних, які в іншому випадку ніколи не помістяться в контекст RAG. Це також значно зменшує ймовірність галюцинацій, оскільки більшість обчислень виконується детермінованою системою.

Коли йдеться про структуровані дані, OAG може працювати з значно ширшим діапазоном запитань, включаючи:

• Запитання про конкретний момент часу та діапазони часу
• Складні фільтри
• Статистичні агрегації (медіани, квартилі, OLAP-куби тощо)

У RAG часто важко зрозуміти, чи зробила LLM правильний висновок на основі даних контексту. Перевірка цього потребує, щоб людина самостійно проаналізувала весь контекст, що нівелює мету. OAG пропонує кращу аудитованість і походження. Навіть якщо відповідь вимагає обробки терабайт даних — згенерований запит можна легко перевірити та зрозуміти. Система oracle також може надати способи перевірки, чи використовуються надійні джерела даних. Оскільки запит зазвичай агрегує багато точок даних у зручний статистичний підсумок або графік — людям набагато легше перевірити, чи є інтерпретація результату LLM правильною.

В OAG докази вводять відповідальність. Доказ запиту, описаний вище, дозволяє користувачам тримати постачальників даних і сторони, які виконали запит, вічно відповідальними за правильність результатів. Вони можуть виявити будь-які спроби змінити чи утримати дані і таким чином стати основою для покарання зловмисних учасників. Лаконічні криптографічні докази, надані Kamu, залишаються невеликими навіть коли результат включає мільйони точок даних і тому можуть дешево зберігатися разом з історією чату відповідей агентів.

OAG і Kamu для перевірки ланцюга постачання даних

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

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

Перевірка ланцюга постачання даних

Дані з авторитетних видавців або блокчейн можуть оброблятися кількома третіми сторонами, очищатися і комбінуватися в більш високого рівня корисні набори даних, з якими агенти ШІ природно надаватимуть перевагу при пошуку відповідей.
Але завдяки Kamu, доказ для одного запиту автоматично включатиме докази походження для всього ланцюга постачання даних, незалежно від того, скільки разів дані пройшли через різні руки!

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

Роль OAG в ІТ і економіці даних

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

На жаль, ми бачимо велику проблему в тому, як великі компанії ШІ застосовують RAG сьогодні. Коли LLM надають нам необхідні результати, багато користувачів можуть більше не відчувати потреби відкривати веб-сторінки, з яких RAG отримував інформацію. Це означає, що вебсайти, з яких отримані дані для RAG, починають втрачати трафік і дохід від реклами. Ми скоро можемо побачити, як брокери даних забороняють агентів ШІ на своїх вебсайтах. Це може, в свою чергу, змусити великі компанії LLM використовувати свої майже безмежні кошти для інвестування у власні пропрієтарні канали даних. Оскільки законодавство щодо ШІ та прав інтелектуальної власності все ще перебуває в підвішеному стані, така міра централізації буде катастрофічною.

Ми раніше показували [1][2], як децентралізована система, така як Kamu, пропонує кращу основу для економіки даних:

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

Тепер з OAG ми розширюємо ці властивості для економіки ШІ.

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

Розподіл винагород на основі походження

Походження надає нам кількісний спосіб розподілу доходу вгору до кожного учасника ланцюга постачання даних:

• Постачальники даних
• Постачальники зберігання та обчислень
• І глобальна спільнота, що будує і підтримує канали обробки даних.

Майбутні розробки

Перший прототип OAG перевершив наші очікування, але у нас є багато інших ідей для випробування:

• Агентний експлораційний аналіз даних — щоб допомогти з однією з найбільших проблем сьогодення, коли LLM іноді важко правильно фільтрувати дані без достатньої кількості підказок щодо конкретних значень у даних, ми хочемо, щоб агент міг вирішити, коли йому не вистачає інформації для формування запиту і потрібно виконати проміжні кроки для дослідження вмісту кандидатних наборів даних.
• Прогресивне розширення контексту через знання/семантичну граф — щоб допомогти LLM генерувати правильні JOIN між наборами даних з різних доменів, ми хочемо розширити метадані семантичними анотаціями (наприклад,
  RDF).
• Нечіткий запит — де SQL-шар на стороні Kamu може виявити і автоматично виправити типові помилки в запитах
• Тонке налаштування з OAG-в-процесі — оскільки ми вважаємо, що найкращі результати можуть бути досягнуті, коли LLM навчається разом з оракулом і вчиться використовувати його для досягнення найкращих результатів.

Дякуємо за прочитане! Будь ласка, спробуйте агента ШІ Brian і дайте нам знати вашу думку на Discord!

Перекладено з: Oracle-Augmented Generation: Connecting AI to Real-Time Verifiable Data