Как вы проверяете, что LLM правильно «понял» диаграмму, а не просто угадал?

Краткий тезис

LLM может дать верный фактологический ответ, даже не восстановив топологию диаграммы — например, ответить «да» на вопрос о связности, угадав по ключевым словам. Проверка понимания диаграммы требует метрики retrieval Subgraph Retrieval Recall (SRR) — доли извлечённых системой узлов и рёбер, необходимых для ответа. SRR проверяет, восстановил ли retrieval (поиск) полный путь в графе, а не отдельные фрагменты. Дополнительно оценивается faithfulness (верность ответа извлечённому подграфу), чтобы убедиться, что LLM не «додумал» связи.

1. Термин: диаграмма как граф

Любую структурную диаграмму (блок-схему, граф связей, архитектурную схему) можно представить в виде графа:

• Узлы (nodes) — объекты, блоки (например, «сервер», «база данных», «пользователь»).
• Рёбра (edges) — связи, потоки данных, зависимости (например, «call|вызов API», «запись в БД»).
• Атрибуты — текстовые метки, типы, веса.

LLM может «угадать» ответ, используя свои общие знания или ключевые слова из текстовых описаний, не восстанавливая реальную структуру графа. Проблема особенно остра в мультимодальном RAG, где диаграмма подаётся как изображение или как текстовое описание.

2. Проблема: почему LLM часто угадывает

Пример:

Диаграмма: «Пользователь → Аутентификация → База данных». Вопрос: «Есть ли прямой доступ к БД без аутентификации?» Правильный ответ: «Нет».

LLM может ответить «Нет», опираясь на общий принцип безопасности, даже если диаграмма на самом деле содержит альтернативный путь (например, «Пользователь → Кеш → База данных»). Без извлечения подграфа связей система не способна удостовериться, что LLM действительно «видит» разрыв в пути.

Главная опасность: ложная уверенность — метрика на финальный ответ (accuracy/EM) может быть высокой, а реальное понимание структуры — отсутствовать.

3. Метрика Subgraph Retrieval Recall (SRR)

3.1 Определение

Subgraph Retrieval Recall — доля узлов и рёбер из ground truth подграфа (эталонного множества, необходимого для ответа), которые были извлечены retrieval-компонентом и поданы LLM.

Формально:

SRR = (|извлечённые узлы ∩ эталонные узлы| + |извлечённые рёбра ∩ эталонные рёбра|)
     / (|эталонные узлы| + |эталонные рёбра|)

Где:

• извлечённые узлы/рёбра — те элементы графа, которые попали в контекст LLM (например, через текстовые чанки, описывающие диаграмму, или через прямое извлечение из графа).
• эталонные узлы/рёбра — заранее размеченные элементы, которые необходимы для правильного ответа на конкретный вопрос.

3.2 Отличие от recall@k

SRR — это аналог recall, но для графового пространства. Если recall@k показывает, что найден нужный чанк, SRR показывает, восстановлен ли весь подграф.

3.3 Пример расчёта

Пусть для вопроса «Может ли пользователь напрямую писать в БД?» эталонный подграф:

• узлы: {Пользователь, База данных}
• рёбра: {Пользователь → База данных}

Извлечено:

• узлы: {Пользователь, Аутентификация, База данных} (лишний узел)
• рёбра: {Пользователь → Аутентификация, Аутентификация → База данных} (нет прямого ребра Пользователь → БД)

SRR = (|{Пользователь, База данных}| + |∅|) / (2 + 1) = 2/3 ≈ 0.67

LLM получает подграф, с которого может корректно ответить «Нет» (прямой связи нет), но SRR не идеален, потому что не извлечено само ребро-запрос. Обычно SRR > 0.8 считается приемлемым.

4. Процесс проверки понимания диаграммы

4.1 Этап 1: Разметка ground truth

Для каждого вопроса датасета необходимо вручную или полуавтоматически (с помощью графового аннотатора) указать:

• Минимальный подграф, достаточный для ответа.
• Ожидаемое объяснение (почему ответ такой).

4.2 Этап 2: Извлечение подграфа retrieval-компонентом

Способы извлечения:

• Текстовый: диаграмма описана в тексте (например, D2-скрипт или список связей) → используем стандартный retrieval чанков.
• Мультамодальный: диаграмма — изображение → используем мультимодальный эмбеддер (например, CLIP) для поиска изображений, затем OCR или парсер структуры для извлечения графа.
• Графовая БД: если документы хранятся в графовой БД (Neo4j), retrieval может быть traversal-запросом.

4.3 Этап 3: Оценка SRR

Сравниваем извлечённый подграф с эталонным. Инструменты: NetworkX (Python) для сравнения множеств узлов/рёбер.

4.4 Этап 4: Оценка faithfulness

Даже если извлечён правильный подграф, LLM может «придумать» несуществующие связи. Проверяем с помощью LLM-as-judge или структурной верности:

• Faithfulness score: доля утверждений в ответе, подтверждённых извлечённым подграфом. Можно посчитать с помощью NER на предсказании и поиске в подграфе.
• Structural consistency: ответ должен описывать только те пути, которые есть в извлечённом графе.

Если faithfulness низкая, а SRR высокая — проблема в генерации, а не в retrieval.

5. Дополнительные метрики

6. Когда достаточно обычных метрик, а когда нужен SRR

• Простая диаграмма (один узел): достаточно точности ответа (Accuracy).
• Диаграмма с разветвлениями, условными переходами: SRR обязателен, иначе LLM может «угадать» по части.
• Мультимодальный RAG с изображениями: SRR помогает отсечь случаи, когда LLM игнорирует графические детали (цвета, стрелки).

7. Инструментальная реализация

Пример на Python с NetworkX:

import networkx as nx

def compute_srr(extracted_nodes, extracted_edges, gold_nodes, gold_edges):
    gold_set = set(gold_nodes) | set(gold_edges)
    retrieved_set = set(extracted_nodes) | set(extracted_edges)
    intersection = retrieved_set & gold_set
    if len(gold_set) == 0:
        return 1.0
    return len(intersection) / len(gold_set)

# Пример
gold_nodes = ["Пользователь", "БД"]
gold_edges = [("Пользователь", "БД")]
extracted_nodes = ["Пользователь", "Аутентификация", "БД"]
extracted_edges = [("Пользователь", "Аутентификация"), ("Аутентификация", "БД")]

srr = compute_srr(extracted_nodes, extracted_edges, gold_nodes, gold_edges)
print(f"SRR: {srr:.2f}")  # 0.67

Для faithfulness можно применить LLM-as-judge:

prompt = f"""
Дан извлечённый подграф: {extracted_edges}
Ответ LLM: {answer}
Верен ли каждый факт ответа относительно подграфа? Ответь только True/False для каждого факта.
"""
# Парсинг и усреднение

8. Преимущества и ограничения подхода

Преимущества:

• Прямая проверка того, что нужно для понимания структуры.
• Позволяет отделить ошибки retrieval от ошибок генерации.
• Легко интерпретируется (почему провал — не хватает рёбер).

Ограничения:

• Высокая стоимость разметки ground truth подграфов (нужны эксперты).
• Не учитывает семантику атрибутов (например, метки «REST» vs «gRPC» — разные, но структурно одинаковы).
• Сложность с мультимодальными диаграммами (OCR может быть неточным).

Пет-проект для закрепления

Задача: Построить систему мультимодального RAG для вопросов по блок-схемам (FlowchartQA или собственный датасет из 50 диаграмм) и оценить LLM с помощью SRR.

Инструменты:

• Данные: нарисовать 10 блок-схем с помощью diagrams.net, сохранить как PNG и экспортировать в D2 (текстовое описание).
• Ретривл: мультимодальный эмбеддинг (CLIP) для поиска изображения; для извлечения узлов и рёбер использовать OCR + парсер (например, Grobid или простой шаблон для D2).
• Генерация: GPT-4o или другая LLM с vision. Шаги:

1. Разметить ground truth подграфы для 20 вопросов.
2. Реализовать retrieval, возвращающий список чанков (текст D2 или извлечённый граф).
3. Посчитать SRR, Precision, F1 для подграфа.
4. Посчитать faithfulness (вручную или LLM-as-judge).
5. Сравнить метрики для случаев, когда LLM даёт правильный ответ, но SRR низкий (примеры «угадывания»). Ожидаемый результат: Получить количественное подтверждение, что SRR — более чувствительная метрика, чем точность ответа. Демонстрировать, что при высоком SRR (>0.7) faithfulness почти всегда >0.9, а при низком SRR — даже если ответ верен, объяснение может быть неверным.

Связь с другими вопросами

Навигация

• Предыдущий: 117
• Следующий: 119
• Индекс: 00. Индекс разборов