Разработчик под псевдонимом Николай опубликовал подробный разбор своего проекта «Нафаня» — агентного RAG-помощника, специализирующегося на нормативно-технической документации в сфере строительства и ценообразования, включая методики Минстроя, ГОСТы, СНиПы и профильные законы. В статье автор рассказывает, как устроена система, как проходила её проверка на сложном бенчмарке TRuST и какие архитектурные изменения потребовались для преодоления «потолка метрик». Особый интерес представляет то, что проект работает на домашнем железе: двух RTX 4070 по 16 ГБ и одной RTX 5060, что накладывает серьёзные ограничения на выбор моделей и распределение задач. В отличие от многих коммерческих RAG-решений, которые полагаются на мощные серверные кластеры, «Нафаня» демонстрирует, что даже скромная по современным меркам конфигурация способна обеспечить конкурентоспособное качество обработки сложной технической документации.

Ключевая особенность архитектуры «Нафани» — разделение ролей между локальными узкими моделями и внешними API-сервисами. На RTX 5060 работают эмбеддеры, на одной RTX 4070 — 4B LLM для оценки релевантности чанков, на второй — 4B VLM для разбора формул и изображений. Общая языковая модель через внешний API (в основном Qwen и DeepSeek) отвечает за планирование, генерацию и критику. Такая гибридная схема позволяет использовать сильные стороны больших моделей, не перегружая локальные ресурсы. Продукт поддерживает загрузку PDF, DOC, DOCX, TXT, HTML, включая сложные нормативные документы с таблицами и формулами, а также мультимодальную обработку и несколько стратегий поиска: векторный, семантический, гибридный и специализированные доменные виды. Важно, что «Нафаня» умеет работать с «тяжёлыми» PDF-файлами, включая старые советские сканы, где даже продвинутые инструменты вроде docling иногда пасуют.

До проверки на бенчмарке «Нафаня» уже имел развитую агентную обвязку: планировщик задавал направления поиска, ретривер компоновал контекст, оценщик проверял релевантность, генератор готовил ответ, а критик оценивал результат и мог запускать перегенерацию или новые поисковые циклы. На внутренних доменных примерах система выглядела убедительно, и автор признаётся, что его самоуверенность была избыточной. Всё изменилось после конференции Т-Банка, где он услышал доклад про агент-ретривер T-Search и бенчмарк TRuST. T-Search — это открытый агент на базе Qwen3.6-35B-A3B, обученный на синтетических данных, который выполняет многошаговый поиск и возвращает ранжированный список чанков. TRuST — бенчмарк из 324 сложных вопросов на русском языке, требующих многошаговых рассуждений и связи нескольких источников, с фиксированным индексом из примерно 23 тысяч документов. Бенчмарк охватывает восемь тематик и пять типов поисковой сложности, включая Multihop, Structured Evidence, Temporal Tracking, Entity Disambiguation и Comparative Reasoning, что делает его серьёзным испытанием для любой RAG-системы.

Адаптация бенчмарка к «Нафане» потребовала изменений, поскольку TRuST оценивает только качество поиска, а не финальный ответ. Автор создал внешний стенд, который обращается к RAG как обычный клиент и проверяет как результаты поиска, так и качество сгенерированного ответа. При этом он использовал метрику Recall@10 для оценки поиска, но также ввёл дополнительные метрики для ответов. Первые тесты показали, что система справляется с простыми вопросами, но на сложных типах задач, таких как Multihop или Temporal Tracking, возникают проблемы. Это заставило пересмотреть архитектуру: критик, который раньше казался «взрослым» звеном, стал узким местом, потому что его оценки релевантности часто были неточными, а циклы перегенерации не всегда приводили к улучшению. Автор обнаружил, что на бенчмарке система показала результаты, сопоставимые с более крупными коммерческими решениями, но при этом осталась полностью локальной и прозрачной для пользователя.

В процессе доработки автор внедрил несколько улучшений: добавил специализированные инструменты для работы с таблицами и формулами, улучшил алгоритмы оценки релевантности, ввёл бюджеты на количество итераций и проверки полноты охвата. Также он экспериментировал с использованием локальных моделей для узких задач, что позволило снизить зависимость от внешних API и ускорить обработку. Важным открытием стало то, что на бенчмарке TRuST система показала результаты, сопоставимые с более крупными коммерческими решениями, но при этом осталась полностью локальной и прозрачной для пользователя. Автор подчёркивает, что «Нафаня» — это не просто исследовательский проект, а рабочий инструмент, который можно использовать в реальной инженерной практике. Он также отмечает, что использование внешних API остаётся уязвимым местом, но благодаря гибридной архитектуре удалось минимизировать эту зависимость.

Для российского рынка этот проект представляет особый интерес, поскольку демонстрирует возможность создания эффективных RAG-систем на доступном оборудовании без необходимости использования дорогих облачных сервисов. Учитывая, что многие российские компании сталкиваются с ограничениями на использование зарубежных ИИ-платформ, локальные решения становятся всё более востребованными. «Нафаня» показывает, что даже домашняя рабочая станция способна обеспечить достойное качество обработки сложной технической документации, что может быть полезно для малых и средних предприятий строительной отрасли. Однако остаются открытые вопросы: насколько система масштабируема при увеличении объёма документов, как она поведёт себя на других доменах, и можно ли полностью отказаться от внешних API без потери качества. Эти вопросы автор планирует исследовать в дальнейшем.

В перспективе автор планирует продолжить развитие «Нафани», улучшая алгоритмы поиска и добавляя новые типы документов. Он также рассматривает возможность публикации части кода и бенчмарков для сообщества, чтобы другие разработчики могли воспроизвести и улучшить результаты. Важным направлением является интеграция с открытыми моделями, которые можно запускать локально, что снизит зависимость от внешних сервисов. В целом, опыт «Нафани» показывает, что агентные RAG-системы способны решать сложные задачи даже на ограниченном железе, если правильно спроектировать архитектуру и использовать специализированные инструменты. Это открывает новые возможности для создания автономных ИИ-помощников в различных отраслях, где требуется работа с большими объёмами нормативной документации. Учитывая текущие тренды в области ИИ, такие как развитие локальных моделей и рост интереса к суверенным технологиям, проект Николая может стать важным шагом в популяризации доступных и прозрачных RAG-решений в России.