Коли ви тільки починаєте створювати щось за допомогою штучного інтелекту, найгучніші голоси вказують на одне й те саме: на модель. Оберіть правильну, кажуть вони, і все інше стане на свої місця. Після кількох тижнів моїх власних експериментів я можу сказати вам, що це просто неправда. Вибір між доступними великими мовними моделями має значення, але це, можливо, лише двадцять відсотків роботи. Решта — це системна робота. Це інженерія, майстерність і невпинне тестування. Це усвідомлення прийшло до мене рано, і відтоді воно змінило мій підхід до кожного проєкту.
Модель — це лише початок
Легко зрозуміти, чому новачки зациклюються на моделях. Примітки до релізів обіцяють кращі міркування, більші контекстні вікна та чистіші результати. Ці покращення реальні, але вони загального призначення. Сучасна модель не знатиме автоматично політику повернення коштів вашої компанії. Вона не зможе надійно форматувати відповіді для вашого мобільного додатка, якщо ви не скажете їй, як це робити. Вона не може дістати дані про наявність товарів із повітря.
Я засвоїв це на власному гіркому досвіді. Мій перший прототип використовував потужну модель і створював красиві, впевнені абзаци, які час від часу були абсолютно невірними. Текст звучав професійно, тому що модель опанувала тон, але вона не мала доступу до актуальної інформації. Я витрачав дні на порівняння бенчмарків моделей, хоча мав думати про пайплайни даних та ін'єкцію контексту. Модель не була зламана. Неповною була система навколо неї. Ця різниця є вирішальною, коли ви переходите від демо-версій до програмного забезпечення, на яке люди дійсно покладаються.
Промпти — це код, а не просто підказки
Високоякісні промпти лежать в основі будь-якого надійного ШІ-додатка. На початку я ставився до промптів як до пошукових запитів — коротких, невимушених, оптимістичних. Я просив модель «підсумувати це» або «бути корисним» і сподівався на краще. Результати коливалися від корисних до зовсім нерелевантних, і я не розумів чому.
Тепер я ставлюся до промптів як до легковажних програм. Хороший промт визначає роль, уточнює формат виводу, містить приклади, коли це необхідно, і встановлює межі. Якщо мені потрібен JSON, я прошу JSON і показую схему. Якщо мені потрібна стисла відповідь, я чітко обмежую довжину та забороняю вступні фрази. Ітерації мають значення. Я веду журнал промптів та їхніх результатів, змінюючи по одній змінній за раз. Один неоднозначний прикметник у промті може змінити поведінку всього робочого процесу. Така чутливість вимагає суворості, а не вгадування.
Сміття на вході — сміття на виході
Надійне вилучення даних — це те місце, де тихо гинуть багато ШІ-проєктів. Retrieval-Augmented Generation, або RAG, став стандартним патерном для надання моделям доступу до приватних або актуальних даних. Ідея проста: отримати відповідні документи, помістити їх у контекстне вікно моделі та дозволити моделі міркувати на основі фактів. Практика ж набагато складніша.
Я витратив час на налагодження простої бази знань, яка постійно повертала непов'язані результати. Модель була в порядку. Проблема була в рівні вилучення (retrieval layer). Мої чанки були занадто малими та позбавленими контексту. Ембедінги генерувалися без очищення дубльованих заголовків. Пошук за схожістю знаходив технічно близький текст, який відповідав на зовсім інше питання. Виправлення означало переосмислення стратегії чанкування, додавання фільтрів метаданих та впровадження етапу переранжування. Як тільки вилучення стабілізувалося, відповіді моделі миттєво покращилися. Урок був зрозумілим: ви не можете виправити погане вилучення даних за допомогою кращої моделі. Ви повинні правильно побудувати пайплайн.
Ви не можете покращити те, що не вимірюєте
Постійне оцінювання — це звичка, яка відрізняє експерименти від продуктів. Коли я починав, я оцінював за відчуттями. Я прочитав би п'ять відповідей, схвально кивнув і пішов далі. Це працює доти, доки користувач не поставить шосте запитання і не отримає щось дивне.
Тепер я створюю невеликі набори для оцінювання для кожної функції. Я збираю реальні запити користувачів, маркую очікувану поведінку та запускаю автоматизовані перевірки проти них. Я стежу за дрейфом: промт, який працював минулого місяця, може погіршитися після оновлення моделі або після зміни вихідних даних. Я відокремлюю оцінювання стилю від фактичної точності. Виглядати професійно — це добре; бути правильним — обов'язково. Без цього циклу ви випускаєте продукт наосліп, а сподівання — це не стратегія тестування.
Знайте межі машини
Розуміння обмежень моделей вберегло мене від надмірних обіцянок і невиконаних зобов'язань. Ці системи мають реальні обмеження. Контекстні вікна стали більшими, ніж раніше, але вони все ще мають свої межі, а їх переповнення погіршує продуктивність на краях. Моделі галюцинують, особливо в нішевих темах, де навчальних даних мало. Вони мають труднощі з точними арифметичними обчисленнями та певними типами багатоетапної логіки. Вони чутливі до формулювань.
Вартість і швидкість — це також обмеження. Модель, яка генерує ідеальну прозу за десять секунд, може бути непридатною для чат-інтерфейсу в реальному часі. Тепер я заздалегідь зіставляю функції з бюджетами затримки. Якщо завдання потребує відповіді менше ніж за секунду, я можу попередньо обчислювати відповіді, агресивно використовувати кешування або використовувати меншу модель для першого чернетки, а більшу — лише для доопрацювання. Робота в межах обмежень — це стандарт інженерії. ШІ не є винятком.
Створення для реальних людей
Зараз я вивчаю застосунки на базі LLM та програмну інженерію з простою метою: створювати інструменти, якими люди користуються щодня. Це звучить очевидно, але розрив між крутим прототипом і інструментом для щоденного використання величезний. Демонстрація може дозволити собі сорокасекундну паузу та багатослівну відповідь. Людина, яка намагається завершити завдання перед зустріччю, — ні.
Інструментам для щоденного використання потрібна обробка помилок, резервні варіанти (fallbacks) та зрозумілий UI, коли модель не впевнена. Вони мають інтегруватися в існуючі робочі процеси, а не нав'язувати нові. Тепер я думаю про граничні випадки: що станеться, коли модель відмовиться відповідати, коли контекст переповниться або коли API вийде за таймаутом? Випуск ШІ-програмного забезпечення означає відповіді на ці запитання за допомогою коду, а не просто оптимізму.
Давайте ділитися тим, що ми вивчаємо
Я хочу налагодити зв'язок з іншими розробниками, які проходять той самий шлях. Галузь розвивається швидко, а найкращі практики все ще формуються. Ніхто не має відповідей на всі запитання. Незалежно від того, чи боретеся ви з проектуванням промптів, чи налаштовуєте retrieval pipelines, чи намагаєтеся зрозуміти, як оцінювати результати у великих масштабах, проблеми краще вирішувати разом.
Давайте ділитися тим, що ми вивчаємо. Не відшліфованими доповідями на конференціях, а «хаотичною серединою». Зламаними конвеєрами, правками промптів, які нарешті спрацювали, тестами оцінювання, які виявили баг перед запуском. Саме такий детальний, чесний обмін досвідом перетворює індивідуальні експерименти на спільний масив знань.
Головний висновок
Якщо ви тільки починаєте розробку в галузі ШІ, витрачайте менше часу на пошук