Последнее время окунулся в изучение данного вопроса (как раз имеющего узкий специализированный домен) и все больше склоняюсь с мысли, что без объемного и развенутого( множеством примеров) файн тюнинга не родится аленький цветочек)) (причем это справедливо как для имбеддинг так и для модели суммирования). Ну а в случае систем выставляющих требования контекстной зависимости, можно улучшить результат добавив в цепочку компонент для работы с графовым представлением данных , что при правильно организованной логики пеплайна даст хороший результат. С уважением.
Приветствую. Лет 15 читаю habr (без регистрации), но эта статья мотивировала пройти регистрацию. В первую очередь хочу выразить благодарность автору, хороший слог, основные моменты вопроса изложены последовательно, понятным языком! Но тема векторных представлений данных в контексте системы RAG лишь на первый взгляд выглядит «чудным» , «экспертным» решением и в начале может показаться бюджетной альтернативой моделям обученным на конкретном домене данных. В статье также следовало сделать акцент на том, что очень важным моментом является правильный выбор имбеддинг модели, а также подчеркнуть, что в процессе работы поменять ее на другую не выйдет, прийдется выполнять векторизацию данных сначала. Но все это по сути «цветочки» , ягодки начинаются когда подходим к вопросу «чанкинга» и приходит осознание, что в кейсах использующих обьемные контекстно не зависимые массивы для узко специализированных доменов, данный подход не принесет желаемого результата. (В специфичных доменах (например, техническая документация СТО) слово «машина» может значить не только «автомобиль», но и, например, станок или агрегат. Если модель не обучена именно на таких данных, она может неправильно интерпретировать смысл. Поэтому в узких областях важно дообучать модель или использовать доменно-специфичные данные для векторизации.) Так же вы упомянули что в случае использования мощных (DeepSeek, ChatGPT) в качестве модели суммирования позволяет получить ответ на нужном языке пользователю. Это верно лишь отчасти, действительно крупная модель с легкостью вернет результат выполнив осмысленный перевод, НО важным моментом является то, что в случае если запрос пользователя выполняется на языке отличного от того в который использовался при создании векторов, ничего у нас не сработает, так как логично что векторное представление «машина» и «car» будут бесконечно далеки. Этот нюанс так же необходимо учитывать. Подводя итог, не все так гладко , прекрасно и легко на текущем уровне развития систем RAG, и пока использование их в сферах с высокими требованиями к достоверности данных вызывают больше вопросов чем ответов. Ведь сама суть таких систем - «модель суммирования» не должна фантазировать, и работать с нулевой температурой. Еще раз спасибо автору, статья действительно хорошая!
Большое спасибо!
Последнее время окунулся в изучение данного вопроса (как раз имеющего узкий специализированный домен) и все больше склоняюсь с мысли, что без объемного и развенутого( множеством примеров) файн тюнинга не родится аленький цветочек)) (причем это справедливо как для имбеддинг так и для модели суммирования). Ну а в случае систем выставляющих требования контекстной зависимости, можно улучшить результат добавив в цепочку компонент для работы с графовым представлением данных , что при правильно организованной логики пеплайна даст хороший результат. С уважением.
Приветствую. Лет 15 читаю habr (без регистрации), но эта статья мотивировала пройти регистрацию. В первую очередь хочу выразить благодарность автору, хороший слог, основные моменты вопроса изложены последовательно, понятным языком! Но тема векторных представлений данных в контексте системы RAG лишь на первый взгляд выглядит «чудным» , «экспертным» решением и в начале может показаться бюджетной альтернативой моделям обученным на конкретном домене данных. В статье также следовало сделать акцент на том, что очень важным моментом является правильный выбор имбеддинг модели, а также подчеркнуть, что в процессе работы поменять ее на другую не выйдет, прийдется выполнять векторизацию данных сначала. Но все это по сути «цветочки» , ягодки начинаются когда подходим к вопросу «чанкинга» и приходит осознание, что в кейсах использующих обьемные контекстно не зависимые массивы для узко специализированных доменов, данный подход не принесет желаемого результата. (В специфичных доменах (например, техническая документация СТО) слово «машина» может значить не только «автомобиль», но и, например, станок или агрегат. Если модель не обучена именно на таких данных, она может неправильно интерпретировать смысл. Поэтому в узких областях важно дообучать модель или использовать доменно-специфичные данные для векторизации.) Так же вы упомянули что в случае использования мощных (DeepSeek, ChatGPT) в качестве модели суммирования позволяет получить ответ на нужном языке пользователю. Это верно лишь отчасти, действительно крупная модель с легкостью вернет результат выполнив осмысленный перевод, НО важным моментом является то, что в случае если запрос пользователя выполняется на языке отличного от того в который использовался при создании векторов, ничего у нас не сработает, так как логично что векторное представление «машина» и «car» будут бесконечно далеки. Этот нюанс так же необходимо учитывать. Подводя итог, не все так гладко , прекрасно и легко на текущем уровне развития систем RAG, и пока использование их в сферах с высокими требованиями к достоверности данных вызывают больше вопросов чем ответов. Ведь сама суть таких систем - «модель суммирования» не должна фантазировать, и работать с нулевой температурой. Еще раз спасибо автору, статья действительно хорошая!