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

В технической документации половина смысла живёт в картинках: графики, таблицы, матрицы, архитектурные схемы, скриншоты 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 ГБ VRAM превращают в swap — и латентность падает в 27 раз
На ноутбуке с распаянной памятью без апгрейда дискретная видеокарта простаивает, пока система свопится на SSD. Автор nbd-vram отдал её 8 ГБ VRAM под swap — и получил среднюю латентность 335 мкс против 9 мс у NVMe.