Auto-Ontology: хто затвердив значення слова "активний"?

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

Це огляд документації та коду на 4 листопада. Сервіс не встановлювався, точність відповідей не вимірювалася. Обіцянка меншої кількості помилок належить проєкту. Практичне питання для проби: чи може інший аналітик пояснити визначення та відтворити запит?

Від метаданих до показника

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

Термін пов'язує поняття бізнесу зі стовпцями. SQL-атрибут задає вираз показника, наприклад маржі. Зв'язки визначають з'єднання таблиць. Люди редагують і сертифікують чернетку. Така перевірка має охоплювати повернення, скасовані рахунки та дату звітного періоду. Позначка схвалення без цих рішень мало допомагає.

Дві перевірки перед відповіддю

Посібник MCP розрізняє check_readiness і check_answerable. Перша перевірка встановлює наявність скомпільованого шару та живого з'єднання. Каталог може залишитися після втрати з'єднання. Друга оцінює, чи покриває шар питання; вона не доводить правильність самого визначення.

ask_question виконує text-to-SQL і повертає відповідь, SQL та рядки окремо. Видача рядків обмежена 100, а row_count і truncated повідомляють про обмеження. Видиму частину списку не можна вважати повним результатом. Агрегований показник потребує перевірки виразу і фільтрів.

Права належать користувачу

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

MCP-сервіс звертається до публічного API Next.js. Посібник описує індивідуальний вхід і перевірку непрозорого токена через UserInfo. Запропонований тест має використати дві вигадані облікові записи з різними правами, дозволений запит, відмову та повтор після відкликання доступу. Огляд не підтверджує однаковий захист окремо відкритого внутрішнього backend.

Часткова конфігурація Vault

Посібник з'єднань прямо зазначає: Vault спочатку вимкнений. Потрібні VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID та VAULT_SECRET_ID. Часткова конфігурація ігнорується з попередженням; облікові дані тоді зберігаються відкритим текстом у Postgres.

Модуль Vault і сервіс з'єднань підтверджують цей вибір у коді. Приймальний тест має встановити фактичне місце зберігання на фіктивних даних і перевірити резервні копії. Наявність однієї змінної не доводить захисту. Самі секрети до звіту не включаються.

З чого почати

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

Apache-2.0 визначає умови використання. У перевіреній гілці є коміт від 3 листопада зі зміною типових моделей. Недавнє супроводження не доводить придатності до робочих даних. Почніть з одного показника і бази лише для читання; ширший доступ залежить від перевірених визначень, відмов і зберігання секретів.