Pull to refresh
8K+
6
Артур Хайруллин@iximy

User

17
Rating
15
Subscribers
Send message

Он прем или облако каждый решает сам, исходя из корпоративных требований конкретной организации, универсального решения нет.
Стоимость готовых решений как для онпрем так и облачных это вообще отдельная тема, не говоря о запуске самостоятельной разработки и конечной стоимости собственного решения
В статье описано как получить RAG базу знаний за 15 минут и почему пришлось собирать свою версию RAG, а не использовать готовые решения или разработку RAG на фреймворках

Как раз такой вариант развертывания (он прем за 15 минут) и описан в статье, также приведено полное видео развертывания на чистой ОС https://www.youtube.com/watch?v=jjMnOLqgTkA, после развертывания система работает полностью локально, с возможностью подключения облачной генерации. Про один клик в статье речи не идет, это цитата из Вашего комментария про готовые продукты. Для развертывания достаточно выполнить 6 copy\paste из мануала, для этого не нужна команда разработки, справится среднестатический пользователь
Даже если рассматривать облачные сервисы как альтернативу собственной инфраструктуре и отбросить вопросы безопасности при выгрузке корпоративных данных на внешние сервисы, таких решений (без ограничений на количество документов\запросов\пользователей) на рынке нет

Моя отсылка к критичности локализации это ответ на Ваш вопрос в стартовом комментарии "зачем все это".
Локализация, как на уровне хранения, так и генерации это ключевой момент для компаний, где безопасность и конфиденциальность критичны. И не всегда это зависит от оборота, например небольшая оптика или косметологическая клиника с мед. данными клиентов или учебный центр с персональными данными несовершеннолетних не менее остро нуждаются в закрытом контуре обработки данных.

Он прем под заказчика\по согласованию и онпрем из коробки это абсолютно разные продукты, не говоря о их стоимости, фактически по ссылкам корпоративные варианты с доступом по заявке\индивидуальному предложению через менеджеров, с согласованием, лицензиями, и это уже точно не в "один клик"

Вы писали "в РФ есть уже готовые продукты, которые позволяют для бизнеса в один клик начать пользоваться ими", я таких предложений найти не смог, он прем с стартом за 15 минут без ограничений на генерацию, количество документов и пользователей никто не предлагает

По всем ссылкам Вы привели приведены только SaaS решения, ограниченные по количеству документов, генераций и пользователям.

При этом ни по одной ссылке нет решений для локального развертывания, тем более за 15 минут от старта до первого запроса и без ограничений на обьем документов, количество запросов и пользователей.

Локализация основная проблема корпоративных систем, вряд ли условная бухгалтерия или отдел кадров вместе с производством, захочет слить все свои корпоративные документы (первичку, личные дела работников, технологические карты и регламенты) тому же ИП, которого Вы привели в одной из ссылок

Вы очень точно сформулировали позицию сторонников фреймворков, и в Ваших тезисах действительно есть рациональное зерно.
Фреймворк отличный вариант для старта, для нетребовательных пайплайнов и 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 как стандарт опережали время, многослойная архитектура позволяла конфигурировать периферию на свой вкус, а размеры и промышленное исполнение позволяли интегрировать платы этого стандарта куда угодно от авто до спутников

Насколько линейно рост в геометрической прогрессии объема создаваемых данных влияет на количество судебных споров, связанных с защитой интеллектуальной собственности. По ссылке из статьи:

  1. 2023год - 52 620 ,

  2. 2022год - 43 608,

  3. 2021год - 33 863

При этом в 2022 году больше 10% споров инициировал один заявитель

Вопрос интересный, особенно с учетом того, что в последнее время чаще начинают заявлять о возможном нарушении авторских прав на произведения, которые были использованы для обучения AI моделей. Фактически генерация не является переработанным произведением, но с позиции самой модели, AI модель при генерации заимствует именно фрагменты - токены из этих "нелегальных" датасетов, а не генерирует из набора символов. По сути речь идет о фрагментах чужих произведений, грубо говоря собранных AI по требованию пользователя, основная дилемма - могут ли такие действия могут порождать авторские права

Information

Rating
460-th
Registered
Activity

Specialization

ML разработчик, AI разработчик
Ведущий
From 620,000 ₽
Git
Python
Базы данных
C++
Разработка программного обеспечения
Программирование микроконтроллеров
C#
PHP
Laravel
SQL