Как быть, если одно и то же изображение встречается в документах с разными подписями?

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

В мультимодальных RAG-системах одно изображение может появляться в разных документах с разными подписями (например, в новостях, научных статьях, блогах). Проблема в том, что при retrieval мы можем вернуть изображение с неподходящей подписью, что ухудшит ответ LLM. Решение — хранить для каждого изображения несколько контекстов (подписей) и при поиске выбирать наиболее релевантную подпись к запросу пользователя. Это требует специальной индексации и ранжирования, но повышает точность и гибкость системы.

1. Термины: мультимодальный RAG, изображение, подпись, контекст

• Мультимодальный RAG — расширение классического RAG, где в базу знаний добавляются не только текстовые документы, но и изображения, аудио, видео. Изображения обычно хранятся в виде эмбеддингов (через CLIP, SigLIP и т.п.) и/или в исходном формате.
• Изображение — визуальный объект (фото, график, схема). В контексте RAG оно может быть как самостоятельной единицей, так и частью документа.
• Подпись (caption) — текстовое описание изображения, которое обычно находится рядом с ним в документе (например, под рисунком). Подпись может быть краткой или развёрнутой, содержать контекст документа.
• Контекст изображения — совокупность подписи, окружающего текста, метаданных (дата, автор, источник). В данном вопросе под «контекстом» понимается именно подпись, так как она наиболее информативна для поиска.

2. Проблема: почему одно изображение может иметь разные подписи?

Одна и та же фотография или иллюстрация может использоваться в разных документах с разными целями:

Причины различий:

• Разные авторы по-разному интерпретируют одно и то же изображение.
• Разные жанры (новости vs наука) диктуют разный стиль подписей.
• Ошибки OCR/разметки — подпись может быть неверно извлечена.
• Изображение используется как декоративное — подпись может быть пустой или неинформативной.

Если мы храним только одну подпись (например, первую попавшуюся), то при запросе пользователя «Как изменился ВВП в 2024?» система может вернуть изображение с подписью «Президент выступает…», что нерелевантно. LLM, получив такое изображение, либо даст неверный ответ, либо проигнорирует его.

3. Решение: хранение нескольких контекстов и выбор релевантной подписи

Основная идея — не усреднять и не выбирать одну подпись заранее, а сохранить все варианты и динамически выбирать наиболее подходящий под запрос пользователя.

Архитектура:

1. Индексация изображений:

   • Каждое изображение получает уникальный ID (например, хеш от пикселей).
   • Для каждого документа, где встречается это изображение, сохраняем пару (image_id, caption, document_id, metadata).
   • В векторной БД храним эмбеддинги изображений (визуальные) и эмбеддинги подписей (текстовые) — отдельно или в одном пространстве (через мультимодальные модели вроде CLIP).

2. Retrieval:

   • По запросу пользователя ищем релевантные изображения (по визуальному сходству или по тексту запроса, если используется CLIP).
   • Для каждого найденного изображения получаем все его подписи.
   • Ранжируем подписи по релевантности к запросу (например, косинусное сходство между эмбеддингом запроса и эмбеддингом подписи).
   • Возвращаем изображение + наиболее релевантную подпись (или top-k подписей, если контекст позволяет).

3. Генерация ответа:

   • LLM получает изображение и выбранную подпись как часть контекста.
   • Подпись помогает LLM правильно интерпретировать изображение.

4. Детали реализации: как хранить и выбирать

4.1. Структура данных

В векторной БД (например, Qdrant, Weaviate, Pinecone) можно использовать коллекцию images с точками:

{
  "id": "img_abc123",
  "vector": [0.12, -0.45, ...],  # эмбеддинг изображения (CLIP visual)
  "payload": {
    "captions": [
      {"text": "Президент выступает...", "source": "news_2024", "score": 0.92},
      {"text": "Рис. 1. Динамика ВВП...", "source": "paper_2023", "score": 0.88},
      ...
    ]
  }
}

Альтернатива — отдельная коллекция captions, где каждая подпись ссылается на image_id. Тогда retrieval двухэтапный: сначала ищем изображения, потом по image_id ищем подписи и ранжируем.

4.2. Выбор релевантной подписи

Метод 1: Семантическое сходство (cosine similarity)

• Заранее вычисляем эмбеддинги подписей (тем же CLIP text encoder).
• При retrieval считаем сходство между эмбеддингом запроса и каждым эмбеддингом подписи.
• Выбираем подпись с максимальным сходством.

Метод 2: LLM-ранжирование

• Если подписей много, можно использовать небольшой LLM (например, GPT-4o-mini) для выбора лучшей подписи по запросу.
• Дороже, но точнее, особенно если подписи семантически близки.

Метод 3: Гибридный

• Сначала отсекаем подписи с низким сходством (порог 0.5), затем LLM выбирает из оставшихся.

4.3. Обработка случая, когда подпись отсутствует

Если изображение встречается без подписи (например, в PDF без alt-текста), можно:

• Использовать модель image captioning (BLIP, GIT) для генерации подписи «на лету».
• Хранить сгенерированную подпись как один из вариантов.

5. Альтернативные подходы и их ограничения

Предложенное решение (хранение нескольких подписей + динамический выбор) — наиболее гибкое и точное, хотя требует больше вычислительных ресурсов на этапе retrieval.

6. Метрики оценки качества выбора подписи

Чтобы понять, правильно ли система выбирает подпись, нужны специальные метрики:

• Подпись-релевантность (Caption Relevance) — оценивает, насколько выбранная подпись соответствует запросу. Можно использовать LLM-as-a-judge (например, GPT-4 оценивает по шкале 1-5).
• Влияние на ответ (Answer Faithfulness) — сравниваем ответ LLM с использованием правильной подписи vs неправильной. Если ответ меняется кардинально — выбор подписи критичен.
• Recall@k подписей — для каждого запроса есть gold-standard подпись (размеченная человеком). Считаем, в скольких случаях правильная подпись попала в top-k выбранных.
• Latency — время на ранжирование подписей. Должно быть < 100 мс, чтобы не замедлять общий ответ.

7. Trade-offs и компромиссы

• Хранение: несколько подписей увеличивают размер payload в векторной БД. Для миллионов изображений это может быть существенно. Решение — хранить подписи в отдельной колонке или внешнем key-value store.
• Retrieval latency: ранжирование подписей добавляет O(N) операций на изображение, где N — количество подписей. Если N > 10, стоит предварительно фильтровать по сходству.
• Точность vs скорость: LLM-ранжирование даёт лучший выбор, но медленнее. Для продакшена обычно используют семантическое сходство, а LLM — только для сложных случаев (fallback).
• Дублирование изображений: если одно и то же изображение хранится с разными ID (из-за разных хешей), нужно дедуплицировать. Иначе система может вернуть несколько копий с разными подписями, запутывая LLM.

8. Пример кода (фрагмент на Python)

import numpy as np
from sentence_transformers import SentenceTransformer
from typing import List, Dict

# Загрузка модели для эмбеддингов (можно CLIP)
text_model = SentenceTransformer('all-MiniLM-L6-v2')

def select_best_caption(query: str, captions: List[Dict]) -> str:
    """
    Выбирает наиболее релевантную подпись к запросу.
    captions: список словарей [{"text": "...", "embedding": [...]}]
    """
    query_emb = text_model.encode(query)
    best_score = -1
    best_caption = ""
    for cap in captions:
        score = np.dot(query_emb, cap["embedding"]) / (
            np.linalg.norm(query_emb) * np.linalg.norm(cap["embedding"])
        )
        if score > best_score:
            best_score = score
            best_caption = cap["text"]
    return best_caption

# Пример использования
captions_db = [
    {"text": "Президент выступает на форуме", "embedding": [0.1, 0.2, ...]},
    {"text": "Динамика ВВП по годам", "embedding": [0.3, 0.1, ...]},
]
query = "Как изменился ВВП?"
best = select_best_caption(query, captions_db)
print(best)  # "Динамика ВВП по годам"

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

Задача: Создать мини-мультимодальный RAG, который умеет обрабатывать изображения с несколькими подписями.

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

• Python, LangChain или LlamaIndex
• Векторная БД: Chroma (in-memory) или Qdrant (local)
• Модель: CLIP (openai/clip-vit-base-patch32) для эмбеддингов изображений и текста
• Датасет: 10-20 изображений из Wikimedia Commons, для каждого собрать 2-3 разные подписи из разных статей

Шаги:

1. Загрузить изображения, вычислить визуальные эмбеддинги.
2. Для каждого изображения сохранить список подписей с текстовыми эмбеддингами.
3. Реализовать retrieval: по текстовому запросу найти top-3 изображения (по сходству запроса с визуальным эмбеддингом или с эмбеддингами подписей — поэкспериментировать).
4. Для каждого найденного изображения выбрать лучшую подпись (семантическое сходство).
5. Передать изображение (как URL) и выбранную подпись в LLM (например, через OpenAI Vision API) и получить ответ.
6. Сравнить качество ответа, если всегда брать первую подпись vs динамический выбор.

Ожидаемый результат: Система, которая для запроса «экономические данные» выбирает подпись про ВВП, а для запроса «политическое событие» — подпись про выступление президента, даже если изображение одно и то же.

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

11. Навигация

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

Навигация

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