Promptra Team for Promptra

Posted on Jul 21

Одних векторов ИИ-агенту мало: гибрид и graphrag меняют RAG

#ai #agents #llm #coding

Главное. Генерация текста почти перестала быть проблемой - модели пишут связно и рассуждают. Ломается другое: поиск нужного куска знаний перед ответом. Если ИИ-агент притащил мусор, самая сильная модель уверенно наврёт поверх мусора. В 2026 фронт работ сместился в retrieval: гибридный поиск, реранкинг, местами граф знаний и агентные петли. Ниже - как это собрать, что из этого реально помогает, а что жрёт бюджет впустую, и какую векторную базу брать под конкретную нагрузку.

⚠️ Данные актуальны на 2026-07-10. Модели, версии, цены и лимиты в ИИ меняются каждую неделю - сверяйся с первоисточником на свою дату.

Почему в 2026 узкое место у ИИ-агента - поиск?

Коротко: Модель научилась писать и рассуждать, а вот находить точный факт в твоих документах - нет. Провал почти всегда в retrieval: ИИ-агент подтянул не тот кусок, и дальше уверенная галлюцинация. За Q1 2026 намерение внедрять гибридный поиск в enterprise выросло с 10,3% до 33,3% - рынок это уже почувствовал (VentureBeat, 2026-05-18).

Разберёмся с терминами сразу, без разгона. ИИ-агент - это программный робот: бот, который сам решает, что ему поискать, лезет в базу знаний, оценивает найденное и при нужде ищет снова. Когда в 2026 говорят «ИИ для роботов», чаще имеют в виду именно такого программного робота в бизнес-контуре, а железо на колёсах тут ни при чём. У любого такого робота два движка: генерация (LLM пишет ответ) и retrieval (поиск того, на чём ответ строится).

И оба движка - это платные вызовы моделей по API: эмбеддинг-модель считает векторы, LLM пишет ответ, отдельная модель реранкает и оценивает релевантность. Все обращения идут к OpenAI, Anthropic, Cohere, Google - а из России прямой доступ и оплата к ним закрыты. OpenAI блокирует российские IP с июня 2024, карты РФ не принимает, VPN проблему биллинга не решает (DTF, 2026).

provod.ai - это агрегатор нейросетей для пользователей из России: Claude, GPT, Gemini, DeepSeek и Qwen в одном чате и через единый API (OpenAI- и Anthropic-совместимый), с оплатой в рублях легально, без VPN и зарубежных карт, с договором и закрывающими документами для юрлиц. Когда пайплайну нужен вызов топовой модели, подключить её из РФ можно сменой ключа и base_url. Про честную границу - что provod не хостит базу и не строит граф - расскажу ниже, врать не буду.

Так какой из движков - узкое место? Генерация в 2026 почти решена: разрыв между флагманами по качеству текста сузился, модель связно рассуждает и держит длинный контекст. С retrieval сложнее. Когда система отдаёт правдоподобный, но неверный ответ, дело почти всегда в поиске: он вернул нерелевантные чанки, и робот честно написал поверх них уверенную чушь. Это опаснее явного отказа - визуально ответ неотличим от корректного (Habr, «10 актуальных RAG-подходов», 2025-04-29).

Цифры подтверждают сдвиг. По данным VB Pulse RAG Infrastructure Market Tracker, за первый квартал 2026 доля enterprise-покупателей, планирующих внедрять гибридный retrieval, утроилась - с 10,3% до 33,3%. При этом 22% опрошенных признались, что RAG в проде у них вообще нет (VentureBeat, Sean Michael Kerner, 2026-05-18). Люди поняли, что голого векторного поиска мало, и пошли достраивать поисковый слой.

«Модели получают всё внимание, но именно retrieval делает их полезными в проде» - Andre Zayarni, CEO Qdrant, SiliconANGLE, 2026-03-12.

Есть ещё одна отрезвляющая мысль, которую в РФ повторяют enterprise-инженеры: 70-80% проблем RAG сидят в данных - грязные, плохо структурированные исходники бьют больнее, чем выбор модели или векторной БД (Habr, блог Alpina Digital, 2026). Даже идеальный поиск не спасёт, если на входе каша. Но при чистых данных именно поисковый слой решает, притащит робот факт или галлюцинацию.

Что такое RAG нового поколения и из чего он собран?

Коротко: RAG нового поколения - это не «векторный поиск плюс top-k чанков», а многослойный пайплайн. Три несущих слоя: гибридный поиск (dense + BM25 + реранкинг), опционально граф знаний (graphrag) для связанных данных и агентные петли (агентный rag), где робот сам ищет по кругу. Каждый слой включают под конкретную боль, а не «на всякий случай».

Модель 2023 года была простой: нарезал документы на чанки, посчитал эмбеддинги, на запрос достал ближайшие top-k по косинусу, скормил в LLM. На демо всё летает. В проде наивный RAG на больших данных не просто работает хуже - он разваливается (Habr, блог Otus, «Возвращение RAG в 2026 году», 2026-02-23).

Что пришло на смену - собирается из трёх слоёв, которые включают по нарастающей.

Слой	Что решает	Цена / латентность	Когда включать
Гибридный поиск (dense + BM25 + реранкинг)	точность retrieval, точные термины и ID, которые вектор теряет	+50-100 мс на реранкинг; дёшево	почти всегда, это база
Граф знаний (graphrag)	multi-hop и связанные данные («как X влияет на Y через Z»)	индексация $20-40 за 1М токенов; +200-500 мс на запрос	только под связанные данные и multi-hop
Агентные петли (агентный rag)	сложные запросы, где нужно искать по кругу и самопроверяться	4-7x к стоимости базового RAG	под сложные запросы, не под FAQ

Логика простая. Гибридный слой чинит саму точность поиска и нужен почти везде. Граф знаний добавляют, когда данные сильно связаны и вопросы требуют переходов между сущностями. Агентные петли включают, когда одного прохода поиска мало и роботу надо декомпозировать вопрос и искать итеративно.

Ключевое слово - «по нарастающей». Каждый следующий слой дороже и медленнее предыдущего, и каждый из них при неверном применении режет качество. Дальше по статье разберём каждый слой с цифрами: где он окупается, а где ты просто платишь за латентность и токены впустую. Начнём с фундамента - гибридного поиска, потому что без него всё остальное строится на песке.

Чем гибридный поиск (dense + BM25) обходит чистый вектор?

Коротко: Векторный поиск ловит смысл, но промахивается по точным словам - артикулам, кодам ошибок, фамилиям, номерам статей. BM25 (классический лексический поиск) ловит именно точные совпадения. Слить их через RRF - и доля сбоев retrieval падает: контекстные эмбеддинги плюс BM25 снижают провалы на 49%, а с реранкингом - до 67% (Anthropic, 2024-09).

Вектор - это про смысл. Эмбеддинг превращает текст в точку в многомерном пространстве, и близкие по смыслу тексты оказываются рядом. «Эмбединг = смысл. Но все мы работаем с разными смыслами, и это - большая проблема» (Дмитрий Антипов, Habr, 2025-10-29). Проблема в том, что смысловая близость промахивается там, где важна буквальная точность. Запрос «ошибка E-4021 на модели X» вектор поймёт как «что-то про ошибки и модели» и притащит соседей по теме вместо конкретного документа с этим кодом.

Тут выручает BM25 - лексический поиск по совпадению слов, тот самый, что крутится в поисковиках десятилетиями. Он не понимает смысла, зато точно находит «E-4021» и «статью 154». Гибрид берёт оба списка результатов и сливает их.

Как сливать разнородные оценки, если BM25-скор и косинусное сходство несравнимы напрямую? Через Reciprocal Rank Fusion. RRF считает по позициям документов в списках, игнорируя сами значения скоров: score(d) = Σ 1/(k + rank_i(d)) по всем поисковым системам. Константа k=60 - эмпирический sweet spot, найденный ещё Cormack et al. на данных TREC в 2009 году; бенчмарки 2020-х подтверждают, что k в диапазоне 40-80 даёт сопоставимый результат, и большинство вендоров ставят 60 по умолчанию (сводка по Microsoft Learn Azure AI Search и техблогам, 2026-02-10). Плюс RRF - не нужна нормализация несравнимых скоров, работа идёт по рангам.

Теперь цифры. Эталонный источник, на который до сих пор ссылаются в 2026 - Anthropic и его Contextual Retrieval.

Конфигурация retrieval	Доля сбоев на top-20 чанках	Снижение к базе
Обычные эмбеддинги	5,7%	-
Контекстные эмбеддинги	3,7%	-35%
Контекстные эмбеддинги + контекстный BM25	2,9%	-49%
+ реранкинг	-	до -67%

Источник: Anthropic Engineering, Contextual Retrieval, 2024-09, активно цитируется в 2026.

Гибрид против чистых методов по recall выглядит так (индикативно, методология в источнике раскрыта не полностью - воспринимай как порядок величины):

Метод	Recall@10
BM25 (только лексика)	~65%
Dense (только вектор)	~78%
Гибрид (dense + BM25)	~91%

Источник: сводные обзоры RAG-бенчмарков, 2026 (методология раскрыта не полностью - порядок величины).

На финансовых документах прирост ещё жёстче: гибрид с реранкером Cohere дал Recall@5 = 0,816 против 0,587 у чистого dense - это +39% относительно (бенчмарк на finance-корпусе, обзор 2026). Отдельный выброс: на MS MARCO простое взвешенное слияние в некоторых конфигурациях поднимало Recall@10 до 5,8x к чистому вектору - это данные с большим числом точных терминов, но показательно. RU-практика бьётся: команда на Habr подняла Top-1 accuracy с 62% до 88% на корпусе 50k+ корпоративных документов, добавив к вектору BM25 и cross-encoder реранкер (Habr, 2026). Это кейс одной компании, не универсальный закон, но направление то же.

«Если в вашем поисковом слое нет лексической компоненты и реранкера, скорее всего вы поставляете демо, а не систему» - Habr, «Возвращение RAG в 2026 году» (перевод, оригинал SteadyKestrel, перевод Ксения Мосеенкова), 2026-02-23.

Вот почему гибрид - это фундамент. Программный робот, который ищет только вектором, систематически теряет запросы с точными терминами, а таких в реальном бизнесе - половина.

Что добавляет реранкинг и сколько он стоит?

Коротко: Реранкинг - второй проход: сначала быстрый гибрид достаёт top-50-100 кандидатов, потом cross-encoder переоценивает их по релевантности и оставляет лучшие 5-10. Прирост - до +17,4% Recall@5 поверх гибрида (finance-бенч, 2026). Managed Cohere Rerank стоит ~$2 за 1000 запросов, self-host BGE - ~$0,35, но требует GPU.

Гибридный поиск быстрый, но грубый: он ранжирует документы по дешёвым признакам. Реранкер - медленный, но точный: он прогоняет каждую пару «запрос-документ» через модель-cross-encoder, которая читает их вместе и выдаёт честную оценку релевантности. Отсюда двухступенчатая схема: retrieval достаёт много кандидатов, реранкер оставляет золото. Это тот самый шаг, который в бенчмарке Anthropic доводит снижение сбоев до 67%.

Цена вопроса и выбор «managed или self-host»:

Реранкер	Цена	Латентность	Прирост / примечание
Cohere Rerank	~$2,00 / 1000 search units	managed API	+17,4% relative Recall@5 поверх гибрида (finance-бенч 2026); единица = запрос + до 100 документов
BGE-reranker-large v2 (self-host)	~$0,35 / 1000 запросов	50-100 мс на GPU	сопоставимое качество, но нужен свой GPU
BGE-reranker-base v2 (self-host)	~$0,18 / 1000 запросов	50-100 мс на GPU	легче, чуть слабее

Источник цен: обзор рынка rerankers, 2026.

Арифметика окупаемости простая. Self-host BGE обгоняет managed API по цене за запрос примерно с 500-1000 запросов в час на spot-GPU уровня A10 ($0,50-0,80/час). И он часто быстрее: 50-100 мс против сетевого round-trip до чужого API (обзор рынка rerankers, 2026). Расплата - тебе нужен GPU для ИИ и человек, который его поднимет и будет за ним следить. Для маленькой нагрузки Cohere проще: платишь по факту, ничего не хостишь.

Практический вывод. Если у робота меньше пары сотен запросов в час - бери managed Cohere и не морочься инфраструктурой. Если поток стабильно высокий и есть DevOps - self-host BGE на арендованном GPU в разы дешевле на дистанции. Реранкер добавляет 200-400 мс на проход (Habr, 2025-04-29) - для чата это незаметно, для real-time с жёстким SLA считай бюджет латентности заранее.

Когда Graph-RAG реально нужен, а когда только вредит?

Коротко: Graph-RAG (graphrag) строит из документов граф сущностей и связей и ходит по нему при поиске. Он выигрывает на multi-hop и global-запросах: +4,5% глубины рассуждения на HotpotQA, win rate 72-83% на global sensemaking. Но на простом fact-lookup он ХУЖЕ обычного RAG на 13,4%, а на свежих данных - до 16,6% (GraphRAG-Bench, ICLR 2026). Ставить граф «на всякий случай» - терять качество и платить graph tax по латентности.

Идея graphrag красивая. Вместо плоского набора чанков ты извлекаешь из текста сущности (компании, детали, люди, статьи закона) и связи между ними, собираешь граф знаний и при поиске ходишь по рёбрам. Тогда робот отвечает на вопросы, где ответ размазан по многим документам: «как задержка компонента X повлияет на дедлайн Q3 для клиента Y». Чистый вектор тут пасует - он «улавливает похожесть, но упускает структуру» и не знает, что компонент X вообще часть поставки клиенту Y (VentureBeat, Daulet Amirkhanov, май 2026).

На связанных данных граф реально вывозит. В оригинальном бенчмарке Microsoft (arXiv 2404.16130, «From Local to Global») comprehensiveness win rate GraphRAG над векторным RAG на global-запросах - 72-83% на подкастах и новостях. На multi-hop задачах (HotpotQA) граф улучшает глубину рассуждения на +4,5%. Системы с сильной иерархией вроде RAPTOR и HippoRAG показывают среднюю accuracy выше 72 там, где нужно синтезировать информацию из многих узлов (arXiv 2506.05690, ICLR 2026).

А теперь честная граница, ради которой стоит читать этот раздел. Свежий научный бенчмарк GraphRAG-Bench прямо ломает вендорский хайп.

«Recent studies report that GraphRAG frequently underperforms vanilla RAG on many real-world tasks» - авторы arXiv 2506.05690, «When to use Graphs in RAG», ICLR 2026, версия от 2026-02-22.

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

Что показал бенчмарк конкретно:

На Natural Questions (простой fact retrieval) graphrag выдаёт точность на 13,4% ниже обычного RAG.
На time-sensitive запросах (где важна свежесть) разрыв ещё больше - до 16,6% в минус.
На multi-hop (HotpotQA) - плюс 4,5% глубины рассуждения.
Открытые вопросы и этические рассуждения оба класса методов заваливают одинаково.

К этому добавляется «graph tax» - оверхед графового поиска по латентности. Vector-only retrieval - это ~50-100 мс, graph-enhanced - ~200-500 мс в зависимости от глубины хопов (VentureBeat, май 2026). Митигируется семантическим кешированием повторяющихся запросов и CDC-пайплайнами для синхронизации графа с исходными данными, но даром это не даётся.

Вендорские цифры бывают куда громче - Diffbot в старом бенчмарке 2023 года давал графу 56,2% против 16,7% у вектора на 43 enterprise-вопросах, FalkorDB заявляет 90%+ (FalkorDB blog, вендорский источник, методология 2023 года - держи поправку на заинтересованность). CEO Diffbot Майк Танг говорил, что граф «функционально обязателен для определённых классов enterprise-вопросов». Может, и так - для определённых. Но GraphRAG-Bench (ICLR 2026) - это независимая наука, и она говорит четко: граф оправдан на multi-hop и синтезе; универсальным апгрейдом retrieval он не служит.

Как понять, нужен ли граф. Если твои вопросы - это «найди пункт договора» или «какой статус заказа», граф тебе только навредит: минус 13% качества и плюс латентность. Если вопросы - это «прослеживание цепочек» и «что из чего следует через три шага», граф окупается. Пример из РФ, где он к месту: AI-ассистент, который понимает Жилищный кодекс РФ и связи между его нормами (Habr, 2026) - там переходы между статьями и есть суть задачи.

Сколько стоит построить граф знаний?

Коротко: Полная индексация Microsoft GraphRAG на корпус ~1М токенов (около 500 страниц) стоит $20-40 на gpt-4o и занимает ~45 минут; 58% всех токенов съедает LLM-извлечение сущностей. Лёгкие альтернативы - LightRAG, LazyGraphRAG - валят цену в 50-6000 раз: тот же корпус за ~$0,50 и 3 минуты ценой 70-90% качества.

Граф не берётся из воздуха. Чтобы построить его, ты прогоняешь весь корпус через LLM и просишь её вытащить сущности и связи из каждого чанка. Это и есть главная статья расходов: по разборам 2026 года, извлечение сущностей съедает около 58% всех токенов индексации. Полный Microsoft GraphRAG на ~1М токенов обходится в $20-40 на gpt-4o (в отдельных оценках - до $50-200) и работает около 45 минут (сводка технических разборов, 2026). RU-источник даёт близкий порядок: $50-200 на 100 МБ текста, win rate графа на global-запросах 70-80% (Habr, akzhankalimatov, 2025-04-29).

Актуальный статус инструмента: пакет graphrag от Microsoft - версия 3.1.0, релиз 28 мая 2026 (GitHub, microsoft/graphrag, 2026-05-28). Из свежего - убрали зависимость от NetworkX в пользу реализации на DataFrame, а сам GraphRAG и LazyGraphRAG теперь доступны через агентную платформу Microsoft Discovery. Требует Python от 3.11 до 3.13.

Дорого. Поэтому появилось семейство лёгких вариантов - LightRAG, LazyGraphRAG, Fast GraphRAG. Они снижают стоимость индексации в 50-6000 раз при сохранении или улучшении точности на global-запросах:

LightRAG индексирует тот же корпус ~1М токенов за ~$0,50 против $20-40 и за ~3 минуты против 45.
На retrieval разница ещё драматичнее: полный GraphRAG может тратить до 610 000 токенов на один запрос против <100 у LightRAG (⚠️ цифра 610k из независимых обзоров, не из документации Microsoft - как иллюстрация, не абсолют).
Качество: LightRAG выдаёт 70-90% от полного GraphRAG при ~1/100 стоимости индексации (⚠️ округлённая оценка обзоров, не строгий бенчмарк).

Врезка для тех, кто строит граф из РФ. Извлечение сущностей - это тысячи вызовов к LLM подряд: каждый чанк отправляется модели с промптом «вытащи сущности и связи». Из России эти вызовы упираются в тот же затык - гео-блок и оплата. Весь пайплайн заводится сменой двух строк: ключ и base_url на единый API агрегатора provod.ai - он совместим и с OpenAI-SDK, и с Anthropic, так что твой индексатор графа подхватит его без переписывания кода. Один ключ на все вызовы, оплата в рублях. Сам граф при этом строится и хранится на твоей стороне - provod даёт только доступ к модели, которая извлекает сущности.

Тут же прячется смежная задача - «ИИ для генерации промтов» под извлечение. Качество графа напрямую зависит от того, как ты попросишь модель размечать сущности: слабый промпт извлечения даёт рыхлый граф, и никакой retrieval его потом не спасёт. Так что перед тем как гнать весь корпус, прогони промпт извлечения на десятке чанков вручную и посмотри, что модель реально вытаскивает.

Что такое агентный RAG и петли retrieval?

Коротко: Агентный rag - это когда робот крутит петлю поиска: декомпозирует вопрос, решает что искать, ищет, оценивает найденное, при нужде переформулирует и ищет снова. Пять продакшен-паттернов: router, ReAct, plan-and-execute, multi-agent, self-RAG. Платить за это приходится 4-7x к стоимости базового RAG.

Классический RAG делает один проход: запрос - поиск - ответ. Агентный добавляет цикл и право решать. Джерри Лю из LlamaIndex описывает суть на пальцах.

«Agentic RAG allows the model to search, read a summary, realize it needs more detail, and execute a second search before answering» - Jerry Liu, CEO LlamaIndex, материалы LlamaIndex, 2026.

Живой перевод: робот поискал, прочитал сводку, понял что данных мало, переформулировал и поискал ещё раз - и только потом отвечает. Отсюда основные паттерны, которые добавляют по мере роста сложности задачи:

Self-RAG - модель генерирует спецтокены рефлексии, которые управляют тем, когда идти в поиск и как критиковать релевантность найденного перед ответом.
Corrective RAG (CRAG) - добавляет retrieval evaluator: тот оценивает качество контекста и при низкой оценке триггерит корректирующее действие (веб-поиск или переформулировку).
Adaptive RAG - роутит по сложности: простой вопрос идёт быстрым single-pass путём, сложный эскалируется в полный агентный цикл.
Router / ReAct / plan-and-execute / multi-agent - разные способы декомпозиции и оркестрации того, кто и в каком порядке ищет.

Внутри петли живёт та самая «ИИ для генерации промтов» - query rewriting. Робот берёт кривой пользовательский запрос («а что там по прошлому кварталу у того клиента») и переписывает его в чёткий поисковый промпт, иногда в несколько под-запросов. Это критично: «реальные документы содержат шум, пользовательские запросы плохо сформулированы, а косинусное сходство не понимает бизнес-логику» (Habr, «RAG от А до Я», 2026). Переписывание запроса чинит вход, прежде чем он дойдёт до поиска.

Оркеструют всё это два фреймворка. LangGraph и LangChain дошли до версии 1.0 в октябре 2025; на 2026-07-10 актуальная версия LangGraph - 1.2.9 (PyPI, 2026). LangGraph стал де-факто стандартом оркестрации stateful-агентов: граф с условным ветвлением, персистентными чекпоинтами и точками human-in-the-loop. Когда пишут «langgraph агент», имеют в виду именно это - явную стейт-машину переходов, где узлы решают, ретривить снова или отвечать. LlamaIndex (версия 0.14.23, релиз 2026-06-24) сместился к agentic document processing: его Retrieval Harness - персистентный пайплайн, который подключается к источнику, индексирует базу знаний и выдаёт агенту набор файло-подобных инструментов (semantic search, keyword search, regex grep, read). RU-сообщество зафиксировало нишевание чётко: LangGraph - под явные графы переходов, LlamaIndex - под сложный RAG и работу с данными (Habr, «Агентные фреймворки», 2026).

Теперь про цену, потому что она кусается. Агентный RAG даёт 4-7x рост стоимости против базового: иллюстрация с Habr - базовый RAG ~$500/день превращается в agentic ~$2-3K/день на сопоставимой нагрузке (Habr, akzhankalimatov, 2025-04-29; цифры одного разбора, но качественно консенсус). Каждая итерация петли - это новые вызовы LLM и новый проход реранкинга по 200-400 мс. Поэтому Adaptive RAG и роутинг по сложности прямо экономят бюджет: простые вопросы нельзя гонять через полный агентный цикл.

Какую векторную базу брать под ИИ-агента?

Коротко: Универсального ответа нет - выбирай по масштабу и по тому, есть ли у тебя DevOps. Уже есть Postgres и до ~50-100М векторов - бери pgvector. Нужен managed без возни - Pinecone. Критична латентность - Qdrant. Экстремальный масштаб 10B+ - Milvus. Встроенный гибрид из коробки - Weaviate.

Векторная база - это хранилище эмбеддингов с быстрым поиском ближайших соседей. Именно к ней робот обращается на каждом запросе. Главный совет от практиков: не бери «лучшую по бенчмаркам», потому что «в публичных бенчмарках от самих разработчиков часто оказывается, что их решение - лучшее» (Дмитрий Антипов, Habr, 2025-10-29). Декомпозируй по своей задаче.

БД	Масштаб	Латентность	Цена	Когда брать
pgvector (+pgvectorscale)	до ~50-100М векторов	p95 ~28 мс на 50М (вендорский бенч Timescale)	self-host, дёшево поверх Postgres	у тебя уже есть Postgres
Pinecone	1B+	~47 мс p99 на 1B прогретом; cold start 200-800 мс	serverless от $50/мес	нужен managed без DevOps
Qdrant	1B+	p50 ~4 мс, p99 ~2-25 мс	self-host / cloud	критична чистая латентность
Milvus (Zilliz)	10B+	масштабируемая, DiskANN	Zilliz storage $0,04/GB/мес	экстремальный масштаб
Weaviate	сотни млн+	зависит от конфигурации	self-host обычно дешевле всего	нужен встроенный гибрид

Латентности и цены - по независимым обзорам и вендорским бенчмаркам 2026, каждая цифра с оговоркой в разделах ниже.

Разложим «ИИ для роботов» по живым бизнес-сценариям, потому что «векторная база под ИИ-агента» звучит абстрактно, пока не привяжешь к делу.

Чат ИИ для юристов - поиск по судебной практике и договорам. Тут связка гибрид + реранкер обязательна: номера статей, реквизиты дел, точные формулировки вектор теряет, а BM25 ловит. Масштаб корпуса обычно средний, данные чувствительные - хороший кейс под self-hosted Qdrant или pgvector, где данные не уходят наружу.

ИИ-агент для продаж - retrieval по CRM и базе сделок. Данные меняются каждый час, значит важна дешёвая инкрементальная индексация вместо разовой сборки. Тут больно бьёт дорогой re-indexing, о котором ниже, и часто выигрывает pgvector рядом с той же транзакционной базой.

ИИ-нейросеть для студентов - поиск по конспектам и учебникам. Небольшой корпус, толерантность к латентности высокая, бюджет низкий. ChromaDB для прототипа или pgvector - и хватит, городить Milvus незачем.

ИИ для аналитики чатов - retrieval по истории переписок и тикетов. Объёмы растут быстро и линейно, тут важен масштаб и дешёвое хранение: Milvus/Zilliz на экстремальных объёмах или Qdrant с квантизацией.

Тренд, который стоит держать в голове: «в 2025 стало болезненно очевидно, что векторы - это уже тип данных, встраиваемый в мультимодельную БД, а не отдельный тип БД» (VentureBeat, «6 data predictions for 2026», 2025-12-31). То есть маятник качнулся в сторону «положи векторы рядом с обычными данными в Postgres» вместо отдельного vector-native сервиса. Для команд, которые внедряют ИИ-агентов для бизнеса без большой инфраструктурной команды, это хорошая новость - меньше движущихся частей.

pgvector или Pinecone - что выбрать в 2026?

Коротко: pgvector хорош, если у тебя уже есть Postgres и до ~50-100М векторов - но честный потолок держит только связка pgvector + pgvectorscale (DiskANN) поверх голого HNSW. Pinecone - managed, sub-50ms достижимы на большом прогретом индексе, но serverless-индексы «остывают» после 5-10 минут простоя, и первый запрос подскакивает до 200-800 мс. Считай счёт на масштабе - стартовый ценник обманчив.

Это самая частая развилка в РФ-командах, и вокруг неё больше всего мифов. Разберём по фактам.

Голый pgvector на HNSW держит весь граф индекса в памяти. На 10М векторов это уже ~40+ ГБ RAM, на 50М - сотни ГБ или деградация по latency и recall (Instaclustr, 2026). Поэтому фраза «pgvector тянет 50М» верна с оговоркой: тянет столько связка pgvector с pgvectorscale, которая добавляет StreamingDiskANN - диск-ориентированный индекс по мотивам исследования Microsoft DiskANN. Он держит индекс, который не влезает в память, с приемлемой латентностью. Актуальные версии на 2026-07-10: ядро pgvector - 0.8.5 (релиз 8 июля 2026), pgvectorscale - 0.9.0.

Вендорский бенчмарк Timescale (важно: делал сам Timescale, не независимая сторона) гонял 50М эмбеддингов Cohere по 768 измерений. Итог: pgvector+pgvectorscale дал p95 = 28 мс против p95 = 784 мс у Pinecone storage-optimized при recall 99%. Это в 28x меньше латентность и в 16x больше throughput, при этом на 75% дешевле на self-hosted EC2 (Tigerdata/Timescale blog, 2026). Цифры красивые, но помни - это бенчмарк заинтересованной стороны, воспроизводи на своих данных.

Теперь Pinecone. Тезис «sub-50ms p99» подтверждается, но с оговорками. На 1 млрд векторов 768D p99 держится около 47 мс; на 10М - около 33 мс; а вот на 100М отдельные источники дают уже 50-100 мс (обзоры perf, 2026). И главная ловушка: serverless-индексы Pinecone остывают после 5-10 минут неактивности, и латентность первого запроса подскакивает до 200-800 мс. То есть sub-50ms - это про прогретый, хорошо загруженный индекс на масштабе; робота, которого дёргают редко, ждёт другая картина. Публичной latency-SLA у Pinecone нет - все цифры из независимых тестов.

Тарифы Pinecone Serverless на 2026 (сверяй с pinecone.io на свою дату - они меняются): storage $0,33/ГБ/мес, план Standard от $50/мес, Enterprise от $500/мес, free-тир 2 ГБ. Read/write units считаются отдельно, и источники по ним расходятся - это отдельный повод свериться напрямую.

Что реально пугает - счёт на масштабе. Задокументированный кейс: RAG-чатбот на Pinecone - $50 в первый месяц, $380 во второй, $2847 в третий, после чего команда мигрировала на pgvector за $200/мес при той же нагрузке (обзор миграционных кейсов, Medium, 2026; отдельный кейс, не статистика). И миграция - это не бесплатно: другая команда потратила 40-200 инженерных часов на переезд с Pinecone на Qdrant из-за проблем с metadata filtering. Мораль: развилку решай на старте, переезжать потом дорого.

Дерево решений короткое. Есть Postgres и до ~50М векторов - pgvector + pgvectorscale, дёшево и рядом с данными. Нет DevOps и нужен managed прямо сейчас - Pinecone, но заложи cold start и растущий счёт. Нужна минимальная латентность любой ценой - Qdrant.

Как ускорить и удешевить поиск: HNSW, DiskANN, квантизация?

Коротко: Тип индекса решает, где живут векторы. HNSW - быстрый граф в памяти для средних масштабов, но дорог в пересборке. DiskANN держит индекс на диске и тянет объёмы, которые не влезают в RAM. Квантизация сжимает векторы: scalar - 4x, binary - до 32x, product - до 64x, ценой части recall.

Два рычага производительности векторного поиска - индекс и квантизация. Начнём с индекса.

HNSW - иерархический граф ближайших соседей, целиком в памяти. Быстрый recall на средних масштабах, но перестройка дорога при больших объёмах и частых апдейтах, и он прожорлив по RAM. IVF режет пространство на ячейки и ищет в ближайших - экономнее по памяти, но чуть хуже по recall. DiskANN и StreamingDiskANN - диск-ориентированные индексы от Microsoft Research: они позволяют держать индекс, не влезающий в память, с приемлемой латентностью. Именно DiskANN - основа масштабирования pgvectorscale и части деплоев Milvus.

Второй рычаг - квантизация, то есть сжатие векторов ценой точности. Механика везде одна: на квантизованных векторах делаешь грубый быстрый отбор, а top-кандидатов пересчитываешь по исходным float-векторам для финальной точности.

Тип квантизации	Сжатие	Ускорение	Потеря recall
Scalar (float32 - int8)	4x	до 2x (SIMD int8)	минимальная
Binary (1-2 бита на компонент)	до 32x	до 40x (битовые операции)	заметная, но recall 95%+ при rescoring
Product	до 64x	приоритет памяти	больше, если гонишься за экономией RAM

Источник: qdrant.tech, 2026.

Шпаргалка по цифрам. Эмбеддинги размерности 768 и выше почти всегда стоит квантизовать - иначе память улетает (Habr, 2025-10-29). Binary Quantization в Qdrant держит recall 95%+ при сжатии до 32x - для большинства задач этого хватает. Из свежего: в мае 2026 Qdrant выпустил TurboQuant - метод на базе алгоритма Google Research с ICLR 2026. Он перед сжатием поворачивает вектор, чтобы равномернее размазать дисперсию по измерениям, и даёт лучший recall, чем binary, при том же бюджете памяти (qdrant.tech, 2026). Если память - твоё узкое место, смотри в эту сторону.

Сколько стоят эмбеддинги и как их выбрать?

Коротко: Эмбеддинги считаются на каждый документ и на каждый запрос, поэтому на масштабе счёт заметный. API дёшевы в стартап-режиме ($0,02-0,13 за 1М токенов), но на потоке ~100М токенов/день self-host BGE на своём GPU выходит в разы дешевле. Выбирай по языку и домену; абсолютный балл лидерборда - слабый одиночный критерий, ведь «эмбединг = смысл, а смыслы у всех разные».

Эмбеддинг-модель превращает текст в вектор. Качество retrieval начинается именно тут: плохие эмбеддинги - и никакой реранкер потом не вытащит.

«Эмбединг = смысл. Но все мы работаем с разными смыслами, и это - большая проблема» - Дмитрий Антипов, Habr, 2025-10-29.

Смысл цитаты практический: модель, обученная на английском вебе, на русских юридических текстах «понимает» смысл иначе, чем нужно тебе. Поэтому абсолютный балл лидерборда - плохой единственный критерий.

По лидерборду MTEB (апрель 2026) в топе держатся Gemini Embedding 001 на английском и Qwen3-Embedding-8B на мультиязычных задачах. Рядом - Voyage, NV-Embed, открытый BGE-M3 с поддержкой 100+ языков (агрегаторы MTEB-данных, 2026; точные абсолютные баллы меняются еженедельно, не привязывайся к цифре). Для русского языка важнее другое. RU-сообщество фиксирует, что «февраль 2026 - точка, когда открытые модели перестали быть компромиссом»: GigaEmbeddings от Sber AI Sage и Qwen3-Embedding сравнялись по качеству на русском с проприетарными API (vc.ru, «Эмбеддинги для русского языка в 2026»).

Цены на модели - и генерации, и эмбеддингов:

Модель	Тип	Цена	Примечание
OpenAI text-embedding-3-small	эмбеддинги (API)	$0,02 / 1М токенов	1536D
OpenAI text-embedding-3-large	эмбеддинги (API)	$0,13 / 1М токенов	3072D, batch вдвое дешевле
Cohere embed-v4	эмбеддинги (API)	~$0,12 / 1М токенов	контекст 128k, мультимодальная
Voyage-4	эмбеддинги (API)	$0,06 / 1М токенов	voyage-4-lite - $0,02
Qwen3-Embedding-8B	эмбеддинги (открытая)	$0,01 / 1М или self-host	Apache 2.0, Matryoshka-размерность
BGE-M3	эмбеддинги (self-host)	~$500/мес на GPU при 100М токенов/день	нужен свой GPU, 100+ языков
Через provod.ai: gemini-3.1-flash-lite	генерация ответа (LLM)	0,019 / 0,117 ₽ за 1000 токенов	вход / выход, в рублях 1:1
Через provod.ai: deepseek-v4-flash	генерация ответа (LLM)	0,011 / 0,022 ₽ за 1000 токенов	дешевле остальных в этой таблице на генерацию
Через provod.ai: claude-opus-4.8	генерация ответа (LLM)	0,39 / 1,95 ₽ за 1000 токенов	флагман под сложные ответы

Долларовые цены эмбеддингов - обзоры pricing 2026, сверять с вендорами. ₽-строки - тарифы provod.ai, 1:1 с официальными, оплата в рублях; это цена именно LLM-вызовов (генерация ответа, реранкинг через модель, извлечение сущностей), отдельного эмбеддинг-сервиса тут нет.

Развилка «API или self-host» решается объёмом. Production-нагрузка ~100М токенов/день на text-embedding-3-large - это ~$13 000/мес; тот же объём на self-hosted BGE-M3 с амортизацией GPU - ~$500/мес (обзор рынка, 2026, иллюстративная оценка). Разница на порядок, но за неё платишь DevOps-ресурсом и GPU для ИИ. Для маленького проекта API проще и дешевле в абсолюте; для потока - считай точку перехода на self-host заранее.

Как собрать этот пайплайн из России?

Коротко: Собрать RAG из РФ реально. Векторную БД поднимаешь на российском облаке или self-hosted, эмбеддинги гоняешь на арендованном GPU (A100 от ~211,77 ₽/час, Immers.cloud), а доступ к топовым LLM для генерации и извлечения закрываешь через агрегатор с оплатой в рублях. Честная граница: агрегатор даёт модели, но БД, граф и self-host - на тебе.

Пройдёмся по пайплайну по слоям и посмотрим, что где живёт в российских реалиях - как собрать «ИИ для роботов» под свои данные, не упираясь в гео-блок.

Векторная база. pgvector рядом с Postgres на Selectel, Cloud.ru или self-hosted; Qdrant self-hosted; managed Pinecone - технически доступен, но биллинг в валюте. Для команды из РФ проще всего pgvector или self-hosted Qdrant на российском облаке - данные не уходят наружу, оплата в рублях.

Self-hosted эмбеддинги и реранкер. BGE-M3, Qwen3-Embedding или российская GigaEmbeddings гоняются на арендованном GPU. Аренда реальна и недорога: NVIDIA A100 80GB - от 211,77 ₽/час на минимальной конфигурации (Immers.cloud, прямая проверка сайта, 2026-07-11), у HOSTKEY есть акционные входные тарифы. Одной A100 хватает для inference эмбеддингов; fine-tuning дороже. Расплата - нужен DevOps, которого у многих команд нет.

Доступ к топовым LLM. Тут и всплывает главный затык: генерация ответа, реранкинг через модель, извлечение сущностей для графа, LLM-as-judge оценка, планирование в агентной петле - всё это вызовы к Claude, GPT, Gemini. Из РФ прямой доступ и оплата к ним закрыты.

Как собрать доступ к моделям из РФ.

Регистрируешься в агрегаторе, пополняешь баланс в рублях (карта РФ, СБП или счёт с закрывающими для юрлиц).

Берёшь один API-ключ на все модели.

Меняешь в своём коде две строки - ключ и base_url:
from openai import OpenAI

client = OpenAI(
    api_key="provod-...",
    base_url="https://api.provod.ai/v1",  # OpenAI-совместимый эндпоинт
)

# генерация ответа поверх найденных чанков
resp = client.chat.completions.create(
    model="claude-opus-4.8",
    messages=[
        {"role": "system", "content": "Отвечай строго по контексту."},
        {"role": "user", "content": f"Контекст:\n{retrieved}\n\nВопрос: {query}"},
    ],
)
Claude Code, Cursor и n8n подхватывают тот же ключ без переписывания кода - совместимость с OpenAI и Anthropic. Подключить модели из РФ.

Честная граница. provod.ai закрывает доступ и оплату моделей. Он НЕ хостит твою векторную БД, НЕ строит и НЕ хранит граф знаний, НЕ гоняет self-hosted эмбеддинги на GPU и НЕ пишет за тебя оркестрацию LangGraph. База, граф, чанкинг и агентный код - на команде. Агрегатор - это топливо (модели), а сам retrieval-движок собираешь ты.

Так это ложится на живые задачи. ИИ-агент для продаж по CRM: pgvector рядом с базой сделок, эмбеддинги через API или self-host, генерация ответа через агрегатор в рублях - и бухгалтерия получает закрывающие. Чат ИИ для юристов по судебной практике: self-hosted Qdrant, чтобы данные не уходили наружу, гибрид с реранкером под точные реквизиты, LLM для формулировки ответа через тот же единый ключ. В обоих случаях инфраструктуру ты держишь у себя, а вопрос «как легально платить за топовую модель из РФ» снят.

7 граблей RAG, которые всплывают в проде

Коротко: Наивный RAG красиво работает на демо и разваливается на проде. Семь типовых граблей: битый чанкинг, «lost in the middle», косинус без бизнес-логики, дорогой re-indexing, over-engineering графом, боль миграции между вендорами и уверенные галлюцинации при плохом поиске. Почти все лечатся на этапе retrieval - смена модели тут не поможет.

Собрал грабли из свежих разборов и РФ-практики - с парами «должно / не должно».

1. Чанкинг рвёт контекст. Нарезка по длине ломает кореференции: «этот метод», «данный параметр» теряют, к чему относятся. Крупные чанки тащат шум, мелкие недодают контекста - оба ведут к галлюцинациям (обзоры по chunking, 2026). На русском больнее: многие готовые чанкеры спотыкаются, потому что токенайзеры считают его побочным языком (Habr, 2026). Должно: семантический чанкинг с оглядкой на структуру документа. Не должно: слепая нарезка по N символов.

2. Lost in the middle. У LLM устойчивая U-образная кривая точности по позиции факта в длинном контексте: начало и конец помнит, середину теряет. Простое расширение context window это не чинит (обзоры, 2026). Должно: реранкер поднимает лучшее в начало, компрессия убирает шум. Не должно: пихать 50 чанков в промпт и надеяться.

3. Косинус не понимает бизнес-логику. «Реальные документы содержат шум, запросы плохо сформулированы, а косинусное сходство не понимает бизнес-логику» (Habr, «RAG от А до Я», 2026). Должно: query rewriting, гибрид, multi-stage retrieval. Не должно: полагаться на голый вектор.

4. Дорогой re-indexing. Наивный RAG переэмбеддит весь документ при правке одного чанка. Умные diff-подходы срезают объём переэмбеддинга на ~77%, но из коробки этого почти нигде нет - команды натыкаются постфактум, когда апдейты контента становятся дорогими (академический обзор, 2026). Должно: инкрементальная индексация по diff. Не должно: пересобирать всё на каждую правку.

5. Over-engineering графом. Прямо подтверждено GraphRAG-Bench (ICLR 2026): граф на простом fact-lookup хуже обычного RAG на 13,4%, на time-sensitive - на 16,6%, плюс graph tax по латентности. Команды ставят граф «на всякий случай» и теряют качество (arXiv 2506.05690). Должно: граф только под multi-hop. Не должно: graphrag «чтобы было».

6. Боль миграции между вендорами. Переезд с Pinecone на Qdrant из-за metadata filtering стоил команде 40-200 инженерных часов (обзор кейсов, Medium, 2026). Должно: выбрать БД на старте по задаче. Не должно: брать «модную» и переезжать через полгода.

7. Уверенные галлюцинации при плохом retrieval. Когда поиск отдаёт нерелевантные, но правдоподобные чанки, робот генерирует уверенный неверный ответ - опаснее явного отказа (Habr, 2026). Должно: CRAG-оценка релевантности и фолбэк «не знаю». Не должно: доверять любому ответу, раз он звучит гладко.

Общий знаменатель всех семи сформулировал akzhankalimatov на Habr (2025-04-29): главная ошибка команд - лезть в сложность до того, как измеришь, где система реально ломается; выбор фреймворка тут вторичен. Сначала померь, где ломается retrieval, потом достраивай слой под конкретную поломку.

Частые вопросы

Коротко: Быстрые ответы на то, что чаще всего гуглят про graphrag, агентный rag, выбор векторной базы, GPU под эмбеддинги и «ИИ для роботов» в бизнес-смысле. Короткая версия всей статьи: начинай с гибридного поиска, граф и агентные петли добавляй под конкретную нагрузку, а базу выбирай по масштабу и наличию DevOps. Первое предложение каждого ответа - прямой ответ, детали дальше.

Что такое graphrag простыми словами?
Graphrag - это RAG, который перед поиском строит из документов граф сущностей и связей и ходит по нему вместо плоского набора чанков. Он выигрывает на multi-hop и global-запросах, где ответ размазан по многим документам (win rate 72-83% на global sensemaking, Microsoft, 2026). Но на простом поиске факта он хуже обычного RAG на 13,4% (GraphRAG-Bench, ICLR 2026), плюс дорого индексируется ($20-40 за 1М токенов) - ставь его только под связанные данные.

Агентный rag - это что?
Агентный rag - это RAG, где ИИ-агент (программный робот) циклически уточняет поиск: сначала ищет, читает найденное, при нехватке данных сам меняет формулировку запроса и ищет ещё раз, и только тогда отвечает. Паттерны - self-RAG, CRAG, adaptive RAG, оркеструются через LangGraph. Платишь за это 4-7x к стоимости базового RAG, поэтому простые вопросы через полный агентный цикл не гоняют.

Какую векторную базу брать под ИИ-агента?
Бери по масштабу и наличию DevOps: уже есть Postgres и до ~50-100М векторов - pgvector с pgvectorscale; нужен managed без возни - Pinecone (заложи cold start); критична латентность - Qdrant; экстремальный масштаб 10B+ - Milvus. Универсального лидера нет, и «лучшая по бенчмаркам» от самого вендора - плохой критерий (Habr, 2025-10-29).

Нужен ли GPU для ИИ-эмбеддингов?
GPU нужен только если гонишь эмбеддинги self-hosted (BGE-M3, Qwen3-Embedding, GigaEmbeddings) - тогда бери в аренду, A100 от 211,77 ₽/час (Immers.cloud, 2026). Если используешь эмбеддинги через API (OpenAI, Cohere, Voyage) - GPU не нужен вообще, всё считается на стороне вендора. Из РФ доступ к таким API и к LLM-генерации закрывает агрегатор нейросетей provod.ai: единый ключ, оплата в рублях, без VPN и зарубежных карт, для юрлиц - договор и закрывающие. Self-host эмбеддингов и хостинг БД при этом остаются на тебе.

Graph RAG или обычный RAG - что лучше?
Для большинства задач лучше обычный гибридный RAG (dense + BM25 + реранкинг): он дешевле, быстрее и на простом поиске точнее графа. Graph RAG лучше только на multi-hop и синтезе информации из многих узлов - там он даёт +4,5% глубины рассуждения (HotpotQA, ICLR 2026). Если твои вопросы - «найди пункт» и «какой статус», бери обычный; если «проследи цепочку через три шага» - граф. Так что «ИИ агенты для бизнеса» чаще стартуют с гибрида, а граф добавляют позже под конкретную нагрузку.

Движок retrieval ты собираешь сам, а топливо к нему бери готовым. На provod.ai флагманы Claude, GPT, Gemini, DeepSeek и Qwen живут в одном чате и за единым API, с оплатой рублями с карты РФ и закрывающими для юрлиц. Без VPN и наценки, модель переключается одной строкой. Базу, граф и self-host эмбеддинги держишь у себя - доступ к моделям не изобретаешь.

Источники

VentureBeat, Daulet Amirkhanov, «Architectural patterns for graph-enhanced RAG», май 2026
VentureBeat, Sean Michael Kerner, «Enterprise RAG rebuild / hybrid retrieval intent tripled», 2026-05-18
VentureBeat, «6 data predictions for 2026», 2025-12-31
Anthropic Engineering, «Contextual Retrieval», 2024-09 (актуально цитируется в 2026)
arXiv 2506.05690, «When to use Graphs in RAG» / GraphRAG-Bench, ICLR 2026, версия 2026-02-22
arXiv 2404.16130, Microsoft, «From Local to Global», 2024 (цитируется в обзорах 2026)
GitHub, microsoft/graphrag 3.1.0, релиз 2026-05-28
Timescale / Tigerdata blog, бенчмарк pgvectorscale vs Pinecone (вендорский), 2026
SiliconANGLE, интервью с Andre Zayarni (CEO Qdrant) и раунд Series B, 2026-03-12
Zilliz Cloud / PR Newswire, анонс тарифов хранения, вступил в силу 2026-01-01
Habr, Дмитрий Антипов, «Выбираем векторную БД для AI-агентов и RAG», 2025-10-29
Habr, «Возвращение RAG в 2026 году» (перевод, оригинал SteadyKestrel, перевод Ксения Мосеенкова), 2026-02-23
Habr, akzhankalimatov, «10 актуальных RAG-подходов», 2025-04-29
Habr, «RAG от А до Я: шпаргалка архитектора», 2026-06
Habr, блог Alpina Digital, «RAG в enterprise: 70-80% проблем сидят в данных, не в модели», 2026
qdrant.tech, документация по квантизации и TurboQuant, 2026
Immers.cloud, цены на аренду GPU A100 (прямая проверка), 2026-07-11
DTF, «Как получить доступ к OpenAI в России», проверено 2026-07-11
PyPI / GitHub, версии pgvector 0.8.5 (2026-07-08), pgvectorscale 0.9.0, graphrag 3.1.0, langgraph 1.2.9, llama-index 0.14.23 (прямая проверка), 2026-07-11

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

Код, сложное рассуждение, поиск, длинные документы и генерация медиа требуют разных инструментов: переключайте модель, сохраняя API, баланс и инфраструктуру команды.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Сравнивайте качество и стоимость без скрытой надбавки агрегатора: цены идут 1:1 с официальными тарифами провайдеров, поэтому выбор определяется задачей, а не лишней комиссией provod.ai.

Выберите модель для своего сценария: форма регистрации · цены на модели · защита данных по 152-ФЗ · главная provod.ai

DEV Community