1,483 показання
1,483 показання

Ця єдина практика полегшує створення, тестування та масштабування LLM

за Andrew Prosikhin7m2025/04/07
Read on Terminal Reader

Надто довго; Читати

Промо модуляризація LLM дозволяє безпечно вводити зміни до вашої системи з плином часу.
featured image - Ця єдина практика полегшує створення, тестування та масштабування LLM
Andrew Prosikhin HackerNoon profile picture

Це частина поточної серії: див first і друга публікація.

першийдругий

Принцип III: Модуляризація перспектив

Кожен досвідчений інженер бачив одне: код, який настільки великий, високий ризик, і важко зрозуміти, що ніхто не наважиться доторкнутися до нього. Немає жодних одиниць тестування, кожна зміна є причиною невеликого серцевого нападу. Єдині, хто втягується поруч з ним, це старі таймери - ті, хто був навколо, коли монстр був побудований, і вони тільки наближаються, коли немає альтернативи.


Я пам'ятаю першу монструозність, з якою я зіткнувся. 5000-лінійна функція, яка була центральною для операцій бізнесу, вартістю сотні мільйонів доларів; майже ніхто не мав впевненості, щоб доторкнутися до неї.Коли вона розірвалася, цілі команди прокинулися в середині ночі.Все розвиток в компанії сповільнювалося через залежність від цього ключового компонента.Мільйони доларів витрачалися, намагаючись управляти монстром.


Що все це має спільного з запрошеннями LLM? Вони також можуть стати монструаціями! Настільки страшно змінюватися, що їх ніхто не торкається.


Що потрібно клієнтам

Клієнти не хочуть платити за програмне забезпечення, яке працює належним чином лише у вівторок і четвер; вони вимагають постійної надійності та потоку нових функцій.


Так, як ви отримуєте здорове додаток AI, а не монструозність? Є більше десятка підходів, всі охоплені в цій серії.Всі вони починаються з одного принципу: замість одного гінормового запрошення, ви хочете кілька менших орієнтованих запрошень, кожна з яких спрямована на вирішення однієї проблеми.


Що таке модуляція

Модуляризація - це практика розщеплення складної системи на менші, самостійні та багаторазові компоненти.У традиційній інженерії програмного забезпечення це означає написання функцій, класів та послуг, кожна з яких виконує певне завдання.У контексті спот-інженерії для LLM, модуляризація означає розщеплення великого, монолітного спот на менші, орієнтовані спот - кожен призначений для виконання однієї, чітко визначеної роботи.


Переваги модуляції

Модуляризація дозволяє безпечно впроваджувати зміни у вашу систему з плином часу.

  • Тривалість часу, протягом якого програма буде підтримуватися, збільшується.
  • Число і складність функцій, які очікується додати, збільшуються.
  • Вимоги до надійності системи стають більш суворими.
  • Тривалість часу, протягом якого буде підтримуватися заявка, збільшується.
  • Число і складність функцій, які очікується додати, збільшуються.
  • Вимоги до надійності системи стають більш суворими.
  • Всі ці виміри необхідно розуміти при плануванні системи.


    Але як конкретно модуляція допомагає підтримувати систему?

    Зниження ризику

    Виконання проб LLM по своїй суті нестійке. Їхня природа така, що будь-яка зміна може вплинути на вихід непередбачуваними способами. Ви можете управляти цим ризиком, розбиваючи великі проби на компоненти, де зміна може вплинути тільки на продуктивність частини системи. Навіть якщо одна пробка порушена, решта системи працюватиме так само, як і до зміни.



    Але що, якщо виклики працюють як ланцюг? Чи не розірвання одного компонента все одно розірвало б ланцюг? Так, це було б, але пошкодження все ще зменшується в цьому сценарії. Помилковий вихід в ланцюгу викликів може забезпечити виклики внизу ланцюга помилковими входами, але кожен компонент все ще працюватиме, як і до зміни набору дійсних входів. Контрастуйте це з зміною гігантського виклику - зміна може (і буде!) впливати на кожен шматок логіки, кодованої в цьому виклику. Ви не розірвали один аспект системи - ви потенційно розірвали кожну частину його.


    (Безпечна експлуатація ланцюгів запитів є майбутньою главою серії.Ви повинні планувати різні типи збоїв і мати плани надзвичайних ситуацій.

    Поліпшення випробуваності

    Кожен, хто мав написані одиничні тести, знає, що просту функцію, яка виконує одну річ, простіше перевірити, ніж складну функцію, яка намагається виконувати багато різних речей.

    Найкраща продуктивність

    Широкий спектр доказів показує, що короткі промови, як правило, перевершують більш довгі: 1, 2, 123


    Дослідження щодо впливу багатозадач на швидку продуктивність більш змішане: 4, 5. Досконало оптимізований запрос може, за правильних обставин, багатозадач. Хоча на практиці набагато простіше оптимізувати орієнтовані запроси, де можна відстежувати45

    Легкість обміну знаннями

    Пояснення складності супер-промпту з 3 тисячами слів новому учаснику команди - це подорож.І незалежно від того, скільки ви пояснюєте, єдиними, хто має почуття для цього звіра, будуть автори, які вносять свій внесок.


    Система сповіщень, при якій кожна частина є відносно простою, може бути введена на борт набагато швидше; інженери почнуть бути продуктивними раніше.

    Оптимізація витрат

    Використовуючи різні моделі в різних частинах системи, можна досягти значної економії витрат і затримки, не впливаючи на якість відповіді.


    Наприклад, запит, який визначає мову введення, не повинен бути особливо розумним - він не вимагає вашої останньої і найдорожчої моделі. З іншого боку, запит, який генерує відповідь на основі документації, може отримати вигоду від вбудованого ланцюг міркувань, вбудованого в моделі високого класу.

    Редагувати


    Коли не можна модулізувати

    Більшість програмних додатків вимагають безпечного додавання функцій протягом тривалого періоду часу. Проте є виняток. Прототипні додатки не призначені для тривалого зберігання; вони не отримають нових функцій, і не призначені для високої надійності. Так що не марнуйте час на модуляризацію при будівництві прототипів. Насправді, більшість зразків у цій серії не застосовуються до прототипних додатків.


    Друга увага полягає в тому, щоб знати, коли припинити модуляризацію.Відмінність полягає в тому, щоб керувати додатковими запрошеннями, і якщо переваги подальшої модуляризації низькі - ви повинні припинити продовжувати руйнувати систему.


    Інфраструктура для модуляції

    Якби модуляризація проб була тривіальною - всі б це робили. Щоб управляти багатьма пробками в системі, вам потрібно інвестувати в інфраструктуру - без неї ви отримаєте хаос. Ось мінімальні вимоги до інфраструктури проб LLM:

    • Здатність швидко і безболісно додавати промпти стандартизованим способом. Особливо важливо, коли промпти завантажуються ззовні кодової бази. Див Принцип II: Завантажити промпти безпечно (якщо вам дійсно потрібно).

    • Здатність розгортати промпти автоматизованим способом.

      <

    • Здатність швидко і безболісно додавати запити у стандартизований спосіб. Особливо важливо, коли запити завантажуються з-за межі бази кодів. Дивіться Принцип II: Завантажити запити безпечно (якщо вам дійсно потрібно).

    • Здатність швидко і безболісно додавати запрошення у стандартизований спосіб. Особливо важливо, коли запрошення завантажуються ззовні бази кодів. Див. Принцип II: Завантажити запрошення безпечно (якщо вам дійсно потрібно).

      Принцип II: Завантаження швидко безпечно (Якщо Ви дійсно повинні)
    • Здатність розгортати прохання автоматизованим способом.

    • Здатність розгортати запрошення автоматизованим способом.

    • Здатність реєструвати та контролювати входи/виходи окремих запрошень.

    • Здатність реєструвати та контролювати входи/виходи окремих запрошень.

    • Здатність додавати автоматизовані тести, які охоплюють запрошення.

    • Здатність додавати автоматизовані тести, які охоплюють запрошення.

    • А спосіб легко відслідковувати токен / $ витрати на різних запропонованих.


    • Як легко відслідковувати token / $ витрати на різних промптах.


      Дослідження випадків

      Давайте подивимося, як побудова системи Gen AI працює на практиці з модуляризацією і без неї.

      Без модуляції

      У найпростішій версії, ви можете уявити монолітний запрошення, яке генерує відповіді при завантаженні відповідної документації через RAG.


      RAG

      Unmodularized Система

      Unmodularized Система

      Виглядає приємно і легко, чи не так? Але коли ви додаєте функції - виникають проблеми з цією архітектурою:

      • Ви хочете відповідати на повідомлення в фіксованому списку мов, але не справлятися з іншими. Щоб досягти цього, ви додаєте пробні інструкції, щоб відповідати тільки в певних мовах і отримати LLM, щоб повернути "мовне" поле для звітування.

      • Ви хочете, щоб всі розмови були класифіковані. Додати поле "етикетка" до виходу пробного.

        Коли користувач не задоволений - ескалація справи до людської підтримки. Додати вихідну змінну "ескалація_на_людина" разом з інструкціями в пробному.

      • Потрібен переклад всіх повідомлень, відправлених

      • Ви хочете відповідати на повідомлення в фіксованому списку мов, але не справлятися з іншими.Для цього ви додаєте негайні інструкції, щоб відповісти тільки на певних мовах і отримати LLM, щоб повернути поле «мова» для звітування.

      • Ви хочете відповідати на повідомлення в фіксованому списку мов, але не справлятися з іншими.Для цього ви додаєте пробні інструкції, щоб відповісти тільки на певних мовах і отримати LLM, щоб повернути поле «мова» для звітування.

      • Ви хочете, щоб всі розмови були класифіковані. Додайте поле «етикетка» до пробного виходу.

      • Ви хочете, щоб всі розмови були класифіковані. Додайте поле «етикетка» до запропонованого виходу.

      • Коли користувач незадоволений - ескалація справи до людської підтримки.Додайте змінну виходу «escalate_to_human» разом з інструкціями в посібнику.

      • Коли користувач незадоволений - ескалація справи до людської підтримки. Додайте змінну виходу «escalate_to_human» разом з інструкціями в посібнику.

      • Потрібен переклад всіх повідомлень, відправлених для внутрішнього аудиту.Поверніть поле «перекладено» з повідомленням англійською мовою.

      • Потрібен переклад всіх повідомлень, надісланих для внутрішнього аудиту.Поверніть поле «перекладено» з повідомленням англійською мовою.

      • Потрібна захист, щоб гарантувати, що додаток ніколи не запитує користувачів про їх місцезнаходження і за кого вони проголосували на останніх виборах.

        Потрібна захист, щоб переконатися, що додаток ніколи не запитує користувачів про їх місцезнаходження і за кого вони проголосували на останніх виборах.

      • Необхідне резюме для кожної розмови? Додайте поле «підсумок» до кожного виходу.


      • Потрібно резюме для кожної розмови? Додайте поле «підсумок» до кожного виходу.


        Можливо, ви починаєте бачити проблему - ця промова тепер має шість виходів. Тестування буде кошмаром. Ви додаєте підтримку для іншої мови, і раптом ваше додаток починає повертати резюме іспанською мовою замість англійської. Чому? Хто знає, виходи LLM нестійкі, тому зміна промови має непередбачувані результати.


        Вітання - ви створили монстра! З часом він буде рости і викликати ще більше болю.

        З модуляцією

        Modularized System

        Modularized Система

        Обоє Prompt Chain і повністю відокремлений промпт класифікації використовується. Оригінальний великий промпт модулізований настільки, наскільки практичний.

        Промп ChainПідприємництво

        Один промпт виявляє мову, один забезпечує переклад, один визначає, якщо користувач засмучений і ескалація до людей, промпт відповіді генерує відповідь, guardrail перевіряє відповідність відповіді.


        Зміна все ще може порушити певний попит, але ризики значно зменшуються, тому що:

        • Зміна на одну частину не ризикує порушити кожну частину логіки застосування.
        • Тестування набагато простіше, а шанси на ранній провал високі.
        • Кожен запит відносно простий, тому його простіше зрозуміти, і ви менш схильні завдати шкоди зміною.
        • Зміни простіше переглянути.
      • Зміна однієї частини не ризикує порушити кожну частину логіки застосування.
      • Тестування набагато простіше, і шанси на ранній провал високі.
      • Кожен заклик відносно простий, тому його легше зрозуміти, і ви менш схильні завдати шкоди зі зміною.
      • Зміни легко переглядати.
      • Ви отримуєте всі переваги Gen AI, але ризики значно зменшуються.Плюс, ви можете використовувати дешевші моделі для деяких компонентів, щоб заощадити гроші.


        Заключення

        Модуляризація дозволяє ізолювати помилки, покращувати технічне обслуговування і будувати більш надійну систему. Навіть у помірних розмірах додатки будуть мати десятки, якщо не сотні, компонентних проб. Розбивати проб до тих пір, поки кожен з них не виконає одне завдання, і до тих пір, поки переваги подальшої модуляризації не переважуються додатковою операційною складністю. Модуляризація ваших проб є необхідністю, якщо ваші додатки, орієнтовані на штучний інтелект, повинні залишатися надійними, і продовжувати додавати функції в довгостроковій перспективі.


        Якщо вам сподобалася ця серія - підпишіться на більше повідомлень.

    L O A D I N G
    . . . comments & more!

    About Author

    Andrew Prosikhin HackerNoon profile picture
    Andrew Prosikhin@andrewproton
    Generative AI Engineer. Founder and CEO of Blobfish AI.

    ПОВІСИТИ БИРКИ

    ЦЯ СТАТТЯ БУЛА ПРЕДСТАВЛЕНА В...

    Trending Topics

    blockchaincryptocurrencyhackernoon-top-storyprogrammingsoftware-developmenttechnologystartuphackernoon-booksBitcoinbooks