Machine Learning Mastery показал, как собрать RAG на scikit-learn без векторной базы

Machine Learning Mastery 13 октября 2026 года выпустил практическое руководство по сборке сквозного RAG-конвейера на минимальном стеке. Векторный поиск отдан scikit-learn, а эмбеддинги и работа с текстом построены на открытых моделях. Серверов с векторной базой, отдельной инфраструктуры и платных API на этапе прототипа не требуется. Материал учебный, не релизный, но он хорошо показывает, как мало нужно, чтобы запустить рабочую схему «найди контекст, затем ответь».

В анонсе описаны общие контуры схемы, поэтому ниже она разобрана по типовым шагам RAG. Конкретные параметры из полного текста руководства здесь не пересказываются.

Из чего собран конвейер

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

В руководстве за векторизацию отвечают открытые модели эмбеддингов, а за поиск ближайших соседей scikit-learn. Для такого сценария у библиотеки есть готовые инструменты: косинусное сходство и класс NearestNeighbors. Матрица векторов лежит в памяти, запрос превращается в вектор той же размерности, дальше идёт выборка top-k.

Примерный профиль такого стека:

• Поиск: scikit-learn, косинусная близость или NearestNeighbors, точный перебор без приближений.
• Эмбеддинги: открытая модель. Популярная all-MiniLM-L6-v2 для примера выдаёт 384-мерные векторы.
• Хранилище: массив NumPy в оперативной памяти.
• Объём: 100 тысяч фрагментов при 384 измерениях в float32 занимают около 150 МБ.
• Зависимости: Python, scikit-learn и библиотека для загрузки модели эмбеддингов.

Цифры по объёму посчитаны из размерности вектора, а не взяты из статьи. Они показывают порядок величин: 384 числа по 4 байта дают 1,5 КБ на фрагмент.

Зачем обходиться без векторной базы

Первое преимущество в прозрачности. Когда поиск сводится к умножению матриц и сортировке, видно, что происходит на каждом шаге. Можно распечатать сходство, посмотреть, какой фрагмент выиграл и почему, и сразу заметить, что чанки нарезаны плохо. В специализированных системах часть этой механики спрятана за API.

Второе преимущество в цене входа. Прототип не требует аккаунтов, ключей и сетевых вызовов. Для внутренней базы знаний на несколько тысяч страниц или для обучения команды этого хватает. Точный перебор на таких объёмах отрабатывает за доли секунды, так что приближённые индексы вроде HNSW ничего не добавляют.

Третье преимущество в воспроизводимости. Фиксируете версии библиотек и модели, и результат у коллеги совпадёт с вашим.

Где такая схема упрётся в потолок

Перебор масштабируется линейно. Когда корпус дорастёт до миллионов фрагментов, время ответа и память начнут мешать, и придётся переходить на FAISS, pgvector, Qdrant или аналоги. Дополнительные условия тоже ложатся на плечи разработчика: фильтры по метаданным, права доступа, инкрементальное обновление индекса. В scikit-learn всё это приходится дописывать руками.

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

Как использовать на практике

Начните с небольшого корпуса, например с вашей документации или FAQ, и соберите конвейер в одном скрипте. Заведите 20–30 контрольных вопросов с известными ответами и считайте долю случаев, когда нужный фрагмент попадает в top-3. Эта метрика, hit rate, покажет качество поиска раньше, чем вы подключите генерацию.

Потом меняйте по одной переменной: размер чанка, модель эмбеддингов, значение k. Если метрика растёт, схема работает. Когда корпус или нагрузка выйдут за пределы памяти одной машины, замените блок поиска на промышленную векторную базу. Остальной код при этом останется прежним, потому что интерфейс «вектор запроса на входе, список фрагментов на выходе» одинаков для обоих вариантов.