Если вы делаете RAG-поиск по документации или базе знаний, то рано или поздно упираетесь в проблему: хорошо найти — это еще не хорошо ответить.

База знаний, RAG, найденные чанки, LLM строит ответ. Но пользователь не знает ни про DCG, ни про Recall@10, ни про чанки вообще. Он видит только то, что написано в итоговом ответе. А проблемы начинаются именно здесь: модель может что-то проигнорировать, ответить на другом языке, добавить что-то от себя или выдать уверенный текст с иероглифами посередине.

В прошлой статье мы разбирали, как улучшали сам retrieval: чанкование, метаданные, гибридный поиск, реранкинг. Но после того как с поиском более-менее разобрались, встал другой вопрос — как вообще понять, хороший ли ответ получает пользователь?

Привет, меня зовут Дима, я делаю ИИ-функции в Gramax. В этой статье расскажу, как мы выстроили методику оценки ответов RAG-поиска. Заодно поделюсь, какая модель прямо сейчас дает лучший результат на наших задачах.

Недавно на Хабре вышла статья про создание RAG-системы для строительных ГОСТов. Команда Цифрового стандарта проделала титаническую работу — полгода вручную разбивали документы на смысловые чанки. Респект за настойчивость и результат.

Их история вдохновила поделиться собственным опытом. Мы тоже столкнулись с проблемой чанкования для умного поиска по базе знаний. Тоже прошли через RAG, векторные базы и поиски оптимального решения. Но пошли по пути полной автоматизации.

Всем привет, меня зовут Дима, я делаю ИИ-функции в Gramax. Эта статья для тех, кто сейчас воюет с чанками вручную или пытается найти оптимальный подход. Делимся нашим путем от быстрого прототипа до продакшен-решения с метриками 90%+.