Embeddings vs inference: где заканчивается ChatGPT и начинается RAG

Два режима, которые путают

Когда говорят «AI», в голове обычно одна картинка: окошко чата, ты пишешь, оно отвечает. Под капотом это inference — модель прогоняет твой текст через свои миллиарды параметров и генерирует ответ.

Но у LLM есть второй режим — embeddings. Это когда модель не отвечает на текст, а превращает его в вектор — длинный список чисел, который описывает «смысл» текста.

Эти два режима делают разные вещи и решают разные задачи. Путаница начинается, когда люди ждут от inference того, что умеют только embeddings — и наоборот.

Что такое inference

Inference — «логический вывод». Ты даёшь промт, модель отдаёт ответ.

Это работает так:

1. Твой текст разбивается на токены
2. Токены проходят через сеть
3. Сеть предсказывает следующий токен
4. Повторить, пока не закончится

Inference — дорогой и разовый. Каждый запрос — это новый прогон. Модель ничего не помнит между запросами, кроме того, что ты сам передал в этом конкретном промте.

Inference хорош для:

• Ответ на вопрос
• Перефразирование, перевод
• Структурирование текста
• Креатив (тексты, идеи, код)
• Рассуждение по цепочке

Inference плох для:

• «Найди в моих 500 документах что-то похожее на Х» — нельзя, в одном промте не помещается
• «Помни, что я говорил неделю назад» — нет встроенной памяти
• «Постоянно ищи в базе и обновляй ответ» — каждый раз новая полная цена

Что такое embeddings

Embedding — «числовое представление смысла». Модель берёт текст и выдаёт вектор фиксированной длины — например, 1024 числа.

Главное свойство: похожие по смыслу тексты дают похожие векторы. «Красная машина» и «алый автомобиль» окажутся рядом в векторном пространстве. «Красная машина» и «рецепт борща» — далеко.

Embedding-модель умеет только это. Она не отвечает на вопросы. Не пишет тексты. Не рассуждает. Она преобразует текст в вектор.

Зачем это нужно? Чтобы искать по смыслу, а не по словам.

Поиск по словам (Ctrl+F) пропустит «алый автомобиль», когда ты искал «красная машина». Поиск по embeddings — найдёт, потому что векторы близки.

Embeddings хороши для:

• Семантический поиск в большой базе документов
• Группировка похожих текстов
• Дедупликация (найти дубли по смыслу, а не по буквам)
• Рекомендации («похожее на это»)
• Память для AI-ассистента: «о чём мы говорили в прошлом месяце»

Embeddings в десятки раз дешевле inference. Получить embedding одного текста — копейки. Зато embedding не «отвечает» — для ответа всё равно нужен inference.

Что такое RAG — и почему это связка обоих

RAG (Retrieval-Augmented Generation) — это не отдельная технология, а схема, которая склеивает embeddings и inference в один поток.

Пошагово:

1. У тебя 500 документов. Ты заранее прогоняешь их через embedding-модель и складываешь векторы в векторную базу (Pinecone, Weaviate, Chroma, pgvector в Postgres).
2. Пользователь задаёт вопрос. Ты прогоняешь вопрос через ту же embedding-модель и получаешь его вектор.
3. Векторная база возвращает 3-5 документов, чьи векторы ближе всего к вектору вопроса.
4. Эти 3-5 документов ты подставляешь в промт к inference-модели вместе с исходным вопросом: «Ответь на вопрос Х, опираясь на следующие куски: [тексты]».
5. Inference-модель отвечает, используя реальные данные из твоих документов.

Это и называется RAG: сначала достали (retrieval), потом сгенерировали (generation).

Зачем такая сложность вместо «дать всю базу в промт»? Потому что 500 документов в один промт не лезут — контекстное окно ограничено. Зато с RAG ты в любой момент достаёшь только самые релевантные 3-5 под конкретный вопрос.

Когда какой режим брать

Главный сигнал: «у меня есть свои данные, и AI должен опираться на них» — это RAG. Только inference тут не справится: модель не знает твоих документов и начнёт «галлюцинировать».

Типичные ошибки

«Дам Claude весь свой Notion в промт»

Не получится — Notion даже среднего размера не помещается в контекстное окно. И даже если помещается, ты будешь каждый раз платить за весь объём как input.

Правильно: один раз прогнать через embeddings, сложить в векторную базу, дальше доставать релевантные куски под каждый вопрос.

«Сделаю бота на ChatGPT API, он будет помнить клиентов»

Не будет — inference без памяти. Между разговорами ничего не остаётся. Если хочешь долгую память — нужен RAG: каждое сообщение клиента сохраняешь, embedding-ишь, при следующем разговоре достаёшь релевантную историю и подставляешь в промт.

«Embeddings = вторая модель, давайте использовать Claude для embeddings»

Claude и GPT — модели для inference. У них нет режима «выдай вектор». Для embeddings нужны отдельные модели: text-embedding-3-small/large от OpenAI, voyage-3 от Voyage AI, bge-large open-source. Они дешёвые и специально заточены под эту задачу.

Что попробовать прямо сейчас

Если у тебя есть база документов (заметки, инструкции, прошлые проекты) и ты хочешь, чтобы AI отвечал по ним — собери минимальный RAG:

1. Возьми Postgres с расширением pgvector (или Chroma, если хочешь без БД)
2. Прогоняй каждый документ через text-embedding-3-small (OpenAI, $0.02 за 1M токенов — почти бесплатно)
3. Сохраняй вектор + текст в базу
4. На вопрос — embedding вопроса → top-5 ближайших → в промт к Claude → ответ

Это собирается за день. Дальше можно усложнять: чанковать большие документы, добавлять метаданные для фильтрации, переранжировать результаты.

Главное — не путать режимы. Если задача звучит как «найти и ответить» — это RAG. Если просто «ответить» — голый inference. Если просто «найти похожее» — голые embeddings.