С вас вопросы, с нас ответы. Часть 16
Отвечаем на популярные вопросы про AI System Design
Консультирует:
Алексей Жиряков, исполнительный директор Сбер Дивизиона генеративного AI
Навигация:
- Что такое AI System Design и чем он отличается от классического System Design
- Из каких компонентов обычно состоит современная AI-система
- Что такое RAG и почему он стал стандартом для AI-приложений
- Когда стоит использовать готовую LLM, а когда обучать собственную модель
- Как выбрать между OpenAI, Anthropic, Gemini и open-source моделями
- Как повысить качество ответов LLM без дообучения модели
- Как устроено хранение и поиск знаний в RAG-системах
- Что такое векторные базы данных и как они работают
- Как выбрать между Pinecone, Weaviate, Qdrant и PostgreSQL pgvector
1. Что такое AI System Design и чем он отличается от классического System Design?
Классический System Design упирается в CPU, память и диск. У AI-подсистемы кончается другое, и этих ресурсов ровно четыре.
Это именно бюджеты: каждый ограничен, и каждое решение тратит один, чтобы сэкономить другой. Кэш покупает деньги за свежесть. Роутер покупает деньги за правду. Локальная модель покупает доверие за время и деньги.
Отсюда первое практическое отличие. Вопрос «нужен ли нам роутер» ответа не имеет. Ответ имеет другой вопрос: готовы ли мы купить деньги ценой правды на этом классе запросов и кто подпишет порог.
Второе отличие: стоимость запроса известна только после ответа. Число выходных токенов заранее не знает никто, поэтому честных схем лимита ровно две. Оценочная, по предрасчёту промпта и потолку длины ответа. Либо точный учёт по факту с допустимым перерасходом. Третьей нет. Жёсткий лимит расходов — обещание, которое нельзя выполнить.
Третье: «200 OK» перестаёт быть критерием. У ответа появляются свойства: точность, свежесть, право промолчать, приватность, радиус взрыва. У каждого нужна измеримая формулировка и один владелец, а не «команда».
Четвёртое: для стриминга одна total latency не описывает ничего. Два ответа с одинаковым итоговым временем воспринимаются как быстрый и как зависший, если у них разный TTFT. Считать надо связку: время до первого токена, межтокенную задержку, время до последнего.
Простая проверка, что вы проектируете AI-систему, а не переписываете прокси: в вашем документе у каждого из четырёх бюджетов стоит единица измерения и фамилия.
- Ёмкость и деньги: токены, квота провайдера, GPU под свою модель. Мера не «запросов в секунду», а сколько стоит один решённый запрос.
- Время: сколько пользователь ждёт первый токен, сколько печатается ответ и сколько всё это время занят слот.
- Правда: можно ли опираться на ответ. Точность, свежесть данных, право модели промолчать вместо выдумки.
- Доверие: что системе разрешено видеть и делать. Чьи данные уходят наружу, что происходит без человека, каков радиус взрыва.
Это именно бюджеты: каждый ограничен, и каждое решение тратит один, чтобы сэкономить другой. Кэш покупает деньги за свежесть. Роутер покупает деньги за правду. Локальная модель покупает доверие за время и деньги.
Отсюда первое практическое отличие. Вопрос «нужен ли нам роутер» ответа не имеет. Ответ имеет другой вопрос: готовы ли мы купить деньги ценой правды на этом классе запросов и кто подпишет порог.
Второе отличие: стоимость запроса известна только после ответа. Число выходных токенов заранее не знает никто, поэтому честных схем лимита ровно две. Оценочная, по предрасчёту промпта и потолку длины ответа. Либо точный учёт по факту с допустимым перерасходом. Третьей нет. Жёсткий лимит расходов — обещание, которое нельзя выполнить.
Третье: «200 OK» перестаёт быть критерием. У ответа появляются свойства: точность, свежесть, право промолчать, приватность, радиус взрыва. У каждого нужна измеримая формулировка и один владелец, а не «команда».
Четвёртое: для стриминга одна total latency не описывает ничего. Два ответа с одинаковым итоговым временем воспринимаются как быстрый и как зависший, если у них разный TTFT. Считать надо связку: время до первого токена, межтокенную задержку, время до последнего.
Простая проверка, что вы проектируете AI-систему, а не переписываете прокси: в вашем документе у каждого из четырёх бюджетов стоит единица измерения и фамилия.
2. Из каких компонентов обычно состоит современная AI-система?
Формула «LLM плюс RAG» описывает демо. Система состоит из двух слоёв, и они обычно принадлежат разным командам.
Продуктовый слой — фича внутри живого продукта:
Платформенный слой — контур, через который эта фича и ещё десятки команд ходят в модели:
Здесь и происходит главная подмена: поставим наш обычный шлюз и включим плагин. Не выйдет.
Маршрутизация требует парсинга тела. Решение зависит от поля с именем модели, длины промпта, наличия инструментов и флага стриминга, а не от метода, пути и заголовков.
Единица лимита — токен и деньги, а не запрос. «1000 запросов в минуту» здесь не защищает ничего: короткий запрос и запрос с большим контекстом отличаются по цене на три порядка.
И стоимость известна только после ответа, со всеми следствиями из предыдущего вопроса.
Главное свойство контура на схемах обычно не рисуют. Не должно быть ни одной сплошной линии от клиента напрямую к вендору. Появилась, и все обещания про учёт, квоты и класс данных для этого пути перестали действовать.
Обратная сторона очевидна: шлюз становится единой точкой отказа. Вы забрали у приложений ключи, значит при его падении AI теряют все команды разом. Это проговаривают вслух и проектируют аварийный путь заранее, а не обнаруживают в инциденте
Продуктовый слой — фича внутри живого продукта:
- место вызова относительно живого эндпоинта: синхронно в запросе, джоба с уведомлением или батч. Это три разных архетипа с разными SLO и разной ценой ошибки, мешать их в одной схеме нельзя;
- сборка контекста: retrieval, живое чтение источников правды, раскладка промпта, память между обращениями;
- модель как внешняя зависимость с закреплённой версией;
- инструменты по стандартному протоколу MCP, а не самописными обёртками: у протокола есть версионированная спецификация, и подключение становится контрактом;
- проверки на ответе и право промолчать;
- лестница деградации, где обязательна ступень «AI выключен, продукт жив»;
- промпт и индекс как релизные объекты вашего CI, а не файлы в конфиге.
Платформенный слой — контур, через который эта фича и ещё десятки команд ходят в модели:
- клиенты;
- виртуальные ключи и квоты;
- маршруты и алиасы;
- кэш;
- апстримы.
Здесь и происходит главная подмена: поставим наш обычный шлюз и включим плагин. Не выйдет.
Маршрутизация требует парсинга тела. Решение зависит от поля с именем модели, длины промпта, наличия инструментов и флага стриминга, а не от метода, пути и заголовков.
Единица лимита — токен и деньги, а не запрос. «1000 запросов в минуту» здесь не защищает ничего: короткий запрос и запрос с большим контекстом отличаются по цене на три порядка.
И стоимость известна только после ответа, со всеми следствиями из предыдущего вопроса.
Главное свойство контура на схемах обычно не рисуют. Не должно быть ни одной сплошной линии от клиента напрямую к вендору. Появилась, и все обещания про учёт, квоты и класс данных для этого пути перестали действовать.
Обратная сторона очевидна: шлюз становится единой точкой отказа. Вы забрали у приложений ключи, значит при его падении AI теряют все команды разом. Это проговаривают вслух и проектируют аварийный путь заранее, а не обнаруживают в инциденте
3. Что такое RAG и почему он стал стандартом для AI-приложений?
RAG — это подача фактов модели в момент ответа, а не зашивание их в веса: поиск по вашим данным, найденное в контекст, ответ с цитатой.
Чаще всего звучит так: RAG — прошлый год, сейчас речь про агентов. Верно наполовину: умер наивный RAG как самостоятельный проект. Схема «векторный поиск по вопросу, топ-5 в промпт» проваливает артикулы, отрицания и формулировки не словами корпуса. Но retrieval не умер, он сменил место. Во-первых, стал инструментом внутри агентского цикла: план, поиск, критика найденного, переформулировка — до уверенности или до конца бюджета проходов. Во-вторых, стал серверным инструментом у провайдеров. Документация Gemini API прямым текстом называет File Search реализацией retrieval-augmented generation: Google сам режет на чанки и индексирует ваши данные. Разница с самосборным стеком не в идее, а в том, кто владеет чанкером, эмбеддером и порогами.
Длинный контекст его тоже не заменил, и причина техническая. С ростом числа токенов способность модели точно достать нужный факт из окна падает, и это наблюдается у всех обследованных моделей, а не у отдельной. Это и есть context rot. Отсюда дисциплина context engineering: задача не «как влезет побольше», а минимальный набор высокосигнальных токенов. Наказание двойное: сначала качеством, потом деньгами — в прайсе OpenAI ставка за длинный контекст ровно вдвое выше по входу.
Стандартом retrieval стал из-за проверяемости, а не качества. Обученная на корпусе модель отвечает уверенно и без цитаты: такой ответ нельзя ни проверить, ни откатить. Retrieval даёт худший тон и лучшую проверяемость — в корпоративном контуре обмен выгодный.
Дефолт конвейера — четыре звена: переписывание запроса, затем гибридный поиск со слиянием, затем переранжирование cross-encoder'ом, затем переспрос ретривера.
Не векторный поиск против лексического, а вместе, с весами и слиянием списков. У звеньев есть цена. На корпусе нашего курса — 4,1 млн чанков, один узел, тёплый индекс, медиана — это 180 + 120 + 240 + 280 = 820 мс до первого токена в худшем случае, когда нужен переспрос; без него 540 мс. Числа учебные.
Спор в 2026 идёт не «RAG или агенты», а сколько retrieval, контекста и памяти. Задача бюджетная.
Чаще всего звучит так: RAG — прошлый год, сейчас речь про агентов. Верно наполовину: умер наивный RAG как самостоятельный проект. Схема «векторный поиск по вопросу, топ-5 в промпт» проваливает артикулы, отрицания и формулировки не словами корпуса. Но retrieval не умер, он сменил место. Во-первых, стал инструментом внутри агентского цикла: план, поиск, критика найденного, переформулировка — до уверенности или до конца бюджета проходов. Во-вторых, стал серверным инструментом у провайдеров. Документация Gemini API прямым текстом называет File Search реализацией retrieval-augmented generation: Google сам режет на чанки и индексирует ваши данные. Разница с самосборным стеком не в идее, а в том, кто владеет чанкером, эмбеддером и порогами.
Длинный контекст его тоже не заменил, и причина техническая. С ростом числа токенов способность модели точно достать нужный факт из окна падает, и это наблюдается у всех обследованных моделей, а не у отдельной. Это и есть context rot. Отсюда дисциплина context engineering: задача не «как влезет побольше», а минимальный набор высокосигнальных токенов. Наказание двойное: сначала качеством, потом деньгами — в прайсе OpenAI ставка за длинный контекст ровно вдвое выше по входу.
Стандартом retrieval стал из-за проверяемости, а не качества. Обученная на корпусе модель отвечает уверенно и без цитаты: такой ответ нельзя ни проверить, ни откатить. Retrieval даёт худший тон и лучшую проверяемость — в корпоративном контуре обмен выгодный.
Дефолт конвейера — четыре звена: переписывание запроса, затем гибридный поиск со слиянием, затем переранжирование cross-encoder'ом, затем переспрос ретривера.
Не векторный поиск против лексического, а вместе, с весами и слиянием списков. У звеньев есть цена. На корпусе нашего курса — 4,1 млн чанков, один узел, тёплый индекс, медиана — это 180 + 120 + 240 + 280 = 820 мс до первого токена в худшем случае, когда нужен переспрос; без него 540 мс. Числа учебные.
Спор в 2026 идёт не «RAG или агенты», а сколько retrieval, контекста и памяти. Задача бюджетная.
4. Когда стоит использовать готовую LLM, а когда обучать собственную модель?
Под своей моделью обычно понимают три разных решения: локальный запуск чужих открытых весов, дообучение адаптером поверх чужой базы и обучение модели с нуля. Смешивать их нельзя. Цена отличается на порядки.
Порядок выбора задаётся лестницей из пяти ступеней, и подниматься можно только когда предыдущая замерена и не вытянула:
Дообучение — четвёртая ступень. Оно учит форме и навыку: формату вывода, стилю разметки, узкой классификации, которую не описать инструкцией. Фактам оно не учит. Новый факт требует нового цикла обучения, а цитату дать всё равно нечем. Факты живут на третьей ступени.
Цена четвёртой ступени — не GPU-часы, а контур вокруг них: разметка, цикл обучения, отдельный релизный процесс, свой набор для регрессии. Есть неприятное свойство: адаптер не переносится на другую базовую модель. Базовую модель снимают с поддержки по чужому графику, и каждая такая смена означает обучение заново.
Пятая ступень, модель с нуля, оправдана в одном случае: когда модель и есть продукт, а не деталь продукта. По деньгам и срокам это другой порядок величины и другая команда.
Отдельно локальный запуск открытых весов. Это решение не про качество, а про доверие: класс данных, юрисдикция, обязательный контур обработки. Поле здесь живое: по фактическим загрузкам массовый сегмент держат gpt-oss-120b и gpt-oss-20b, по свежести — DeepSeek-V4-Pro на 1,6 трлн параметров, вышедшая в апреле 2026, и GLM-5.2 на 753 млрд, вышедшая в июне 2026. Обе — MoE с миллионным окном, и у GLM-5.2 на площадке весов уже висит преемник, GLM-5.3. Главное свойство этого поля: карточка модели, на которую вы сослались в архитектурном документе, устаревает быстрее самого документа. Поэтому в документе фиксируют не имя модели, а требование, которому модель обязана соответствовать.
Проверка, которая экономит квартал: спросите, что именно изменится в ответах после дообучения. Если ответ «они станут точнее», выбрана не та ступень, и почти всегда задача решается на третьей.
Порядок выбора задаётся лестницей из пяти ступеней, и подниматься можно только когда предыдущая замерена и не вытянула:
- детерминированное правило;
- промпт;
- retrieval;
- дообучение и адаптеры;
- своя модель.
Дообучение — четвёртая ступень. Оно учит форме и навыку: формату вывода, стилю разметки, узкой классификации, которую не описать инструкцией. Фактам оно не учит. Новый факт требует нового цикла обучения, а цитату дать всё равно нечем. Факты живут на третьей ступени.
Цена четвёртой ступени — не GPU-часы, а контур вокруг них: разметка, цикл обучения, отдельный релизный процесс, свой набор для регрессии. Есть неприятное свойство: адаптер не переносится на другую базовую модель. Базовую модель снимают с поддержки по чужому графику, и каждая такая смена означает обучение заново.
Пятая ступень, модель с нуля, оправдана в одном случае: когда модель и есть продукт, а не деталь продукта. По деньгам и срокам это другой порядок величины и другая команда.
Отдельно локальный запуск открытых весов. Это решение не про качество, а про доверие: класс данных, юрисдикция, обязательный контур обработки. Поле здесь живое: по фактическим загрузкам массовый сегмент держат gpt-oss-120b и gpt-oss-20b, по свежести — DeepSeek-V4-Pro на 1,6 трлн параметров, вышедшая в апреле 2026, и GLM-5.2 на 753 млрд, вышедшая в июне 2026. Обе — MoE с миллионным окном, и у GLM-5.2 на площадке весов уже висит преемник, GLM-5.3. Главное свойство этого поля: карточка модели, на которую вы сослались в архитектурном документе, устаревает быстрее самого документа. Поэтому в документе фиксируют не имя модели, а требование, которому модель обязана соответствовать.
Проверка, которая экономит квартал: спросите, что именно изменится в ответах после дообучения. Если ответ «они станут точнее», выбрана не та ступень, и почти всегда задача решается на третьей.
5. Как выбрать между OpenAI, Anthropic, Gemini и open-source моделями?
Вопрос поставлен неверно, и это самая полезная часть ответа: выбирают не модель, а портфель и маршруты.
Маршруты устроены как уровни кэша: дешёвая модель закрывает частый случай, сильная включается на редком, а на исчерпанном бюджете система отказывает, а не пробует подороже. Аналогия ломается в одном: у кэша промах бесплатен по качеству, у маршрута он стоит правды. Поэтому в строке маршрута стоит не только потолок цены, но и планка качества.
Решают выбор не бенчмарки, а класс данных запроса, контур обработки и юрисдикция. Сначала разметка данных, потом маршрут находится сам. Вариантов три: локальная модель, затем резидентное облако, затем внешняя модель с договорной политикой невыдачи данных.
Третий часто закрывает требование дешевле первых двух. Резидентность уже не только self-hosting: у провайдеров есть параметр региона обработки и наценка за него.
Ориентир по железу даёт арифметика «веса плюс KV-кэш на запрос»: в fp16 одна карта — модели примерно 27−33 млрд параметров; две-четыре карты — около 100 млрд; восемь карт — фронтир. Разрядность двигает границу сильнее всего: gpt-oss-120b на 117 млрд параметров в MXFP4 официально рассчитан на одну 80-гигабайтную карту. Фраза «нам нужны восемь карт» обычно значит, что запросы не разложены по классам.
Про экономию, которую продают с роутером. Цифру цитируют по проекту RouteLLM: до 85% сокращения стоимости при 95% качества сильной модели. Это заявленный потолок на конкретном наборе задач, не ваш прогноз. Смотрите на базлайн: если сегодня всё идёт в дешёвую модель, роутер не сэкономит, а доплатит.
И главное про деньги: не закладывайтесь на то, что токены сами подешевеют. Сигналы разнонаправленные. В прайсе Gemini API у линейки Flash вводные тарифы удваиваются с 1 января 2027: вход и выход ровно вдвое. OpenAI ввёл двойную ставку за длинный контекст и наценку 10% за выбранный регион обработки. Часть денег ушла из токенов: веб-поиск как инструмент стоит от 10 до 25 долларов за тысячу вызовов в зависимости от провайдера и режима, плюс токены найденного. Кэш тоже не бесплатный трюк: запись дороже обычного входа, а у Google есть плата за время хранения. Считайте стоимость решённой задачи.
Маршруты устроены как уровни кэша: дешёвая модель закрывает частый случай, сильная включается на редком, а на исчерпанном бюджете система отказывает, а не пробует подороже. Аналогия ломается в одном: у кэша промах бесплатен по качеству, у маршрута он стоит правды. Поэтому в строке маршрута стоит не только потолок цены, но и планка качества.
Решают выбор не бенчмарки, а класс данных запроса, контур обработки и юрисдикция. Сначала разметка данных, потом маршрут находится сам. Вариантов три: локальная модель, затем резидентное облако, затем внешняя модель с договорной политикой невыдачи данных.
Третий часто закрывает требование дешевле первых двух. Резидентность уже не только self-hosting: у провайдеров есть параметр региона обработки и наценка за него.
Ориентир по железу даёт арифметика «веса плюс KV-кэш на запрос»: в fp16 одна карта — модели примерно 27−33 млрд параметров; две-четыре карты — около 100 млрд; восемь карт — фронтир. Разрядность двигает границу сильнее всего: gpt-oss-120b на 117 млрд параметров в MXFP4 официально рассчитан на одну 80-гигабайтную карту. Фраза «нам нужны восемь карт» обычно значит, что запросы не разложены по классам.
Про экономию, которую продают с роутером. Цифру цитируют по проекту RouteLLM: до 85% сокращения стоимости при 95% качества сильной модели. Это заявленный потолок на конкретном наборе задач, не ваш прогноз. Смотрите на базлайн: если сегодня всё идёт в дешёвую модель, роутер не сэкономит, а доплатит.
И главное про деньги: не закладывайтесь на то, что токены сами подешевеют. Сигналы разнонаправленные. В прайсе Gemini API у линейки Flash вводные тарифы удваиваются с 1 января 2027: вход и выход ровно вдвое. OpenAI ввёл двойную ставку за длинный контекст и наценку 10% за выбранный регион обработки. Часть денег ушла из токенов: веб-поиск как инструмент стоит от 10 до 25 долларов за тысячу вызовов в зависимости от провайдера и режима, плюс токены найденного. Кэш тоже не бесплатный трюк: запись дороже обычного входа, а у Google есть плата за время хранения. Считайте стоимость решённой задачи.
6. Как повысить качество ответов LLM без дообучения модели?
Три нижние ступени лестницы закрывают почти всё. Если вопрос решается справочником или фильтром каталога, модель не нужна. Если фактов мало и они в запросе, работает промпт: раскладка, формат, право промолчать. Если фактов много и они меняются, retrieval.
Поднять качество нельзя, пока вы его не измеряете. Измеряют почти всегда не так.
Начните не с метрик, а с разбора: 50−100 реальных диалогов, прочитать целиком, выписать каждую ошибку своими словами, сгруппировать и посчитать. Если 60% ошибок — подстановка цены из другого варианта товара, главная метрика про цену, а не «полезность ответа».
Вердикты делайте бинарными. Шкала 1−5 не операционализируется: тройка одного проверяющего не равна тройке другого. Факты проверяет детерминированный проверяющий, а не судья-модель: цену, срок доставки и наличие обязательной оговорки сравнивают с источником. Судье оставьте тон, на выборке. Молчание и отказ — полноправные случаи набора.
Качество формулируется как доля: не менее 85% ответов проходят порог. При тысяче обращений в сутки это 150 непрошедших в сутки, живые люди с ответом, который ваша же система считает плохим. Стабильность считается, а не ощущается: при 75% успеха за попытку три подряд дают около 42%.
Отдельный рычаг 2026 года — работа с контекстом. Здесь путают три разные вещи, у каждой свой отказ. Очистка выбрасывает из окна отработавшие вызовы инструментов. Компакция сворачивает историю в пересказ. Память выносит знание наружу окна и возвращает его адресно. Дефолт сместился к отложенной подаче: не грузить всё заранее, а давать модели оглавление и инструмент дочитать нужное.
И контринтуитивное: не бросайтесь сжимать контекст ради экономии. Сжатие вырезает в первую очередь дешёвые токены, читавшиеся из кэша, и переупаковывает начало промпта, обнуляя попадание в кэш префикса. На учебных числах нашего курса минус 38% входных токенов дали не экономию, а рост счёта за миллион входных токенов на 8,5%, а при дисциплине кэша 90% — на 75%: дешёвый кэшированный вход подменился дорогим некэшированным.
Поднять качество нельзя, пока вы его не измеряете. Измеряют почти всегда не так.
Начните не с метрик, а с разбора: 50−100 реальных диалогов, прочитать целиком, выписать каждую ошибку своими словами, сгруппировать и посчитать. Если 60% ошибок — подстановка цены из другого варианта товара, главная метрика про цену, а не «полезность ответа».
Вердикты делайте бинарными. Шкала 1−5 не операционализируется: тройка одного проверяющего не равна тройке другого. Факты проверяет детерминированный проверяющий, а не судья-модель: цену, срок доставки и наличие обязательной оговорки сравнивают с источником. Судье оставьте тон, на выборке. Молчание и отказ — полноправные случаи набора.
Качество формулируется как доля: не менее 85% ответов проходят порог. При тысяче обращений в сутки это 150 непрошедших в сутки, живые люди с ответом, который ваша же система считает плохим. Стабильность считается, а не ощущается: при 75% успеха за попытку три подряд дают около 42%.
Отдельный рычаг 2026 года — работа с контекстом. Здесь путают три разные вещи, у каждой свой отказ. Очистка выбрасывает из окна отработавшие вызовы инструментов. Компакция сворачивает историю в пересказ. Память выносит знание наружу окна и возвращает его адресно. Дефолт сместился к отложенной подаче: не грузить всё заранее, а давать модели оглавление и инструмент дочитать нужное.
И контринтуитивное: не бросайтесь сжимать контекст ради экономии. Сжатие вырезает в первую очередь дешёвые токены, читавшиеся из кэша, и переупаковывает начало промпта, обнуляя попадание в кэш префикса. На учебных числах нашего курса минус 38% входных токенов дали не экономию, а рост счёта за миллион входных токенов на 8,5%, а при дисциплине кэша 90% — на 75%: дешёвый кэшированный вход подменился дорогим некэшированным.
7. Как устроено хранение и поиск знаний в RAG-системах?
Хранилище здесь не одно, их три, и путаница между ними даёт большинство инцидентов.
Первое — корпус-источник: документы с версиями и владельцем. Второе — поисковый индекс: документ нарезан на чанки, у каждого чанка есть вектор, лексическое представление и поля-фильтры (владелец, язык, дата, класс доступа, версия документа). Объём корпуса считают в чанках, а не в документах: 1,9 млн документов дают 4,1 млн чанков, и вся арифметика памяти и задержек идёт от второго числа. Третье — живые источники правды, которые в индекс не кладут вовсе.
Разделительная линия между вторым и третьим проходит по цене ошибки. Поле, участвующее в обещании денег или сроков (цена, наличие, промо, персональная цена), читается живым синхронным запросом. Описательное поле берётся из индекса и выдаётся с отметкой времени. Вчерашний дамп — прекрасный источник описаний и очень плохой источник цены. Ответ «на этот товар действует скидка 30%» по суточному индексу — это обещание от лица компании, которого компания не давала. Правило, которое пропускают чаще всего: если живой источник не ответил, система отказывает по этому полю, а не подставляет индексное значение.
Поиск по индексу — гибрид лексического и векторного со слиянием списков, затем переранжирование, при неуверенности — переспрос.
Права — часть хранения, а не постобработки. Проверяются они до попадания текста в окно модели: предфильтр ретривера, политика инструмента, фильтр в запросе к базе. Фильтрация после генерации контролем не считается. Текст уже прочитан моделью, уже в трейсе и мог попасть в кэш. Поэтому класс доступа живёт полем индекса, а не проверкой на выходе.
Зависимость, которую недооценивают: смена эмбеддера дороже смены чат-модели. Чат-модель меняется строкой в маршруте. Вывод эмбеддера из эксплуатации — полная переиндексация корпуса, потому что вектора разных эмбеддеров несравнимы. Дорого там не машинное время, а повторный подбор порогов. Индекс версионируется вместе с эмбеддером.
Первое — корпус-источник: документы с версиями и владельцем. Второе — поисковый индекс: документ нарезан на чанки, у каждого чанка есть вектор, лексическое представление и поля-фильтры (владелец, язык, дата, класс доступа, версия документа). Объём корпуса считают в чанках, а не в документах: 1,9 млн документов дают 4,1 млн чанков, и вся арифметика памяти и задержек идёт от второго числа. Третье — живые источники правды, которые в индекс не кладут вовсе.
Разделительная линия между вторым и третьим проходит по цене ошибки. Поле, участвующее в обещании денег или сроков (цена, наличие, промо, персональная цена), читается живым синхронным запросом. Описательное поле берётся из индекса и выдаётся с отметкой времени. Вчерашний дамп — прекрасный источник описаний и очень плохой источник цены. Ответ «на этот товар действует скидка 30%» по суточному индексу — это обещание от лица компании, которого компания не давала. Правило, которое пропускают чаще всего: если живой источник не ответил, система отказывает по этому полю, а не подставляет индексное значение.
Поиск по индексу — гибрид лексического и векторного со слиянием списков, затем переранжирование, при неуверенности — переспрос.
Права — часть хранения, а не постобработки. Проверяются они до попадания текста в окно модели: предфильтр ретривера, политика инструмента, фильтр в запросе к базе. Фильтрация после генерации контролем не считается. Текст уже прочитан моделью, уже в трейсе и мог попасть в кэш. Поэтому класс доступа живёт полем индекса, а не проверкой на выходе.
Зависимость, которую недооценивают: смена эмбеддера дороже смены чат-модели. Чат-модель меняется строкой в маршруте. Вывод эмбеддера из эксплуатации — полная переиндексация корпуса, потому что вектора разных эмбеддеров несравнимы. Дорого там не машинное время, а повторный подбор порогов. Индекс версионируется вместе с эмбеддером.
8. Что такое векторные базы данных и как они работают?
Векторная база хранит не текст, а его числовое представление. Эмбеддер переводит фрагмент в вектор из сотен или тысяч чисел так, что близкие по смыслу фрагменты близки геометрически. Близость определена в терминах той модели, которая вектора считала, и только её: сравнивать вектора двух разных эмбеддеров бессмысленно.
Поиск устроен не перебором. Точный ближайший сосед на миллионах векторов слишком дорог, поэтому используется приближённый: вектора связывают в многоуровневый граф соседства, и запрос обходит его от точки входа ко всё более близким кандидатам. Отсюда два свойства, которых у обычной СУБД нет. Результат вероятностный: качество меряют долей действительно ближайших документов в выдаче. И это качество обменивается на память и время параметрами построения и обхода. Квантизация — главный рычаг обмена: вектора хранят огрублённо, чтобы индекс влез в память, а часть точности возвращают рескорингом по точным значениям.
Главное про 2026 год: спор давно идёт не про приближённый поиск, а про фильтрацию. И это самый недооценённый класс отказа во всей теме. Оба наивных способа ломаются по-своему.
Предфильтр считает маску по всей коллекции и делает кандидатом каждое совпадение: на широком фильтре он вырождается в перебор, ради ухода от которого индекс и строили.
Постфильтр ищет сначала, отсеивает потом и компенсирует запасом выдачи: на узком фильтре запас выбрасывается целиком, ответ приходит обрезанным.
Середина диапазона плоха для обоих: совпадений слишком много для предфильтра и слишком мало для постфильтра. В вендорском замере Qdrant обычные формы фильтров держат долю найденного выше 97%, широкий фильтр роняет её до 90,8%, а условие AND по двум широким значениям — до 39,7%.
Как это выглядит в проде: запрос быстрый, ошибок нет, дашборды зелёные, а нужные документы тихо исчезли из выдачи. Ни один системный график этого не покажет — только доля запросов, где нужный документ найден, на размеченном наборе. Современный ответ — фильтрация внутри обхода графа, а не до и не после. В том же замере оба провальных случая, по заявлению вендора, восстанавливаются полностью.
Вещь, которую путают с фильтром: понижение в ранге ничего не выбрасывает. «Предпочитай товары в наличии, но покажи идеальный, которого нет» — не фильтр.
Поиск устроен не перебором. Точный ближайший сосед на миллионах векторов слишком дорог, поэтому используется приближённый: вектора связывают в многоуровневый граф соседства, и запрос обходит его от точки входа ко всё более близким кандидатам. Отсюда два свойства, которых у обычной СУБД нет. Результат вероятностный: качество меряют долей действительно ближайших документов в выдаче. И это качество обменивается на память и время параметрами построения и обхода. Квантизация — главный рычаг обмена: вектора хранят огрублённо, чтобы индекс влез в память, а часть точности возвращают рескорингом по точным значениям.
Главное про 2026 год: спор давно идёт не про приближённый поиск, а про фильтрацию. И это самый недооценённый класс отказа во всей теме. Оба наивных способа ломаются по-своему.
Предфильтр считает маску по всей коллекции и делает кандидатом каждое совпадение: на широком фильтре он вырождается в перебор, ради ухода от которого индекс и строили.
Постфильтр ищет сначала, отсеивает потом и компенсирует запасом выдачи: на узком фильтре запас выбрасывается целиком, ответ приходит обрезанным.
Середина диапазона плоха для обоих: совпадений слишком много для предфильтра и слишком мало для постфильтра. В вендорском замере Qdrant обычные формы фильтров держат долю найденного выше 97%, широкий фильтр роняет её до 90,8%, а условие AND по двум широким значениям — до 39,7%.
Как это выглядит в проде: запрос быстрый, ошибок нет, дашборды зелёные, а нужные документы тихо исчезли из выдачи. Ни один системный график этого не покажет — только доля запросов, где нужный документ найден, на размеченном наборе. Современный ответ — фильтрация внутри обхода графа, а не до и не после. В том же замере оба провальных случая, по заявлению вендора, восстанавливаются полностью.
Вещь, которую путают с фильтром: понижение в ранге ничего не выбрасывает. «Предпочитай товары в наличии, но покажи идеальный, которого нет» — не фильтр.
9. Как выбрать между Pinecone, Weaviate, Qdrant и PostgreSQL pgvector?
Полезнее всего этот вопрос отвечается с обратной стороны: как не выбирать.
Не по чужому графику. Летом 2026 Elastic опубликовала бенчмарк с семикратным преимуществом по пропускной способности над Qdrant, а 8 июля Qdrant ответил встречным замером: вдвое быстрее, вдвое меньше задержка, треть вычислений, а конкурент неверно его сконфигурировал. Оба замера вендорские и опровергают друг друга. Независимого воспроизводимого сравнения за 2026 год в открытом доступе нет, а числа из обзорных статей первоисточником не подтверждаются.
Не первым решением. Первое архитектурное решение сегодня другое: managed retrieval провайдера или свой стек. Поиск по файлам стал серверным инструментом, и собственный чанкер со своим хранилищем — выбор, а не обязательный этап.
Про pgvector скажу точно, потому что здесь есть проверяемый факт. Аргумент в его пользу не скорость: за 2026 год в ветке 0.8.x вышли только багфиксы и точечные оптимизации памяти, а последняя крупная функциональность, итеративные проходы по индексу, приехала ещё в версии 0.8.0 в октябре 2024. Аргумент — отсутствие второй системы. Нет синхронизации двух хранилищ, есть транзакции вместе с реляционными данными, и дежурный уже умеет это эксплуатировать.
Про остальных двоих скажу ровно то, что проверяется по их документации. Weaviate — открытый исходный код и установка к себе: движок можно поднять в своём контуре и прогнать на нём свои данные до всякой покупки. Pinecone — управляемый сервис, поставки для self-hosting нет; это не минус, это ответ на вопрос про юрисдикцию и класс данных. Дальше по производительности я не иду, и вот критерий: цифру можно называть, если её опубликовал не заинтересованный в исходе продавец либо она воспроизводится по описанной методике. Остальное — маркетинг, и в архитектурный документ он не переносится.
Тогда критерии, по которым выбор действительно делается. Профиль фильтрации: как часто ваш типичный запрос идёт с фильтром и насколько широким. Мультитенантность и права как поле индекса. Объём памяти под корпус и допустимая для вас квантизация. Гибридный поиск из коробки. Цена миграции: смена эмбеддера означает переиндексацию независимо от движка. И кто дежурный.
Единственный убедительный замер — свой: ваш корпус, ваши фильтры, ваш размеченный набор.
Не по чужому графику. Летом 2026 Elastic опубликовала бенчмарк с семикратным преимуществом по пропускной способности над Qdrant, а 8 июля Qdrant ответил встречным замером: вдвое быстрее, вдвое меньше задержка, треть вычислений, а конкурент неверно его сконфигурировал. Оба замера вендорские и опровергают друг друга. Независимого воспроизводимого сравнения за 2026 год в открытом доступе нет, а числа из обзорных статей первоисточником не подтверждаются.
Не первым решением. Первое архитектурное решение сегодня другое: managed retrieval провайдера или свой стек. Поиск по файлам стал серверным инструментом, и собственный чанкер со своим хранилищем — выбор, а не обязательный этап.
Про pgvector скажу точно, потому что здесь есть проверяемый факт. Аргумент в его пользу не скорость: за 2026 год в ветке 0.8.x вышли только багфиксы и точечные оптимизации памяти, а последняя крупная функциональность, итеративные проходы по индексу, приехала ещё в версии 0.8.0 в октябре 2024. Аргумент — отсутствие второй системы. Нет синхронизации двух хранилищ, есть транзакции вместе с реляционными данными, и дежурный уже умеет это эксплуатировать.
Про остальных двоих скажу ровно то, что проверяется по их документации. Weaviate — открытый исходный код и установка к себе: движок можно поднять в своём контуре и прогнать на нём свои данные до всякой покупки. Pinecone — управляемый сервис, поставки для self-hosting нет; это не минус, это ответ на вопрос про юрисдикцию и класс данных. Дальше по производительности я не иду, и вот критерий: цифру можно называть, если её опубликовал не заинтересованный в исходе продавец либо она воспроизводится по описанной методике. Остальное — маркетинг, и в архитектурный документ он не переносится.
Тогда критерии, по которым выбор действительно делается. Профиль фильтрации: как часто ваш типичный запрос идёт с фильтром и насколько широким. Мультитенантность и права как поле индекса. Объём памяти под корпус и допустимая для вас квантизация. Гибридный поиск из коробки. Цена миграции: смена эмбеддера означает переиндексацию независимо от движка. И кто дежурный.
Единственный убедительный замер — свой: ваш корпус, ваши фильтры, ваш размеченный набор.
задай вопрос, а мы ответим
