Подивіться:
Ви ніколи, навіть у мільйон років, не побудуєте свою власну систему управління взаємовідносинами (CRM) або власну систему управління контентом (CMS) - або, у більшості випадків, свою власну мову природньої мови (LLM).
Чи зробили б ви?
І все ж, скрізь, куди я не гляну, я бачу відділи ІТ, які переконують себе, що побудова власної чат-системи на основі RAG якось відрізняється. Ні, це навіть гірше.
Кредит зображення: Alden Do Rosario
Дозвольте мені намалювати вам картину: Минулого тижня я стежив, як команда блискучих інженерів демонструвала свою власну новеньку RAG-пайплайн. Все побудовано вдома. Вони були пишні. Вони були захоплені. Вони мали векторні вкладення! Вони мали інженерію промпта! Вони мали… не мали уявлення про те, що їм належить очікувати.
І повірте мені, я бачив цей фільм раніше. Кілька разів. Він завжди закінчується однаково: вигорілими інженерами, розгорілими бюджетами і CTO, який дивується, чому вони не просто придбали рішення в першу чергу.
Пастка "Це Виглядає Просто"
Розумію. Дійсно, розумію. Ви дивитесь на RAG і думаєте:
"Векторна БД + LLM = Готово!"
Додайте кілька відкритих вихідних інструментів, можливо, додайте деяку Langchain (о, ми дійдемо до цього), і ви готові до руху, чи не так?
Ні. Так, так неправильно.
Дозвольте розповісти вам про компанію середнього ринку, з якою я нещодавно спілкувався. Їхній "простий" проект RAG розпочався у січні. Квітнем вони мали:
- 1 інженера на повний робочий день, який виправляв галюцинації та проблеми з точністю.
- 1 людину з даними на повний робочий день, яка мала справу з проблемами ЕТЛ та інгестию.
- 1 інженера DevOps на повний робочий день, який боровся з проблемами масштабованості та інфраструктури.
- 1 дуже незадоволеного CTO, який дивився на бюджет, який зросла втричі.
І це навіть не найгірше. Найгірше було спостерігати, як вони повільно розуміли, що те, що виглядало як двомісячний проект, насправді стане постійним кошмаром.
- Формати документів та різноманітні проблеми з PDF (спробуйте імпортувати epub)
- Проблеми точності у виробництві (О, чекайте - все добре працювало на тестуванні, але виробниче використання перед справжніми користувачами не задовольняє!)
- Галюцинації!
- Перевірка якості відповідей
- Інтеграція з існуючими системами
- Захоплення даних змін (наприклад, дані на веб-сайті змінюються, чи залишається RAG синхронізованим?)
- Вимоги щодо відповідності та аудиту
- Проблеми з безпекою та витоки даних (чи буде ваш внутрішній система відповідати вимогам SOC-2 типу 2?)
Кожна з цих проблем може бути окремим проєктом. Кожне має свої власні підводні камені. Кожен може затягнути ваш графік.
Витрати, про які ніхто не говорить
"Але у нас є таланти! У нас є інструменти! Open source безкоштовний!"
Зупиніться. Просто попрощайте.
Дозвольте мені розкласти справжні витрати вашої "безкоштовної" системи RAG:
Витрати на інфраструктуру
- Хостинг векторної бази даних
- Витрати на інференцію моделі
- Середовища розробки
- Тестові середовища
- Виробничі середовища
- Системи резервного копіювання
- Системи моніторингу
Витрати на персонал
- Інженери з машинного навчання ($150-250 тис. на рік)
- Інженери з DevOps ($120-180 тис. на рік)
- Спеціалісти з безпеки штучного інтелекту ($160-220 тис. на рік)
- Спеціалісти з контролю якості ($90-130 тис. на рік)
- Менеджер проєкту ($100-200 тис. на рік)
Операційні витрати
- Моніторинг 24/7
- Оновлення безпеки
- Оновлення моделей
- Чищення даних
- Оптимізація продуктивності
- Оновлення документації
- Навчання нових членів команди
- Перевірка відповідності вимогам
- Паритет функцій (при розвитку штучного інтелекту)
І ось у чому справа: поки ви витрачаєте гроші на побудову всього цього, ваші конкуренти вже знаходяться в виробництві зі своїм купленим рішенням, витрачаючи частину витрат.
Чому ви запитуєте?
Тому що куплене рішення було протестовано на тисячах клієнтів. І вартість його побудови також була амортизована на тисячах клієнтів.
У вашому випадку, загальний час і витрати коштів були "Розділені на один"
Кошмар з безпеки
Хочете втратити сон? Спробуйте бути відповідальним за систему штучного інтелекту, яка:
- Має доступ до всього корпоративного банку знань вашої компанії
- Може випадково витікати конфіденційна інформація
- Може спричиняти галюцинації конфіденційними даними
- Потребує постійного оновлення безпеки
- Може бути вразливим на атаки впровадження коду
- Може викривати внутрішні дані через відповіді моделі
- Може бути уразливим на атаки з боку злоумисників
Нещодавно я спілкувався з головним інформаційно-безпековим офіцером, який виявив, що їх внутрішня система RAG випадково витікала заголовки внутрішніх документів через свої відповіді. Це були веселі часи. Вони провели три тижні, щоб виправити це. Потім вони знайшли ще п'ять подібних проблем.
І вгадайте, що? Загрози розвиваються швидше, ніж ваша команда може поспішати. Захисні заходи, які були введені минулого місяця, можуть бути застарілими уже сьогодні. Поверхня атак постійно розширюється, а погані актори стають більш витонченими.
Подумайте про це: кожен новий документ, який ви додаєте до банку знань, - це потенційний ризик безпеки. Кожний запит є вектором атаки. Кожна відповідь потребує перевірки. Тут не лише про те, щоб побудувати безпечну систему - йдеться про забезпечення безпеки в середовищі, що щоденно змінюється.
Жахливе Шоу Підтримки
Пам'ятаєте той стартап, про який я згадував, який запустився за допомогою Langchain? Ось що відбулося потім:
- Тиждень 1: Все працює відмінно
- Тиждень 2: Проблеми з латентністю
- Тиждень 3: Дивні випадкові ситуації
- Тиждень 4: Повна переробка
- Тиждень 5: Нові проблеми з галюцинаціями
- Тиждень 6: Новий проект з обробки даних
- Тиждень 7: Міграція бази даних векторів та проблеми з продуктивністю
- Тиждень 8: Ще одна переробка
Вони не самі. Це типовий життєвий цикл внутрішньої системи RAG. І далі буде ще цікавіше (гірше):
Щоденні завдання з обслуговування
- Моніторинг якості відповідей
- Перевірка галюцинацій
- Відлагодження випадкових ситуацій
- Вирішення проблем обробки даних
- Управління квотами API та проблемами інфраструктури
Щотижневі завдання з обслуговування
- Оптимізація продуктивності
- Аудити безпеки
- Перевірки якості даних
- Аналіз зворотнього зв'язку користувачів
- Оновлення системи
Щомісячні завдання з обслуговування
- Тестування великого масштабу
- Оновлення моделей штучного інтелекту (AI Model Updates)
- Перевірки відповідності
- Оптимізація витрат
- Планування потужностей
- Перегляд архітектури
- Вирівнювання стратегії
- Запити на функціонал
І все це потрібно робити, коли ви також намагаєтеся додавати нові функції, підтримувати нові сценарії використання та доводити до задоволення бізнес.
Проблема недоліку експертності
"Але у нас є відмінні інженери!"
Так, у вас є. Але RAG - це не просто інженерія. Дозвольте мені розкласти, що вам справді потрібно:
Операції з Машинним Навчанням
- Експертіза розгортання моделей
- Керування конвеєром RAG
- Контроль версій для моделей
- Оптимізація точності
- Керування ресурсами
- Знання масштабування
Експертиза з RAG
- Розуміння точності
- Оптимізація проти галюцинацій
- Оптимізація вікна контексту
- Розуміння затримки та витрат
- Інженерія запитань
- Метрики якості
Знання Інфраструктури
- Оптимізація векторної бази даних
- Запис та моніторинг
- Керування API
- Оптимізація витрат
- Архітектура масштабування
Експертиза з Безпеки
- Специфічні заходи забезпечення AI
- Запобігання шпигунству
- Управління конфіденційністю даних
- Контроль доступу
- Журналювання аудиту
- Управління відповідністю
І вдачі вам з наймом всього цього на ринку. Навіть якщо ви можете знайти цих людей, ви можете собі їх дозволити? Чи зможете зберегти їх? Тому що кожна інша компанія також шукає талант.
And more importantly: Чи ваша команда RAG (Retrieve, Analyze, Generate) також буде вдосконалювати своє обслуговування та додавати більше функцій та покращувати ключові показники ефективності, такі як точність та антигалюцинація, як це роблять інші платформи RAG? Чи плануєте ви це робити протягом наступних 20 років? (Accuracy, Anti-Hallucination)
Реальність швидкості введення на ринок
Під час розробки вашої системи RAG:
- Ваші конкуренти вже використовують виробничі рішення
- Технологія розвивається (іноді щотижнево)
- Ваші вимоги змінюються
- Ваш бізнес втрачає можливості
- Ринок рухається вперед
- Ваш початковий дизайн стає застарілим
- Очікування користувачів (прослуховувачів подій) зростають щодня.
Давайте поговоримо про реальний графік для створення готової до виробництва системи RAG:
Місяць 1: Початкова розробка
- Основна архітектура
- Перший прототип
- Початкове тестування
- Перші відгуки
Місяць 2: Настання реальності
- Виявлення проблем з безпекою
- Погіршення продуктивності
- Поверхневе множення випадкових ситуацій
- Зміна вимог
Місяць 3: Перебудова
- Виправлення архітектури
- Покращення безпеки
- Оптимізація продуктивності
- Оновлення документації
Місяць 4: Готовність для підприємств
- Впровадження відповідності
- Налагодження моніторингу
- Відновлення після аварій
- Навчання користувачів
І це якщо все пройде добре. Що, звісно, не станеться. Почекайте, поки все дійде до виробництва!
Альтернатива - Покупка
Подивіться, я не кажу, що ніколи не будуйте. Я кажу, будьте розумними у тому, що й чому ви будуєте.
_Кредит зображення: CustomGPT.
markdown
Сучасні рішення RAG включають:
Управління Інфраструктурою
- Масштабована архітектура
- Автоматичні оновлення
- Оптимізація продуктивності
- Забезпечення безпеки
Функції для підприємств
- Контроль доступу на основі ролей
- Журналювання аудиту
- Управління відповідністю
- Контроль конфіденційності даних
Операційні переваги
- Кваліфікована підтримка
- Регулярні оновлення
- Патчі безпеки
- Моніторинг продуктивності
Бізнес-переваги
- Швидкість виходу на ринок
- Зменшення загальних витрат
- Зменшення ризику
- Перевірені рішення
Коли варто будувати?
Добре, добре. Є три сценарії, коли будування має сенс:
1. У вас є дійсно унікальні регулятивні вимоги, які жоден постачальник не може виконати
- Спеціальні урядові регуляції
- Специфічні потреби щодо відповідності галузі
- Унікальні протоколи безпеки
2. Ви розробляєте RAG як ваш основний продукт
- Це ваша основна пропозиція цінності
- Ви інноваційні в цій галузі
- У вас є глибока експертиза
3. У вас є необмежені час і гроші (якщо це про вас, тоді зателефонуйте мені)
- Справді, цього не існує
- Навіть з ресурсами, вартість можливості має значення
- Час виходу на ринок все ще важливий
Що раджу робити замість будування
1. Сконцентруйтеся на реальних проблемах вашого бізнесу
- Що справді намагаються досягнути ваші користувачі?
- Які ваші унікальні пропозиції цінності?
- Де ви можете зробити найбільший вплив?
2. Оберіть надійного постачальника RAG
- Оцініть на основі ваших потреб (Підказка: Подивіться на випадки використання)
- Перевірте сертифікацію безпеки (Підказка: Перевірте на наявність SOC-2 тип 2)
- Перевірте готовність для підприємств (Підказка: Запитайте про випадки використання!)
- Протестуйте продуктивність (Підказка: Подивіться опубліковані бенчмарки)
- Перевірте якість підтримки (Підказка: Зателефонуйте в підтримку!)
3. Витрачайте час інженерії на речі, які дійсно виділяють ваш бізнес
- Користувацькі інтеграції
- Унікальні функції
- Бізнес-логіка
- Користувацький досвід
Тому ось правда: Через п'ять років нікому не буде цікаво, чи ви будували або купували свою систему RAG. Їх цікавитиме лише, чи була вирішена їхня проблема.
Висновок
Припиніть намагатися перетворити колесо.
Особливо коли це колесо насправді складний, заснований на штучній інтелекті космічний апарат, який потребує постійного обслуговування і може вибухнути, якщо ви допустите помилок в деталях.
Створення власної системи RAG - це як вирішення побудувати свій власний поштовий сервер у 2024 році. Звісно, ви можете це зробити. Проте чому б вам це було потрібно?
Ваша майбутня я вас подякує. Ваши інженери вас подякують. Ваш бюджет вам подякує.
І найголовніше, ваш бізнес вам подякує, коли ви насправді вирішуватимете реальні проблеми, а не відлажуватимете проблеми з точністю о 3 ранку.
Вибір за вами. Проте будь ласка, оберіть мудро.
Перекладено з: Dear IT Departments, Please Stop Trying To Build Your Own RAG