Вы очень точно сформулировали позицию сторонников фреймворков, и в Ваших тезисах действительно есть рациональное зерно. Фреймворк отличный вариант для старта, для нетребовательных пайплайнов и MVP экспериментов. На сложных пайпалайнах он уступает место низкоуровневой разработке. Речь идет не о старте на самописном RAG, а о архитектурных ограничениях фреймворков. Вы без труда найдете в Issue Langchain "Closed as not planned" кейсы, а также форки связанные с ограничением исходной архитектуры, публикации с лозунгами "Уходим с Langchain", где будут подробно описаны причины и конкретные кейсы. Поэтому идея статьи скорее не "фреймворки зло", а "важно понимать, как это работает без фреймворка". Тогда уже осознанно выбираешь - оставить Langchain, написать свои компоненты или выбрать гибридный поход.
У Elastic сейчас действительно интересный стек для таких задач. Для многих кейсов это может быть очень быстрый способ собрать RAG. Особенно если уже используется для поиска. Это отличный старт для неспецифичных пайплайнов, но может стать проблемой когда Вам понадобится нестандартная логика фрагментации, специфический гибридный поиск с весами источников или доступ к промежуточным данным для отладки. здесь Elastic может быть неостаточно прозрачным. Кроме того Agent Builder в продакшене добавляет аналогичный слой абстракции
Интересный взгляд, на статью. Но все зависит от того с какой стороны мы посмотрим на проблему. Заказчика, разработчика, интегратора или конечного пользователя. Если говорить про NIH синдром в контексте RAG, то в первую очередь необходимо понимать цели и задачи реализации, если в ресурсоемкой разработке как правило принято довольствоваться имеющимся на рынке решениями, то для относительно доступных технологий и открытого стека заказчик за свои деньги хочет получить ровно то что ему необходимо по ТЗ, и это не путь готовых решений В части метрик Вы затронули важную тему, и я соглашусь метрики и бенчмарки это основа любого RAG кейса. Без этого этапа любой вариант реализации лотерея. Другой вопрос что в статье намеренно не рассматриваются конкретные кейсы, а приводится только архитектурная часть разработки Если оперировать категорией изобретения велосипеда, то они тоже бывают разные ), тут скорее разработка направлена в сторону унификации и упрощения с ориентиром на реальный рынок, состоящий из конкретных запросов
Действительно, при однотипной структуре документов целесообразно применение предобработки данных до векторизации с целью сократить объем БД и повысить релевантность выдачи, например при помощи парсинга, суммаризации и т.п методов, основной критерий это сохранение качества извлекаемых из документов данных, что в некоторых доменах, например медицина может стать критичным
Ставил локально r1:7B модель, тестировал под Q&A RAG, в довольно простых запросах модель щедро разбавляла русскоязычной текст, английским и китайским, та же llama3 справляется с русскоязычной генерацией намного лучше
PC/104 как стандарт опережали время, многослойная архитектура позволяла конфигурировать периферию на свой вкус, а размеры и промышленное исполнение позволяли интегрировать платы этого стандарта куда угодно от авто до спутников
Насколько линейно рост в геометрической прогрессии объема создаваемых данных влияет на количество судебных споров, связанных с защитой интеллектуальной собственности. По ссылке из статьи:
2023год - 52 620 ,
2022год - 43 608,
2021год - 33 863
При этом в 2022 году больше 10% споров инициировал один заявитель
Вопрос интересный, особенно с учетом того, что в последнее время чаще начинают заявлять о возможном нарушении авторских прав на произведения, которые были использованы для обучения AI моделей. Фактически генерация не является переработанным произведением, но с позиции самой модели, AI модель при генерации заимствует именно фрагменты - токены из этих "нелегальных" датасетов, а не генерирует из набора символов. По сути речь идет о фрагментах чужих произведений, грубо говоря собранных AI по требованию пользователя, основная дилемма - могут ли такие действия могут порождать авторские права
Вы очень точно сформулировали позицию сторонников фреймворков, и в Ваших тезисах действительно есть рациональное зерно.
Фреймворк отличный вариант для старта, для нетребовательных пайплайнов и MVP экспериментов. На сложных пайпалайнах он уступает место низкоуровневой разработке. Речь идет не о старте на самописном RAG, а о архитектурных ограничениях фреймворков. Вы без труда найдете в Issue Langchain "Closed as not planned" кейсы, а также форки связанные с ограничением исходной архитектуры, публикации с лозунгами "Уходим с Langchain", где будут подробно описаны причины и конкретные кейсы.
Поэтому идея статьи скорее не "фреймворки зло", а "важно понимать, как это работает без фреймворка". Тогда уже осознанно выбираешь - оставить Langchain, написать свои компоненты или выбрать гибридный поход.
У Elastic сейчас действительно интересный стек для таких задач. Для многих кейсов это может быть очень быстрый способ собрать RAG. Особенно если уже используется для поиска. Это отличный старт для неспецифичных пайплайнов, но может стать проблемой когда Вам понадобится нестандартная логика фрагментации, специфический гибридный поиск с весами источников или доступ к промежуточным данным для отладки. здесь Elastic может быть неостаточно прозрачным. Кроме того Agent Builder в продакшене добавляет аналогичный слой абстракции
Интересный взгляд, на статью. Но все зависит от того с какой стороны мы посмотрим на проблему. Заказчика, разработчика, интегратора или конечного пользователя.
Если говорить про NIH синдром в контексте RAG, то в первую очередь необходимо понимать цели и задачи реализации, если в ресурсоемкой разработке как правило принято довольствоваться имеющимся на рынке решениями, то для относительно доступных технологий и открытого стека заказчик за свои деньги хочет получить ровно то что ему необходимо по ТЗ, и это не путь готовых решений
В части метрик Вы затронули важную тему, и я соглашусь метрики и бенчмарки это основа любого RAG кейса. Без этого этапа любой вариант реализации лотерея. Другой вопрос что в статье намеренно не рассматриваются конкретные кейсы, а приводится только архитектурная часть разработки
Если оперировать категорией изобретения велосипеда, то они тоже бывают разные ), тут скорее разработка направлена в сторону унификации и упрощения с ориентиром на реальный рынок, состоящий из конкретных запросов
Действительно, при однотипной структуре документов целесообразно применение предобработки данных до векторизации с целью сократить объем БД и повысить релевантность выдачи, например при помощи парсинга, суммаризации и т.п методов, основной критерий это сохранение качества извлекаемых из документов данных, что в некоторых доменах, например медицина может стать критичным
Ставил локально r1:7B модель, тестировал под Q&A RAG, в довольно простых запросах модель щедро разбавляла русскоязычной текст, английским и китайским, та же llama3 справляется с русскоязычной генерацией намного лучше
PC/104 как стандарт опережали время, многослойная архитектура позволяла конфигурировать периферию на свой вкус, а размеры и промышленное исполнение позволяли интегрировать платы этого стандарта куда угодно от авто до спутников
Насколько линейно рост в геометрической прогрессии объема создаваемых данных влияет на количество судебных споров, связанных с защитой интеллектуальной собственности. По ссылке из статьи:
2023год - 52 620 ,
2022год - 43 608,
2021год - 33 863
При этом в 2022 году больше 10% споров инициировал один заявитель
Вопрос интересный, особенно с учетом того, что в последнее время чаще начинают заявлять о возможном нарушении авторских прав на произведения, которые были использованы для обучения AI моделей. Фактически генерация не является переработанным произведением, но с позиции самой модели, AI модель при генерации заимствует именно фрагменты - токены из этих "нелегальных" датасетов, а не генерирует из набора символов. По сути речь идет о фрагментах чужих произведений, грубо говоря собранных AI по требованию пользователя, основная дилемма - могут ли такие действия могут порождать авторские права