Уважаемые ИТ-отделы, пожалуйста, перестаньте пытаться создать свои собственные RAG
Смотрите:
Вы никогда и ни за что на свете не стали бы создавать собственную CRM-систему или CMS, или тем более LLM.
Не так ли?
И все же, куда бы я ни посмотрел, я вижу, как ИТ-отделы убеждают себя в том, что создание собственного чата на основе RAG - это нечто иное. Это не так. Это даже хуже.
Позвольте мне в общих чертах обрисовать картину: На прошлой неделе я наблюдал за тем, как команда блестящих инженеров демонстрировала свой новый выдающийся трубопровод RAG. Все построено собственными силами. Они были горды. Они были взволнованы. У них были векторные вложения! У них был быстрый инжиниринг! Они... понятия не имели, что их ждет дальше ….
А я знаю, чем все это закончится. Я такое видел уже очень много раз. Заканчивается он всегда одинаково: сгоревшие инженеры, сбитые бюджеты и технический директор, задающийся вопросом, почему они не купили готовое решение с самого начала.
Ловушка под названием “Легкотня”
Я понимаю. Правда, понимаю. Вы смотрите на RAG и думаете:
“Векторная БД + LLM = Готово!”
Добавьте несколько инструментов с открытым исходным кодом, может быть, немного Langchain (о, мы еще вернемся к этому), и все готово, верно?
Нет. Вы очень сильно заблуждаетесь.
Позвольте мне рассказать вам о компании среднего размера, с которой я недавно общался. Их «простой» проект RAG стартовал в январе. К марту у них было:
- 1 штатный инженер, отлаживающий галлюцинации и проблемы с точностью.
- 1 штатный специалист по данным, занимающийся проблемами ETL и ввода данных.
- 1 штатный инженер DevOps, борющийся с проблемами масштабируемости и инфраструктуры.
- 1 очень недовольный технический директор, смотрящий на бюджет, который увеличился в три раза.
И это еще не самое страшное. Хуже всего было наблюдать за тем, как они осознают, что то, что выглядело как двухмесячный проект, на самом деле превратилось в сплошной кошмар…
Вот всего лишь несколько вещей, о которых они даже и не догадывались:
- Сложность предварительной обработки документов и баз знаний (попробуйте импортировать данные из различных источников, таких как Sharepoint, Google Drive и веб-сайты)
- Форматы документов и всевозможные проблемы с PDF (попробуйте импортировать epub).
- Проблемы с точностью в производстве (но, подождите - в тестировании все работало хорошо, так почему же использование в производстве с реальными пользователями - полный отстой?!!)
- Галлюцинации!
- Обеспечение качества ответов
- Интеграция с существующими системами
- Сбор данных об изменениях (например, данные об изменениях на сайте)
- Соответствие нормативным требованиям и аудит
- Вопросы безопасности и утечки данных (будет ли Ваша внутренняя система соответствовать требованиям SOC-2 Type 2?)
Каждый из этих аспектов вполне может стать отдельным проектом. В каждом из них есть свои сложности. Каждый из них может взорвать Вашу систему.
Затраты, о которых почему – то никто не думает и не говорит
«Но у нас есть талант! У нас есть инструменты! Открытый исходный код бесплатен!»
Остановитесь, просто остановитесь.
Позвольте мне рассказать о реальных затратах на вашу «бесплатную» систему RAG:
Затраты на инфраструктуру
- Хостинг векторной БД
- Затраты на вывод модели
- Развитие среды
- Тестирование среды
- Развитие производственной среды
- Систем бэкапа
- Системы мониторинга
Затраты на персонал
- ML -инженеры ($150k-$250k/год)
- Инженеры DevOps ($120k-$180k/год)
- Специалисты по безопасности в области ИИ ($160k-$220k/год)
- Специалисты по обеспечению качества ($90k-$130k/год)
- Менеджер проекта ($100k-$200k/год)
Постоянные операционные расходы
- Мониторинг 24/7
- Обновления в области безопасности
- Обновление модели
- Очистка данных
- Оптимизация производительности
- Обновление документации
- Обучение новых членов команды
- Аудит
- Паритет характеристик (по мере развития ИИ)
И вот в чем загвоздка: пока Вы сжигаете деньги, создавая все это, ваши конкуренты уже вовсю работают с купленным решением, затрачивая на него в разы меньше средств.
Почему, спросите Вы?
Потому что купленное решение было протестировано на тысячах клиентов. И стоимость его создания тоже была амортизирована тысячами клиентов. В Вашем случае все затраты времени и денег были «поделены на один”.
Кошмар, связанный с безопасностью
Хотите потерять сон? Тогда возьмите на себя ответственность за систему искусственного интеллекта, которая:
- Имеет доступ ко всей базе знаний Вашей компании
- Может вызывать утечку конфиденциальной информации
- Может создавать галлюцинации с конфиденциальными данными
- Нуждается в постоянном обновлении системы безопасности
- Может быть уязвима к атакам с использованием оперативной инъекции
- Может раскрывать внутренние данные через ответы модели
- Может быть подвержена хакерским атакам
Недавно я разговаривал с CISO, который обнаружил, что их внутренняя система RAG пропускает названия внутренних документов через свои ответы. Веселое время. Они потратили три недели на устранение этой проблемы. Затем они обнаружили еще пять подобных проблем.
И знаете что? Угрозы развиваются быстрее, чем Ваша команда успевает за ними следить. Меры безопасности, принятые в прошлом месяце, уже сегодня могут оказаться устаревшими. Атаки становятся все более изощренными, а злоумышленники - все более агрессивными.
Подумайте вот о чем: каждый новый документ, который Вы добавляете в свою базу знаний, представляет собой потенциальный риск для безопасности. Каждый запрос - это вектор атаки. Каждый ответ должен быть проверен. Речь идет не только о создании защищенной системы, но и о поддержании безопасности в среде, которая меняется ежедневно.
Шоу ужасов по обслуживанию системы
Помните тот стартап, запустившийся с помощью Langchain? Вот что произошло дальше:
- Неделя 1: Все работает отлично
- Неделя 2: Проблемы с задержкой
- Неделя 3: Странные случаи
- Неделя 4: Полный рерайт
- Неделя 5: Новые проблемы с галлюцинациями
- Неделя 6: Новый проект по обработке данных.
- Неделя 7: Миграция векторной БД и проблемы с производительностью
- Неделя 8: Очередной рерайт
Они далеко не одиноки в своей еженедельной борьбе. Таков типичный жизненный цикл внутренней системы RAG. И он становится все хуже и хуже день ото дня:
Ежедневные задачи по обслуживанию
- Контроль качества реакции
- Проверка на наличие галлюцинаций
- Отладка нестандартных ситуаций
- Решение проблем с обработкой данных.
- Управление квотами API и проблемами инфраструктуры.
Еженедельные задачи по обслуживанию
- Оптимизация производительности
- Аудит безопасности
- Проверка качества данных
- Анализ отзывов пользователей
- Обновление системы
Ежемесячные задачи по обслуживанию
- Крупномасштабное тестирование
- Обновление моделей искусственного интеллекта.
- Проверка соответствия требованиям
- Оптимизация затрат
- Планирование мощностей
- Анализ архитектуры
- Согласование стратегии
- Запросы на функциональность
И все это должно происходить в то время, когда Вы пытаетесь добавлять новые функции, поддерживать новые сценарии использования и делать бизнес счастливым и прибыльным.
Пробел в знаниях и опыте
“Но у нас супер инженеры!!!”
Безусловно, я и не спорю. Но RAG – это не только про инжиниринг. Это еще и:
Операции ML
- Опыт развертывания модели LLM
- Управление конвейером RAG
- Контроль версий для моделей
- Оптимизация точности
- Управление ресурсами
- Знания о масштабировании
Знания и опыт в области RAG
- Точность понимания
- Оптимизация против галлюцинаций
- Оптимизация контекстного окна.
- Понимание задержки и затрат.
- Оперативное проектирование
- Метрики качества
Знание инфраструктуры
- Оптимизация векторной базы данных
- Ведение журналов и мониторинг.
- Управление API
- Оптимизация затрат
- Масштабируемая архитектура
Экспертиза в области безопасности
- Меры безопасности, специфичные для ИИ
- Предотвращение инъекций
- Управление конфиденциальностью данных
- Контроль доступа
- Ведение журнала аудита
- Управление соответствием нормативным требованиям
И удачи в найме на этом рынке. Даже если Вы найдете всех этих людей, сможете ли Вы их себе позволить? Сможете ли Вы их удержать? Ведь все остальные компании тоже ищут такие же таланты.
И что еще более важно: По мере того как другие платформы RAG продолжают совершенствовать свой сервис, добавлять новые функции и улучшать KPI, такие как точность и антигаллюцинация, будет ли Ваша команда RAG делать то же самое? В течение следующих 20 лет?
Реальность времени выхода на рынок
Пока Вы создаете свою систему RAG:
- Ваши конкуренты внедряют производственные решения
- Технологии развиваются (иногда еженедельно)
- Ваши требования меняются
- Ваш бизнес теряет возможности
- Рынок движется вперед
- Ваш первоначальный дизайн устаревает.
- Ожидания пользователей (с учетом OpenAI) растут с каждым днем.
Давайте поговорим о реальных сроках создания готовой к производству системы RAG:
Месяц 1: Начальный этап разработки
- Базовая архитектура
- Первый прототип
- Первоначальное тестирование
- Первые отзывы
Месяц 2: Столкновение с реальностью
- Возникают проблемы с безопасностью
- Возникают проблемы с производительностью
- Возрастает количество нестандартных ситуаций
- Меняются требования
Месяц 3: Пересмотр
- Изменения в архитектуре
- Улучшения в области безопасности
- Оптимизация производительности
- Доработка документации
Месяц 4: Доведение до ума
- Внедрение политики в области комплаенс
- Настройка мониторинга
- Аварийное восстановление
- Обучение пользователей
И это если все пройдет хорошо. А так точно не будет. Просто подождите, пока не начнется производство!
Покупка готового решения
Стоп, я не говорю, что строить не надо вообще. Я говорю, что нужно с умом подходить к тому, что и зачем Вы строите.
Современные решения RAG предлагают своим пользователям следующее:
Управление инфраструктурой
- Масштабируемая архитектура
- Автоматические обновления
- Оптимизация производительности
- Поддержка безопасности
Функции предприятия
- Управление доступом на основе ролей
- Ведение журнала аудита
- Управление соответствием нормативным требованиям
- Контроль конфиденциальности данных
Операционные преимущества
- Экспертная поддержка
- Регулярные обновления
- Патчи безопасности
- Мониторинг производительности
Преимущества для бизнеса
- Ускоренное время выхода на рынок
- Снижение общих затрат
- Снижение рисков
- Проверенные решения
В каких случаях стоит строить свое собственное решение?
Ладно, хорошо. Есть ровно три случая, в которых создание собственного решения действительно имеет смысл:
1. У вас действительно уникальные нормативные требования, которые не может выполнить ни один поставщик
- Нестандартные государственные нормативы
- Специфические отраслевые требования к соответствию
- Уникальные протоколы безопасности
2. Вы создаете RAG как основной продукт.
- Это Ваше основное ценностное предложение
- Вы внедряете инновации в этой области
- Вы обладаете глубокой экспертизой в этой области
3. У вас неограниченное время и деньги (если это Вы, позвоните мне).
- Если серьезно, то такого не существует.
- Даже при наличии ресурсов стоимость решения имеет значение
- Время выхода на рынок все еще имеет значение
Вот что вы должны делать вместо этого
1. Сосредоточьтесь на реальных бизнес-проблемах
- Чего на самом деле пытаются добиться Ваши пользователи?
- Каковы Ваши уникальные ценностные предложения?
- Где Вы можете оказать наибольшее влияние?
2. Выберите надежного поставщика RAG
- Оценивайте с учетом своих потребностей (подсказка: изучите примеры из практики).
- Проверьте полномочия в области безопасности (Подсказка: проверьте наличие SOC-2 тип 2)
- Проверьте готовность предприятия (Подсказка: попросите привести примеры из практики!)
- Проверьте производительность (Подсказка: посмотрите опубликованные контрольные показатели)
- Проверьте качество поддержки (подсказка: позвоните в службу поддержки!)
3. Тратьте свое инженерное время на вещи, которые действительно выгодно выделяют Ваш бизнес
- Пользовательские интеграции
- Уникальные функции
- Бизнес-логика
- Пользовательский опыт
Потому что вот правда: через пять лет никому не будет дела до того, создали Вы или купили свою систему RAG. Их будет волновать только то, что их задача решена.
Заключение
Хватит пытаться изобрести колесо. Особенно если это колесо - сложный космический корабль с искусственным интеллектом, который нуждается в постоянном обслуживании и может взорваться, если Вы ошибетесь в малейших деталях.
Создать собственную систему RAG - все равно что решить создать собственный сервер электронной почты в 2024 году. Конечно, Вы можете это сделать. Но зачем?
Ваше будущее скажет Вам спасибо. Ваши инженеры скажут Вам спасибо. Ваш бюджет скажет Вам спасибо.
И, что самое важное, Ваш бизнес скажет Вам спасибо, когда Вы будете решать реальные проблемы, а не отлаживать проблемы точности в три часа ночи.
Выбор за Вами. Но, пожалуйста, выбирайте с умом.
