- Дата публикации
AkasicDB: корейские учёные собрали векторную, графовую и SQL-базу в одном ядре и сократили «галлюцинации» ИИ до 78%
Что нового
KAIST и GraphAI показали AkasicDB — систему, которая объединяет три типа баз данных в одном ядре:
- векторную (для семантического поиска);
- графовую (для связей между объектами);
- реляционную SQL-базу (для таблиц и фильтров по параметрам).
На основе AkasicDB исследователи собрали метод Omni RAG — альтернативу классическому RAG, где все операции по смыслу, связям и структуре данных выполняются в одном запросе и одном плане выполнения.
Ключевые цифры из тестов:
- сложные запросы, которые раньше занимали до 21,3 секунды, AkasicDB обрабатывает менее чем за 1 секунду;
- точность ответов корпоративных ИИ-агентов выросла до 78% по сравнению с традиционными RAG-системами;
- за счёт единого ядра сокращается объём промежуточных данных и нагрузка на языковую модель.
Цель AkasicDB — уменьшить «галлюцинации» ИИ в корпоративных сценариях, где данные разбросаны по документам, таблицам и графам связей.
Как это работает
Классический RAG выглядит так:
- Текстовые документы превращаются в векторы.
- По запросу пользователя система ищет ближайшие векторы и подтягивает релевантные документы.
- Языковая модель (например, GPT-4o или Claude 3) формирует ответ на основе найденных текстов.
Этот подход хорошо работает для неструктурированных текстов. Но он почти не умеет одновременно учитывать:
- временные условия (например, «только за 2023 год»);
- категории и типы объектов (типы контрактов, статусы сделок);
- сложные связи между сущностями (кто с кем связан, какие контракты затронули какие поставки).
AkasicDB решает это за счёт единого ядра, которое хранит данные сразу в трёх моделях:
- векторная модель — отвечает за семантический поиск по текстам;
- графовая модель — хранит связи между сущностями: компаниями, продуктами, людьми, контрактами;
- реляционная модель — классические таблицы с полями, индексами и фильтрами по параметрам и времени.
Omni RAG строит для запроса пользователя единый вычислительный план:
- семантический поиск выполняется по векторным представлениям;
- переходы по связям — по графу;
- фильтрация по датам, типам, статусам — по реляционным таблицам.
Вместо нескольких разрозненных запросов к разным базам AkasicDB выполняет всё как один SQL/GQL-запрос. Система планирует его выполнение внутри себя и минимизирует передачу промежуточных данных между подсистемами.
Пример из корпоративной практики:
Найти пункты контрактов компании за определённый период и проанализировать, как они связаны с проблемами поставок.
Для этого нужно одновременно:
- сделать семантический поиск по текстам контрактов;
- пройти по графу связей между контрактами, поставщиками, логистическими событиями;
- отфильтровать результаты по датам, типам контрактов и статусам.
Классическая архитектура RAG делает это несколькими запросами к разным базам и склеивает результаты в приложении. AkasicDB делает это одним запросом внутри ядра, а языковая модель получает уже «собранный» контекст.
Это уменьшает:
- задержки ответа (нет долгой агрегации на уровне приложения);
- нагрузку на LLM (меньше «шума» и несогласованных данных в промпте);
- вероятность «галлюцинаций», потому что модель опирается на более точный и согласованный набор фактов.
Что это значит для вас
AkasicDB и Omni RAG интересны, если вы:
- строите корпоративных ИИ-агентов поверх внутренних данных;
- работаете с юридическими документами, контрактами, отчётами, которые связаны с транзакционными данными в БД;
- хотите уменьшить количество ошибок и «галлюцинаций» в ответах ИИ.
Где AkasicDB особенно полезна:
-
Юридические и контрактные системы
Поиск и анализ пунктов договоров с учётом:- дат действия;
- типов контрактов;
- связей с поставщиками, проектами, судебными спорами.
-
Финансы и риск-менеджмент
Когда нужно одновременно учитывать:- текстовые описания сделок и отчётов;
- структурированные транзакции и лимиты;
- граф связей между контрагентами и продуктами.
-
Промышленность и логистика
Анализ проблем с поставками, гарантийных случаев, инцидентов безопасности:- тексты отчётов и заявок;
- временные ряды и статусы;
- связи между поставщиками, партиями и событиями.
-
Научные и R&D-проекты
Когда нужно связать:- публикации и отчёты;
- экспериментальные данные в таблицах;
- графы цитирований и коавторства.
Где AkasicDB вряд ли нужна:
- простые чат-боты для сайта или поддержки без сложной логики данных;
- проекты, где у вас только неструктурированные тексты без таблиц и графа связей — там достаточно классического RAG на векторной базе;
- небольшие стартапы без серьёзной ИТ-инфраструктуры, где издержки внедрения сложной системы хранения не окупятся.
Если вы разрабатываете корпоративного ИИ-ассистента и уже столкнулись с тем, что LLM уверенно придумывает несуществующие факты, AkasicDB — пример того, как можно снизить эту проблему за счёт архитектуры данных, а не только «лучшей модели» или «другого промпта».
Информация о доступности AkasicDB как готового облачного сервиса или о коммерческой лицензии в описании разработки не приводится. Для российских компаний это означает стандартный сценарий: либо ждать коммерческого продукта, либо ориентироваться на публикации и прототипы и реализовывать похожий подход у себя.
Место на рынке
AkasicDB и Omni RAG конкурируют не с конкретной LLM (GPT-4o, Claude 3 и т.п.), а с подходами к работе с данными для этих моделей.
Сегодня популярный стек для корпоративного RAG выглядит так:
- отдельная векторная база (например, Milvus, Weaviate, pgvector);
- отдельная реляционная БД (PostgreSQL, MySQL, Oracle и т.п.);
- отдельный графовый движок (Neo4j, TigerGraph и другие);
- слой приложения, который сам координирует запросы ко всем этим системам.
AkasicDB предлагает другой путь: одно ядро вместо трёх разных систем. Прямых численных сравнений с конкретными конкурентами разработчики не приводят. Но в тестах на сложных запросах внутри их стенда:
- время ответа сократилось с до 21,3 секунды до менее 1 секунды;
- точность ответов ИИ-агента выросла до 78%.
Это не сравнение с GPT-4o или Claude 3, а сравнение архитектур: «классический RAG + несколько БД» против «Omni RAG + AkasicDB».
Где у подхода есть слабые места:
- повышенная сложность самой СУБД: одно ядро, три модели данных — это сложнее в разработке и, вероятно, в эксплуатации;
- миграция с уже существующей инфраструктуры (отдельный SQL, отдельный граф, отдельный векторный движок) потребует времени и ресурсов;
- нет публичных данных о стоимости лицензии, масштабируемости на продакшн-нагрузках и интеграции с популярными облаками.
Для крупных организаций с жёсткими требованиями к точности — оборона, финансы, промышленность, наука — AkasicDB показывает направление, куда движутся системы хранения для ИИ: не просто «векторный поиск поверх PDF», а единое ядро, которое понимает сразу смысл текста, структуру данных и связи между объектами.