Да, согласна, мы также столкнулись с такой проблемой, и по этой причине возникли такие сложности при разработке и адаптации. На специально подготовленных данных (с вырезанным "мусором"и т.п.) современные RAG-системы работают достойно “из коробки”. Но нашей целью было сделать решение, которое давало бы хотя бы удовлетворительный результат для более-менее случайного набора документации. И тут уже в ход пошли кастомные подходы и решения, начиная от варьирования размера чанков в зависимости от типизации документа, заканчивая разными подходами к финальной обработке на LLM-ранжированной выборке. Ну и конечно, без административных рекомендаций никуда: для более стабильных результатов мы рекомендуем сотрудникам приводить документы к текстово-описательному виду, исключая по возможности любые решения визуального характера. Но, как понимаете, в условиях крупной ИТ-компании, это носит скорее рекомендательный характер)
Что касается локальных моделей: мы пробовали самые разные, как в плане семейств, так и в плане количества параметров. На данный момент остановились на Квене, так как он наиболее гибко себя ведет и на больших чанках, и на большом количестве разрозненных маленьких, давая при этом приемлемую скорость. По соотношению баланса скорости и качества выбрали эту модель. Но это на данный момент - процесс поиска наилучшей модели, особенно ввиду стремительности их развития, прекращать нельзя никогда.
Наличие 1000 и 1 решения на рынке означает, что ни одного по-настоящему хорошего решения нет - иначе именно оно бы этот рынок и захватило.
Проблемы RAGа не в том, чтобы настроить на статичной базе знаний более-менее нормального ассистента, а в том, чтобы обеспечить работу с универсальными документами - чтобы ваш RAG подходил для любого загруженного документа и выдавал достойный результат - тут проблемы возникают как на поиске фрагментов по векторной базе данных, так и по выстраиванию баланса креативности и точности.
Любая компания, которая сделает RAG совершенно стабильным и универсальным - озолотится, потому что потребность в нем колоссальна. Но отсутствие таких универсальных решений на рынке говорит о том, что задача не так проста, как кажется. А опенсорсные решения - не так хороши.
Ну, а если задача - поднять RAG ради RAGа для отчета перед руководством, то, конечно, можно и за полдня поднять)
Спасибо за мнение. С интересом почитаю вашу статью про ваш опыт.
Да, согласна, мы также столкнулись с такой проблемой, и по этой причине возникли такие сложности при разработке и адаптации. На специально подготовленных данных (с вырезанным "мусором"и т.п.) современные RAG-системы работают достойно “из коробки”. Но нашей целью было сделать решение, которое давало бы хотя бы удовлетворительный результат для более-менее случайного набора документации. И тут уже в ход пошли кастомные подходы и решения, начиная от варьирования размера чанков в зависимости от типизации документа, заканчивая разными подходами к финальной обработке на LLM-ранжированной выборке. Ну и конечно, без административных рекомендаций никуда: для более стабильных результатов мы рекомендуем сотрудникам приводить документы к текстово-описательному виду, исключая по возможности любые решения визуального характера. Но, как понимаете, в условиях крупной ИТ-компании, это носит скорее рекомендательный характер)
Что касается локальных моделей: мы пробовали самые разные, как в плане семейств, так и в плане количества параметров. На данный момент остановились на Квене, так как он наиболее гибко себя ведет и на больших чанках, и на большом количестве разрозненных маленьких, давая при этом приемлемую скорость. По соотношению баланса скорости и качества выбрали эту модель. Но это на данный момент - процесс поиска наилучшей модели, особенно ввиду стремительности их развития, прекращать нельзя никогда.
Наличие 1000 и 1 решения на рынке означает, что ни одного по-настоящему хорошего решения нет - иначе именно оно бы этот рынок и захватило.
Проблемы RAGа не в том, чтобы настроить на статичной базе знаний более-менее нормального ассистента, а в том, чтобы обеспечить работу с универсальными документами - чтобы ваш RAG подходил для любого загруженного документа и выдавал достойный результат - тут проблемы возникают как на поиске фрагментов по векторной базе данных, так и по выстраиванию баланса креативности и точности.
Любая компания, которая сделает RAG совершенно стабильным и универсальным - озолотится, потому что потребность в нем колоссальна. Но отсутствие таких универсальных решений на рынке говорит о том, что задача не так проста, как кажется. А опенсорсные решения - не так хороши.
Ну, а если задача - поднять RAG ради RAGа для отчета перед руководством, то, конечно, можно и за полдня поднять)