NVIDIA выпустила открытый фреймворк, который учит агентов понимать смысл данных
Nvidia – open-source auto-ontology
Auto Ontology — открытая Python-библиотека под лицензией Apache 2.0, которая строит поверх корпоративных метаданных семантический слой: генерирует онтологии, примиряет противоречивые определения метрик между системами и отдаёт контекст любому агенту через MCP, CLI и API. Запросы на естественном языке превращаются в SQL и проверяются по сертифицированным определениям с указанием происхождения данных. Внутри — Next.js, FastAPI, Postgres с pgvector и инференс на NVIDIA NIM.
Агенты могут извлекать документы и обращаться к базам данных, но надёжность сдерживает агентную аналитику: метрика выручки, полученная быстрее, ничего не стоит, если число неверное.
- dstu
Это вполне может быть очень полезно, но Claude меня испортил, и у меня теперь внутренняя реакция на слово «gates» в первом предложении, дальше я не смог. Если инструмент стоит того, чтобы его создавать и делиться им, разве не стоит также написать краткое описание того, чего он должен достичь, своими словами?
- gavinray
Я хочу попробовать объяснить, так как, похоже, многие здесь не поняли этот ужасно написанный README.
«Auto Ontology» — это довольно неудачное название.
Вот в чём проблема:
Данные вашей компании разбросаны по базам данных разных типов. Люди, принимающие решения, хотят задавать вопросы об этих данных.
Старый способ: они шли к аналитику данных и говорили: «Сделай мне отчёт о том-то и том-то», и работа аналитика состояла в том, чтобы подобрать правильную последовательность запросов и одноразовых скриптов для получения нужной информации.
С такой системой идея в том, что все ваши модели баз данных были проинтроспектированы и сохранены в центральном каталоге метаданных.
Когда задаётся вопрос вроде «Какие товары были самыми продаваемыми в мае?», каталог метаданных сообщает вам: «Товары хранятся в FOO_DB», а «Product_Sales хранятся в BAR DB», и вы идёте и извлекаете нужные данные из нужного места и выполняете любые необходимые вычисления в памяти.
Система предоставляет реализацию кода для:
- Интроспекции каждой из ваших БД
- Агрегации информации о моделях и метаданных в центральной виртуальной БД (VDB)
- Генерации SQL для конкретного диалекта из запросов на естественном языке и маршрутизации их в нужную БД для соответствующей таблицы
- Объединения результатов в памяти, когда запрос на естественном языке требует нескольких источников данных
- Обработки правильных разрешений и т.д.
ХОРОШАЯ система для этого также интегрируется с вашими внешними источниками API (OpenAPI, GraphQL, gRPC и т.д.), а также с документацией sou […]
- smithclay
Удивлён, что здесь не упомянули https://github.com/ucbepic/DataAgentBench: бенчмаркинг агентов данных, которым нужно запрашивать данные из нескольких источников, — это фокус некоторых исследований в UC Berkeley — на таблицу лидеров стоит взглянуть, чтобы увидеть, как различные закрытые и открытые реализации строят онтологии ... хотелось бы посмотреть, как подход Nvidia выглядит на их фоне.
- grey-area
Чиним ненадёжных агентов, добавляя ещё больше ненадёжных агентов. Жаль, что мы не можем ничего сделать с тенденцией LLM придавать больше веса своим весам, чем данным, которые они анализируют.
Полагаю, всё сводится к тому, что у них нет чёткого разделения между данными, которые они узнали о мире, инструкциями и анализируемыми данными.
Вы можете попросить их рассматривать только 5 фактов перед ними, но они не будут этого делать и не могут.
- fnordpiglet
Мне трудно понять, почему это лучше, чем OWL/RDF и SparQL. Учитывая широту и глубину знаний о семантической паутине в корпусе, они проделывают потрясающую работу, обнаруживая хорошо зарекомендовавшие себя онтологии, строя новые на представленных данных и запрашивая их с помощью sparql. На самом деле лучше, чем почти всё, что я видел. Какая ирония, что семантическая паутина после стольких лет, вероятно, найдёт реальное применение — фактически своё первоначальное.
- mirekrusin
Я всё ещё предпочитаю свой собственный, простой и более функциональный язык CAVE [0]
- HexDecOctBin
У меня вопрос к людям, разбирающимся и в LLM, и в GOFAI: почему мы не можем использовать LLM, чтобы написать столько символьных правил, сколько нужно для соответствия данным, сохраняя при этом набор правил доступным для проверки и сопровождения?
- barrrrald
Я потратил карьеру на работу с данными и онтологиями и не смог понять этот readme, а диаграмма только всё запутывает.