Вы обучили модель с онтологией. Лид говорит: «Качество выросло!» Эксперт кивает: «Похоже на правду.» Но как доказать и измерить этот рост объективно? Традиционные метрики для NLP (BLEU, ROUGE, METEOR) оценивают поверхностное сходство с эталоном, но молчат о смысле. Нужны специализированные метрики для оценки онтологического понимания.  

Уровни оценки: от синтаксиса до семантики  

Уровень 1: Корректность сущностей (Entity Correctness)  

• Что оцениваем: Способность модели правильно извлекать, упоминать и классифицировать сущности из онтологии.  

• Метрики (классические, но адаптированные):  

  • Precision/Recall/F1 для NER: Запускаем NER-модель (или ручную разметку) на выходах LLM и сравниваем с эталонным списком сущностей, которые должны быть в ответе согласно онтологии. Ключевой нюанс: учитываем тип сущности (не просто «лостартан», а «лостартан [КАК МЕДИКАМЕНТ]»).  

  • Строгая точность соответствия (Exact Match): Доля ответов, где все необходимые сущности упомянуты корректно и никаких лишних нет.  

Уровень 2: Корректность отношений (Relational Correctness)  

• Что оцениваем: Понимает ли модель связи между упомянутыми сущностями.  

• Метрики:  

  • Точность отношений (Relation Precision): Извлекаем из ответа модели пары сущностей и предсказанное отношение между ними (можно с помощью промптинга к другой LLM: «Какая связь между X и Y в этом тексте?»). Сравниваем с эталонными отношениями из онтологии.  

  • Точность графа подвывода (Subgraph Precision): Если ответ описывает цепочку ( А вызывает Б, Б лечится В), мы оцениваем, насколько этот маленький граф соответствует истинному графу знаний.  

Уровень 3: Логическая непротиворечивость (Logical Consistency)  

• Что оцениваем: Способность модели избегать внутренних противоречий и противоречий с онтологией.  

• Метрики (задачно-ориентированные):  

  1. Тест на транзитивность: Серия вопросов. «Верно ли, что А является подклассом Б?» (Да). «Верно ли, что Б является подклассом В?» (Да). «Верно ли, что А является подклассом В?» Идеальная модель всегда ответит «Да».  

  2. Тест на симметрию/асимметрию: «Если А является частью Б, может ли Б быть частью А?»  

  3. Коэффициент согласованности (Consistency Score): Задаем модели один и тот же факт в разных формулировках и контекстах. Процент совпадения ответов — метрика ее внутренней устойчивости.  

Уровень 4: Качество сложных выводов (Complex Reasoning Quality)  

• Что оцениваем: Способность делать многошаговые выводы, используя онтологию как набор правил.  

• Метрики:  

  • Точность на синтетических логических задачах: Создайте набор многошаговых вопросов, ответы на которые требуют прохода по 2-3-4 связям в онтологии. Пример для медицины: «У пациента болезнь X, которая является противопоказанием для препарата Y. Препарат Z — аналог Y. Можно ли назначить Z?» (Ответ: «Нет, если аналогичность подразумевает одинаковые противопоказания»).  

  • Оценка «шагов рассуждения» (Chain-of-Thought Evaluation): Заставляем модель генерировать рассуждение шаг за шагом (Chain-of-Thought). Затем каждый шаг проверяем на соответствие онтологии. Метрика — процент корректных шагов.  

Уровень 5: Объяснимость и трассируемость (Explainability & Traceability)  

• Что оцениваем: Может ли модель указать на конкретные факты в онтологии, которые привели к такому выводу.  

• Метрики:  

  • Процент ответов с корректными цитатами: Внедрите требование, чтобы модель в ответе цитировала используемые факты (например, [Источник: Онтология, факт ID:123]). Оценивается доля ответов, где цитаты действительно соответствуют выводу.  

  • Оценка экспертом (человеческая): Эксперт проверяет не только итоговый ответ, но и «объяснение» модели. Шкала: 1 — вывод необоснован, 5 — вывод четко следует из указанных фактов онтологии.  

Практический фреймворк для оценки:  

1. Создание оценочного бенчмарка:  

   • Набор A (Простой): Фактологические вопросы с прямым ответом из онтологии.  

   • Набор B (Средний): Вопросы на проверку 1-2 связей.  

   • Набор C (Сложный): Многошаговые выводы и краевые случаи.  

2. Автоматизация оценки:  

   • Для Наборов A и B можно написать скрипты-валидаторы, которые проверяют ответ по онтологии (как запрос к графу знаний).  

   • Для Набора C потребуется LLM-as-a-Judge, но с четкой инструкцией: «Оцени вывод, сверяясь с данной онтологией (приложена). Если вывод логически следует из онтологии — 5, если есть ошибка в логике — 1».  

3. Сводная панель (Dashboard): Постройте дашборд, который показывает динамику по всем метрикам для каждой версии модели. Это ваш главный инструмент для принятия решения о выкатке в прод.  

Пример: Оценка IT-операционного ассистента  

• Метрика 1 (Сущности): F1-скор по извлечению сервисов, инцидентов, хостов.  

• Метрика 2 (Отношения): Точность определения, на каком хосте работает упавший сервис.  

• Метрика 3 (Логика): Процент корректных ответов на вопрос: «Если хост Х входит в кластер Y, и мы останавливаем Y на техобслуживание, какие сервисы будут затронуты?»  

• Метрика 4 (Объяснимость): Наличие в ответе ссылок на CMDB (Configuration Management Database) — систему-источник истины.  

Вывод для QA Lead в AI-проекте:    
Оценка онтологического понимания — это отдельная инженерная дисциплина. Она требует построения специализированных оценочных наборов (benchmarks) и автоматизированных валидаторов, основанных на вашей же онтологии. Инвестиции в такую систему оценки — это страховка от внедрения «говорящей» модели, которая не понимает, что говорит. Только так вы переводите диалог о качестве с субъективных «мне нравится» на объективные «модель достигает 95% точности на логических выводах уровня 2».