Auto-Ontology: кто утвердил смысл слова "активный"?

Запрос «сколько у нас активных клиентов» допускает несколько правильных SQL-запросов с разными результатами. Для одной команды активность означает покупку, для другой достаточно входа в систему. Auto-Ontology от NVIDIA предлагает хранить такие определения в проверяемом слое между агентом и базой данных.

Это обзор документации и исходного кода на 4 ноября. Сервис не устанавливался, качество ответов не измерялось. Обещание меньшего числа ошибок остается заявлением проекта. Вопрос для пробного внедрения конкретнее: может ли второй аналитик объяснить выбранное определение и воспроизвести запрос?

Как появляется определение

Репозиторий описывает извлечение схем, профилирование столбцов и выборку значений. Затем сервис предлагает термины, связи таблиц и SQL-атрибуты. Контекст хранится в Postgres, векторный поиск использует pgvector. Выборка может содержать реальные значения: перед подключением нужно проверить, какие данные попадут в модель и где они сохранятся.

Термин связывает понятие бизнеса со столбцами. SQL-атрибут задает выражение для показателя, например маржи. Связи описывают соединения таблиц. Люди редактируют и сертифицируют черновик. Сама сертификация полезна только при содержательной проверке: учитывать ли возвраты, какую дату брать для периода, исключать ли отмененные счета.

Готовность и покрытие вопроса

Руководство MCP разделяет check_readiness и check_answerable. Первый проверяет наличие скомпилированного слоя и живого соединения. Каталог может пережить соединение, поэтому читаемый словарь еще не доказывает возможность выполнить SQL. Второй оценивает, покрывает ли слой вопрос. Ошибочное определение при этом может выглядеть подходящим.

ask_question выполняет цепочку text-to-SQL и возвращает ответ, SQL и строки отдельно. Выдача строк ограничена 100; поля row_count и truncated показывают ограничение. Нельзя принимать видимую часть списка за все данные. Анализ агрегата требует отдельной проверки самого запроса.

Кто получает доступ

Описание аутентификации относит разрешения к роли пользователя. API-токен действует от имени владельца; отдельный скрипт не получает новых прав. Срок действия по умолчанию не ограничен, поэтому его стоит выбрать сознательно. Создание и отзыв токенов требуют пользовательской сессии.

MCP-сервис обращается к публичному API Next.js. Документация описывает вход каждого пользователя и проверку непрозрачных токенов через UserInfo. Для испытания нужны две синтетические учетные записи с разными правами, разрешенный запрос, отказ и повтор после отзыва доступа. Этот обзор не подтверждает равнозначную защиту отдельно открытого внутреннего backend.

Где окажется пароль подключения

Документация соединений предупреждает: Vault выключен по умолчанию. Нужны все четыре переменные VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID, VAULT_SECRET_ID. Частичная настройка игнорируется с предупреждением, учетные данные сохраняются открытым текстом в Postgres.

Модуль Vault и сервис соединений подтверждают эту развилку в коде. Проверка должна установить фактический режим хранения на фиктивных учетных данных, включая резервные копии. Наличие одной переменной ничего не доказывает. Секреты нельзя включать в диагностический отчет.

Маленький проверяемый опыт

Подготовьте вымышленные счета: отмененный, возвращенный и обычный, плюс клиента с входом без покупок. Заранее запишите ожидаемые ответы для двух определений активности. Сохраните SQL, выбранный термин и отличие фактического результата от ожидаемого. Добавьте вопрос, для которого данных нет. Эти испытания предлагаются, а не выдаются за выполненные.

Apache-2.0 задает условия использования проекта. В проверенной ветке есть коммит от 3 ноября с изменением моделей по умолчанию. Это признак недавнего сопровождения, а не подтверждение готовности к рабочим данным. Начать разумно с одного показателя и базы только для чтения, расширяя доступ после проверки смысла, отказов и хранения секретов.