Комментарии 7
Фундамент любой ИИ трансформации это сначала цифровизация всего и вся.
RAG не очень надёжен для поиска артикулов, SKU, кодов или точных названий блюд — там, где нужно точное совпадение, обычный поиск по ключевым словам или гибридный поиск часто работают лучше и предсказуемее. И если всё равно нужны классический поиск, фильтрация по метаданным и детерминированная логика, то RAG уже не может быть центром всей системы. Это лишь один из слоёв архитектуры, которые статья почти не затрагивает: гибридный поиск, переранжирование результатов, пайплайн оценки качества, orchestration/tooling-слой поверх самого RAG. Но в любом случае интересный опыт.
Фундамент - это электричество
Интересно, конечно, но непонятно. Непонятно, как же для каждой новой роли делается "изолированная база данных"(!).
Т.е. данные дублируются? (условное меню, наверное, нужно и повару и официанту и гостю)
А как же тогда постулат о "единой базе"? Так это единая база или всё же набор изолированных баз? Или терминология и картинки немного несогласованно используются?
Сильно зависит от задачи. Например для некоторых данных проще использовать реляционную базу данных, скил и хелпер скрипты для получения данных и обновления и в таком варианте ллм может работать лучше с структурированными и с точными данными.
У меня скорее вопрос масштабирования. Я работаю в компании где документов сотни тысяч и обновляются ежегодно более 10 тысяч. Как сделать быстрым создание RAG и не потеряется ли он в таком количестве данных. Как быть с версионностью и не потерять доступ к старым данным и не захоебнется ли сама модель от такого количества данных. Это из того о чем я подумал сразу. И если с этим ок, то какую модель стоит использовать для работы с таким массивом, например qwen 3.6.

Почему RAG — фундамент любой AI-трансформации