Картинки для RAG описывают один раз — вместо +51% к цене запроса

kapa.ai попробовала кормить картинки мультимодальной модели прямо в момент запроса — и получила +27% к цене на GPT и +51% на Claude. Решение оказалось скучным: описать каждое изображение текстом один раз при индексации.

Почему «просто отправить картинку модели» не работает в проде

Схема индексации изображений для RAG от kapa.ai
Схема индексации изображений для RAG от kapa.ai

В технической документации половина смысла живёт в картинках: графики, таблицы, матрицы, архитектурные схемы, скриншоты UI. Для RAG-системы (retrieval-augmented generation — ответ модели на основе найденных кусков документации) это слепое пятно: текст она ищет, а изображения — нет. Разбор kapa.ai описывает, как они это закрыли, и почему отвергли «очевидное» решение. В треде 18 комментариев, и спор там не про метод, а про то, насколько он вообще нов.

Что конкретно сделала kapa.ai и какой ценой обходился наивный путь

Главный тезис формулируется одной фразой: «Мы не отправляем картинки модели в момент запроса. Мы описываем каждое изображение один раз, на этапе индексации, дешёвой vision-моделью, сохраняем описания как текст» — и достаём их рядом с обычными текстовыми чанками.

Прежде чем прийти к этому, они честно попробовали наивный мультимодальный путь — слать сырые картинки в GPT 5.1 и Claude 4.6 Sonnet прямо при запросе — и уперлись в три стены:

  • Экономика. Обработка картинок в момент запроса добавляла +27% к стоимости на GPT и +51% на Claude. На миллионах запросов это нежизнеспособно.
  • Технический потолок. «Типичный вопрос достаёт 10-30 чанков, ссылающихся в среднем на 20-30 изображений, с длинным хвостом за 130». Лимит запроса в 30 МБ у Claude и 50 МБ у OpenAI такой объём просто не вмещает.
  • Плохое семантическое совпадение. CLIP-эмбеддинги теряют мелкие детали, критичные для графиков и таблиц, а короткие технические запросы дают слишком мало сигнала для матчинга по картинкам.

kapa.ai делит изображения на два типа: иллюстративные (поясняют уже существующий текст — скриншоты, диаграммы) и несущие (содержат незаменимые данные — таблицы, матрицы, схемы). Описание один раз закрывает оба случая.

Результат подхода с разовым описанием: прирост стоимости запроса — всего +1...6%, качество ответов статистически значимо выше (p < 0,05), точность размещения картинки в ответе — 94-99%, рост латентности — меньше секунды, и никаких повторяющихся расходов на изображения.

Тред: «это реклама — так делают вообще все»

Самый громкий голос в обсуждении — обвинение в банальности.

«Это реклама их продукта. В этом подходе нет ничего особенного, и его, вероятно, делают точно так же все остальные» — скептик, увидевший в посте рекламу

Но тут же — те, кто делает так же годами, и подтверждают, что метод рабочий именно на практике.

«Я делаю так уже два года, и оно отлично работает. Минус один: для документов с такими картинками мне приходилось гоняться за авторами, чтобы они обновляли подписи. Зато это дешевле мультимодального подхода и меньше времени на индексацию» — инженер, делающий так же два года

Ещё одна реплика — про то, что это давно известный паттерн из обработки медиа, просто перенесённый на LLM.

«В ингесте медиа это называется eager-обработкой — исторически так тянули превью картинок и видео и заранее генерировали типовые размеры. Здесь тот же паттерн, и он полностью оправдан. Единственное опасение: из-за недетерминизма LLM новые модели будут вытаскивать из ваших данных новую информацию» — практик про eager-обработку медиа

Личный кейс из соседней области показывает, что подход работает и в персональных заметках:

«Я так делаю в своём Obsidian-дампе. Если знаю, что картинка важна, генерирую текстовое описание (Mermaid, если получается, иначе по-английски) и вставляю прямо после картинки. Это позволяет агентам видеть изображение» — пользователь, описывающий картинки в Obsidian

Очевидный вопрос — и ответ kapa.ai на него

Кто-то задал ровно тот вопрос, ради которого и написан пост:

«А почему не мультимодальная эмбеддинг-модель?» — участник про мультимодальные эмбеддинги

Ответ уже лежит в самой статье: CLIP-подобные эмбеддинги теряют детали графиков и таблиц, а на коротких технических запросах матчинг по картинкам разваливается — ровно та третья стена, в которую kapa.ai и уперлась.

Что тут на самом деле интересно: «скучное» решение бьёт «умное»

Обвинение «ничего нового» отчасти справедливо — и в этом весь смысл. На фоне гонки за мультимодальностью kapa.ai публично показала с цифрами, что наивный путь (картинки в модель на каждом запросе) проигрывает по деньгам в разы и упирается в лимиты запроса, а скучное решение из эпохи генерации превьюшек даёт +1...6% к цене вместо +51% и статистически лучшие ответы. Если вы строите RAG поверх документации с графиками и таблицами — это аргумент описывать изображения один раз при индексации, а не платить за их «понимание» в каждом запросе.

Получайте такие разборы каждый день

Главные истории Hacker News — на email, в Telegram или RSS.

Следующая новость · 8 из 24 Читать дальше
🚀Tech

Свободные 8 ГБ VRAM превращают в swap — и латентность падает в 27 раз

На ноутбуке с распаянной памятью без апгрейда дискретная видеокарта простаивает, пока система свопится на SSD. Автор nbd-vram отдал её 8 ГБ VRAM под swap — и получил среднюю латентность 335 мкс против 9 мс у NVMe.

★ 290 · 💬 78 · github.com · 5 мин