Как собрать локальную RAG-систему для личных документов
За годы на компьютере накопились сотни заметок: текстовые файлы с рецептами, фрагментами кода, настройками и случайными идеями. Такой формат удобен: документы легко открыть, изменить, скопировать или убрать в архив, а для обычного поиска по словам не нужны специальные программы. Но когда файлы разбросаны по вложенным папкам вроде "Документы/старое/разобрать/диск", нужную запись бывает непросто обнаружить.
Именно эта задача стала поводом попробовать поиск с помощью RAG. Идея - не менять привычный способ хранения, а добавить к нему инструмент, который понимает смысл запроса и подсказывает, в каких документах может находиться нужная информация. Важными условиями были локальная работа без облачных сервисов и подписок, сохранность файлов и умеренные требования к компьютеру: система должна запускаться на уже имеющейся машине с 4 ГБ оперативной памяти.
Здесь "с нуля" означает не создание новой языковой модели, а путь от знакомства с принципом RAG до рабочего домашнего прототипа. Подробности эксперимента с тем, как устроена [разработка RAG-системы с нуля](https://habr.com/ru/articles/1090066/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1090066), помогают увидеть не только общую схему, но и практические сложности, возникающие при ее реализации.
Как работает поиск по смыслу
Сначала документы делят на небольшие фрагменты - чанки. Затем специальная модель преобразует каждый фрагмент в числовой вектор, своего рода компактное представление его содержания. Точно так же кодируется вопрос пользователя. Система сравнивает векторы и выбирает те фрагменты, которые ближе всего по смыслу к запросу.
Для такого сопоставления применяют векторную базу данных. В экспериментальном варианте использовалась FAISS, а модель `intfloat/multilingual-e5-base` превращала тексты в векторы. Дополнительные сведения о том, из какого файла получен каждый фрагмент, сохранялись отдельно в JSON. Благодаря этому найденный отрывок можно связать с документом, где он был написан.
Это отличается от обычного полнотекстового поиска. Если искать только точные слова, запрос "как настроить резервную копию" может не найти заметку, где говорится о сохранении архивов. Векторное сопоставление способно уловить смысловое сходство. При этом поиск по ключевым словам не становится бесполезным: его можно добавить как второй способ отбора и использовать вместе с семантическим поиском.
От учебного примера к рабочему прототипу
Для первой версии был взят готовый Python-скрипт, который показывал основные этапы: чтение файлов из каталога, нарезку текста на чанки, расчет векторов, запись индекса и поиск похожих фрагментов. Это подходящая отправная точка, чтобы разобраться в принципе работы, хотя учебный код не обязательно удобен для постоянного использования.
После доработки появились два базовых процесса: один индексировал документы, другой выполнял запросы к созданной базе. Но быстро обнаружилось узкое место - время запуска. Программа загружала модель при каждом обращении, поэтому даже перед простым поиском приходилось ждать. Для домашней системы это особенно заметно: вместо мгновенного ответа пользователь сначала наблюдает, как подготавливается среда.
Такая проблема важна не только для личных заметок. При разработке AI-чат-бота по базе знаний необходимо учитывать не одну лишь точность ответов, но и скорость, обновление индекса и удобство повседневной работы. Аналогично, создание RAG-системы под ключ - это не просто установка модели и векторной базы: требуется определить, какие форматы документов поддерживать, как отслеживать изменения и как показывать пользователю найденные материалы.
Что стоит продумать заранее
Первое практическое правило - не изменять документы ради индексации. Индекс можно пересоздать, а текстовые файлы должны оставаться доступными и пригодными для чтения независимо от используемой программы. Это делает эксперимент безопаснее: если выбранный инструмент перестанет устраивать, заметки не окажутся заперты в неизвестном формате.
Не менее важна обработка изменений. Если пользователь добавил новую заметку или отредактировал старую, система должна уметь обновить соответствующие записи, а не заставлять каждый раз обрабатывать весь каталог. Для небольшого набора файлов допустим простой полный пересчет, но при росте коллекции эффективнее индексировать только новые и измененные документы.
Еще один шаг - показывать не только сформулированный ответ, но и названия документов с найденными фрагментами. Тогда человек может проверить, правильно ли система поняла контекст. Это особенно полезно, если заметки содержат похожие термины или устаревшие сведения. Само наличие языковой модели не гарантирует безошибочность: качество результата зависит от разбиения текста, выбранной модели и релевантности найденных отрывков.
При внедрении RAG в бизнес к этим вопросам добавляются права доступа, конфиденциальность, контроль актуальности материалов и журналирование запросов. Локальная обработка может быть привлекательной для организаций, которые не хотят отправлять внутренние документы во внешние сервисы, однако она не отменяет необходимости продумать защиту данных и обслуживание системы. А разработка системы поиска по документам с помощью ИИ начинается не с выбора модной модели, а с понимания того, какие вопросы задают сотрудники и в каком виде хранятся нужные им сведения.
Даже небольшой прототип способен показать, насколько удобнее искать по смыслу, чем вручную просматривать каталоги. Но путь от демонстрационного скрипта до надежного инструмента требует работы над скоростью, обновлением индекса и понятным отображением результатов. Для личного архива можно начать с простой локальной версии, постепенно улучшая ее по мере появления реальных задач.
