Ієрархічна карта концепцій інженерії ШІ та ситуацій, коли вони мають значення
Дізнайтеся, які концепції інженерії ШІ визначають, чи буде система взагалі працювати, які мають значення під час створення продукту для експлуатації, а які можна відкласти.
Список іменників розглядає всі двадцять пунктів як еквівалентні, хоча насправді це не так. Шість з них визначають, чи буде ваша система взагалі функціонувати. Ще сім стають важливими, коли ви починаєте створювати щось для серійного використання. Останні сім — це речі, які ви повинні вміти розпізнавати під час розмов, але можете безпечно відкласти їх глибоке вивчення на рік; на жаль, саме їх люди зазвичай вивчають у свій вільний час.
У наступному опису розглядається те саме, але до кожної концепції додаються три аспекти: що вона насправді дає, у який момент вона починає мати значення та спосіб перевірки, чи ви справді її розумієте, а не просто розпізнаєте термін.
Саме перевірки є тим, на що варто звернути увагу. Більшість людей усвідомлюють, що місяцями лише формально слухали певну тему, лише тоді, коли намагаються пояснити її вголос уперше.
Рівень 1: Шість елементів, які визначають, чи працює ваша система
1. Ембеддинги та векторний пошук
Що це дає: Майже все, що пов’язано зі знаходженням інформації, залежить від цього концепту, а його неправильне застосування призводить до збоїв, які не видають жодних помилок.
Перевірка: Два моделі ембеддингів кожна генерує 1024-вимірні вектори. Поясніть, чому класифікатор, навчений на результатах роботи однієї з моделей, все одно буде створювати некоректні результати при роботі з векторами іншої моделі.
Якщо ви вважаєте, що збіг розмірностей — це ознака сумісності, то це саме те непорозуміння. Модель ембеддингів визначає власну геометрію. Дві різні моделі розмістять однакове речення у абсолютно різних місцях у просторах, які лише випадково мають однакову форму. Ніщо у вашій системі не попередить вас про це.
2. Якість пошуку, яка не є тотожною RAG
Що це дає: Майже весь рівень якості відповідей у системі на основі пошуку — причому майже жодна частина цієї якості не походить від самої мовної моделі.
Перевірка: Вкажіть три моменти, через які процес RAG може зазнати невдачі ще до того, як буде викликана мовна модель.
Це фрагментація документа, створення ембеддингів та їх ранжування. Якщо документ розділити не на правильних межах, ви втратите саме те речення, яке відповідало на запитання. Якщо використати модель ембеддингів, навчену на неправильній тематиці, ваша специфічна термінологія опиниться у неправильному сегменті векторного простору. Якщо пропустити етап переранжування, пошуковий механізм поверне результати, які є тематично близькими, але фактично несуттєвими. Команди, які вважають, щу у них проблема галюцинацій, зазвичай мають проблеми з пошуком, і часто витрачають місяць на налаштування запитів, перш ніж це перевірити.
3. Оцінка
Що це дає вам: можливість визначити, чи справді зміна щось покращила, а саме це відрізняє інженерію від здогадок.
Перевірка: описати золотий набір критеріїв, за якими ви оцінюєте — скільки прикладів, звідки вони походять, за що оцінюються та хто перевіряє ці оцінки.
Якщо ви не можете надати конкретні цифри, то те, що у вас є, — це не оцінка, а лише інтуїція та демонстрація, яка випадково спрацювала у вівторок. Розумна початкова точка — це від двохсот до п’ятисот справжніх пар запит-відповідь, взятих з реального трафіку, оцінених за кількома визначеними критеріями, з подальшою перевіркою частини результатів людиною. Також варто знати, що якщо ви використовуєте модель як суддю, цьому судді також потрібна власна оцінка — це рекурсивна проблема, яка є незручною, але неминучою.
4. Структурований вихід та використання інструментів
Що це дає вам: зв’язок між системою, яка генерує текст, та системою, яка фактично виконує дії.
Перевірка: модель повертає JSON, яке не пройшло перевірку відповідно до вашої схеми. Треба детально описати, що робитиме ваша система далі.
Більшість людей зупиняються на фразі «ми спробуємо ще раз», але саме тут починаються справжні запитання. Скільки спроб, з якою стратегією відстрочки, і чи включає спроба повтору помилку перевірки, щоб у моделі був шанс виправити свою помилку? Що відбувається після остаточної невдачі — чи бачить користувач повідомлення про помилку, чи відповідь низької якості, але придатну для використання? Виклик інструменту по суті є викликом функції через межу, яка може створювати хибні дані, тому всі стандартні практики щодо перевірки ненадійних вхідних даних тут також мають повну силу.
5. Контроль витрат та затримок
Що це дає вам: різницю між функцією, яка дійсно випускається, та демо-версією, яку відхиляють з фінансових причин.
Перевірка: Вкажіть поточну вартість одного запиту, а потім наведіть п’ять способів скоротити її вдвічі, розташувавши їх за ступенем впливу кожного з них.
Варто підготувати п’ять підходів. Надсилайте прості запити до дешевшої, менш потужної моделі замість вашої стандартної. Зберігайте у кеші відповіді на запити, які семантично схожі на ті, що ви вже обробили, а не лише ідентичні. Скорочуйте або стискайте все, що ви додаєте до запиту. Об’єднуйте все, що не потребує миттєвої відповіді, у групи та обробляйте їх офлайн. Також скорочуйте результати, які генерує модель, адже токени, які вона створює, зазвичай коштують більше, ніж токени, які ви надсилаєте. За повідомленнями, цього місяця Stripe заплатила понад 7 мільярдів доларів за OpenRouter — компанію, чий основний продукт по суті автоматизує перші два з цих підходів — що свідчить про те, що галузь більше не вважає контроль витрат дрібною деталлю.
6. Керування контекстом
Що це дає вам: передбачувану поведінку, коли обсяг вхідних даних перевищує межі контекстного вікна, що постійно трапляється у продакшн-середовищі та майже ніколи — у демо-версіях.
Перевірка: коли контекстне вікно заповнюється, що саме видаляється та хто приймає це рішення?
Чітка відповідь передбачає конкретну політику: спочатку видаляти найстаріші записи, спочатку — фрагменти з найнижчою оцінкою, узагальнити середню частину або відмовити у обробці запиту. Тривожною є відповідь про те, що фреймворк сам все вирішує, адже це зазвичай означає, що щось важливе тихо видаляється, і ніхто насправді не перевіряє, що саме.
Рівень 2: сім принципів, які ви опановуєте під час створення реальних продуктів
Вони стають актуальними тоді, коли система запущена та з нею починають взаємодіяти реальні користувачі. Немає нічого поганого у вивченні їх раніше, але досліджувати їх до першого рівня означає розміщувати зусилля не у правильному порядку.
7. Запити як версіоновані артефакти
Навичка створення ефективних запитів отримує набагато більше уваги, ніж заслуговує, тоді як інженерні аспекти, пов’язані з запитами, — значно менше. Насправді вам потрібен реєстр, фіксовані версії, можливість порівняння та здатність до скасування змін, адже запит фактично є кодом, який потрапляє у продакшн, не проходячи через компілятор.
8. Стратегія чанкінгу
Розділення тексту на вікна фіксованого розміру, розділення вздовж семантичних меж та додавання перекриття між частинами — усе це різні компроміси між точністю та повнотою. Правильний вибір залежить від структури основних документів, а не від того, яку настройку раптово рекомендує посібник.
9. Переурочування рейтингів
Зазвичай спочатку отримують широкий та недорогий список кандидатів, а потім проводять більш трудомісткий етап оцінювання цього списку. Пропуск цього другого етапу, ймовірно, є найпоширенішою причиною того, чому процес пошуку дає результати, які здаються майже правильними, але не зовсім.
10. Обмеження та вставка запитів
Це вимагає багатошарових захистів: дешеві фільтри на точці входу, більш дорогі перевірки ближче до самої моделі. Будь-який текст, який надходить від користувача або з документа, отриманого вашою системою, слід розглядати як потенційно ворожий вхідний даний, а ніколи як надійні інструкції.
11. Спостережуваність для недетерміністичних систем
Тут вам потрібні сліди, а не просто журнали. Справжнє питання полягає у тому, які фрагменти були отримані та яка версія запиту була активною, коли три дні тому з’явилася певна погана відповідь, і лише деталі на рівні слідів можуть на це відповісти.
12. Вибір між стимулюванням, отриманням даних та фінтюнінгом
Це рішення має набагато більше значення, ніж оволодіння будь-якою окремою технікою. Отримання інформації забезпечує знання, налаштування форм та формату вихідних даних, а стимулювання охоплює все інше, що можна керувати без цих елементів. Поширеною помилкою є використання налаштувань для вирішення проблеми, яка насправді є проблемою отримання інформації.
13. Цикли агентів та вибір інструментів
Один агент, оснащений добре підібраним набором інструментів та обмеженим циклом виконання, може ефективно вирішувати досить велику кількість проблем, тоді як люди часто вдаються до багатоагентних архітектур.
Рівень 3: Сім аспектів, які варто розпізнати та відкласти
Для цього рівня достатньо добре знати лексикон, щоб розуміти діалоги на цю тему. Глибше вивчення можна відкласти, поки конкретна проблема не змусить це зробити, а для багатьох фахівців такий момент ніколи не настає.
14. Оркестрація багатоагентних систем
Це найбільш перебільшено описаний елемент у списку. Вже існує чимало досліджень, які аналізують причини збоїв цих систем після впровадження, і постійний висновок полягає у тому, що надмірні витрати на координацію та зростання частоти помилок зазвичай призводять до гірших результатів, ніж у окремого агента з чітко визначеними функціями, у більшості сценаріїв використання. Дізнайтеся, що означає цей термін, і вдавайтеся до цього підходу лише як останнього засобу.
15. Квантування та оптимізація обслуговування
Це має велике значення, якщо ви самі зберігаєте ваги моделі, але майже не має значення, якщо ви просто викликаєте API.
16. Внутрішня структура Transformer
Механізми уваги, позиційні кодування та інші елементи архітектури зустрічаються у інтерв’ю набагато частіше, ніж у повсякденній роботі. Варто опанувати їх один раз, але глибоке розуміння дивовижним чином мало впливає на спосіб створення систем.
17. Дистиляція
Це стає корисним тоді, коли у вас вже є працездатна, але дорога система, і вам потрібно скоротити витрати — це проблема, яку потрібно вирішувати, а не та, з якою починаєте.
18. Семантичне кешування
Це потужна техніка з серйозними недоліками: успішний пошук у кеші за майже ідентичним запитом повертає неправильну відповідь, яку подають з абсолютною впевненістю.
19. Графи знань та GraphRAG
Вони пропонують справжні переваги, коли базові дані справді є взаємопов’язаними, проте для їх реалізації потрібна значна додаткова складність.
20. Налаштування переваг та сімейство RLHF
Це переважно стосується команд, які фактично навчають моделі, а не тих, хто створює додатки на основі вже існуючих моделей.
Некомфортна частина
Якщо подивитися на всі три рівні, можна помітити щось неправильне.
Оркестрація багатьох агентів, внутрішня структура трансформерів та формулювання запитів — це теми, які вимагають найбільше зусиль від людей під час навчання, і всі три належать до рівнів 2 або 3. У той же час оцінка, якість пошуку та контроль витрат — це те, що насправді визначає, чи функціонує система ефективно, проте їм приділяється лише незначна увага, головним чином тому, що жодна з них не дозволяє створити переконливу демонстрацію.
Існує чітка причина цього розриву, і варто сказати її прямо, а не як критику. Теми третього рівня легко сприймати. Ви можете прочитати про оркестрацію кількох агентів під час поїздки та відчути, що щось дізналися. Натомість оцінювання змушує вас створювати ідеальний набір даних, сперечатися з колегою про те, що означає „хороше“, і іноді приймати те, що ваша система ніколи не була настільки потужною, як здавалося під час демонстрації. Одна з цих діяльностей є комфортною. Інша — справді корисна.
Як насправді опанувати це, а не просто зібрати інформацію
Пастка будь-якого подібного списку полягає у тому, що його сприймають як навчальну програму, яку потрібно прочитати. Читання дозволяє лише розпізнати матеріал, але це розпізнавання зникає в момент, коли хтось ставить додаткове запитання.
Два звички працюють набагато краще, ніж саме читання.
Спочатку створіть одну невелику систему від початку до кінця, а потім навмисно її зламайте. Направте потік отримання даних на документи, які вас справді цікавлять, та навмисно підруйте кожну з стадій. Погано розділіть текст на частини та спостерігайте, як погіршується якість відповідей. Видаліть механізм переурочування та подивіться, що зміниться. Подайте системі спробу введення команди та побачите, що вона витекне. Вихідні, проведені таким чином, навчать більше, ніж місяць читання, адже у вас залишаться спогади про конкретні збої, а не абстрактні визначення.
По-друге, перевірте цей словниковий запас за допомогою реалістичних запитань. Перевірки, описані в цій статті, базуються на типах запитань, які дійсно зустрічаються на практиці, і робота над справжніми завданнями у стилі проектування систем — це найшвидший спосіб виявити прогалини у вашому розумінні, адже справжні запитання супроводжуються додатковими питаннями, і саме тут поверхневе розпізнавання вже недостатнє.
Де я можу помилятися
Цей рейтинг є суб’єктивним оцінюванням, зумовленим конкретними системами, які тут розглядаються, а не результатом формального опитування, тому чесніше називати його обґрунтованим порядком, а не остаточним.
Є два пункти, щодо яких варто відкрито обговорювати їхнє розташування. Оркестрація багатьох агентів знаходиться у 3-му рівні частково через те, що наявні дані про поведінку цих систем у реальних умовах є негативними, а справді міцна платформа, яка з’явиться найближчим часом, може легко підняти її на вищий рівень. Внутрішня структура Transformer має низький рейтинг тут, оскільки робота з моделями ШІ все більше є сферою інтеграції, а не моделювання, і ті, хто працює безпосередньо з самими моделями, повинні підняти цю тему на кілька позицій вище.
Найбільш сильно варто захищати розташування оцінювання на третьому місці, проте є вагомі підстави поставити його на перше місце. Без нього кожен інший пункт у цьому списку перетворюється на припущення, адже неможливо покращити те, що не можна виміряти, і дуже мало команд, які розробляють на основі моделей сьогодні, можуть точно сказати, чи попередня зміна покращила ситуацію чи погіршила її.
Якби ви хотіли змінити цей рейтинг, найцікавіші суперечки, ймовірно, виникають у межах між рівнем 1 та рівнем 2. Більш корисною є дискусія про те, який елемент ви б підняли вище та що саме принесла ця зміна, а не створення ще одного списку з двадцяти позицій.
Пов’язана література
- Управління LLM як суддею як живою системою виробництва — Дізнайтеся, як чотириетапний цикл життя Netflix — дані з реального світу, навчання з використанням критеріїв оцінки, безпечне впровадження та постійний моніторинг — забезпечує точність судді-LLM у масштабах.