2026 рік Посібник з навчання штучного інтелекту: що вчити, чим користуватися, чого уникати

Оригінальна назва: Що вчити, створювати та пропускати в AI-агентах (2026)
Автор: Rohit
Переклад: Peggy, BlockBeats

Автор оригіналу:律动BlockBeats

Джерело оригіналу:

Перепублікація: 火星财经

Редакторський коментар: Галузь AI-агентів входить у фазу вибуху інструментів і недостатньої узгодженості.

Щотижня з’являються нові рамки, нові моделі, нові benchmark і нові продукти з «10-кратною ефективністю», але справді важливі питання вже не в тому, «як йти в ногу з усіма змінами», а в тому, «які з них дійсно варто вкладати».

Автор вважає, що в умовах постійного переписування технологічного стеку справжнім довгостроковим капіталом є не гонитва за найновішими рамками, а більш глибокі навички: контекстне інженерія, дизайн інструментів, системи оцінки, модель оркестратора та субагента, sandbox і мислення у стилі harness. Ці навички не швидко вийдуть з моди з оновленням моделей, навпаки, вони стануть основою для побудови надійних AI-агентів.

У статті також наголошується, що AI-агенти змінюють уявлення про «статус». Раніше диплом, посада і стаж були пропуском у галузь; але у сфері, де навіть гіганти ще експериментують відкрито, резюме вже не є єдиним доказом. Важливішими стають ваші дії і результати.

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

Нижче — оригінал:

Щодня з’являється новий рамковий інструмент, новий benchmark, новий продукт з «10-кратною ефективністю». Питання вже не в тому, «як йти в ногу», а в тому: що тут справжній сигнал, а що — просто шум, що маскується під терміновість.

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

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

За останні два роки я створював продукти у цій галузі, отримав кілька пропозицій з зарплатою понад 250 тисяч доларів на рік, і зараз відповідаю за технічний напрям у компанії, яка ще не афішує свою діяльність. Якщо мене запитають: «Що зараз найважливіше вивчати?», — я надішлю їм цю відповідь.

Це не карта шляху. Галузь AI-агентів ще не має чіткої кінцевої мети. Величезні лабораторії відкрито експериментують, повертаючи проблему регресії до мільйонів користувачів, пишуть аналізи і онлайн-ремонти. Якщо команда Claude Code випустить версію, що спричинить 47% падіння продуктивності, і користувачі це виявлять, — уявлення про «стабільну карту» — фантазія. Всі ще шукають. Стартапи мають шанс, бо гіганти теж не мають відповіді. Люди, які не пишуть код, співпрацюють з агентами, доставляючи у п’ятницю те, що ще у вівторок здавалося неможливим для докторів машинного навчання.

Найцікавіше в цей момент — те, що він змінює наше уявлення про «статус». Традиційно, шлях до статусу — диплом, початкові посади, старші, провідні, і поступове зростання рівнів. Це було логічно, коли сфера не зазнавала швидких змін. Але зараз, коли земля під ногами рухається так само швидко, різниця між 22-річним, що опублікував демонстрацію агента, і 35-річним досвідченим інженером — вже не лише у стажі. Обидва мають справу з порожнім полотном. Для них справжнім капіталом є бажання швидко доставляти результати і базові навички, що не застаріють за квартал.

Це — основна ідея цієї статті. Далі я пропоную спосіб оцінки: які базові навички варто вкладати увагу, а які релізи можна пропустити. Те, що підходить — беріть, що ні — відпускайте.

Дійсно корисний фільтр

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

За останні 18 місяців п’ять питань працювали ефективно. Перед тим, як додати щось нове у свій стек, пройдіть їх.

Чи залишиться це важливим через два роки? Якщо це просто оболонка для передової моделі, CLI-параметр або версія Devin, відповідь майже завжди — ні. Якщо це базовий примітив — протокол, модель пам’яті, sandbox, — відповідь швидше «так». Оболонки швидко застарівають, базові примітиви — роками.

Чи є у когось, кого ви поважаєте, реальний продукт, побудований на цьому, і чесно описаний у досвіді? Маркетингові статті не рахуємо, цінні — аналітичні. Блог «Ми протестували X у виробництві, і тут виникли проблеми» — цінніший за десять оголошень. Справжні сигнали — у тих, хто витратив на це особистий час і згаяв один уікенд.

Чи означає це, що потрібно відмовитися від існуючих систем трасування, повторних спроб, конфігурацій і авторизації? Якщо так — це рамка, що прагне стати платформою. Такі рамки мають дуже високий ризик провалу — близько 90%. Хороші базові примітиви мають легко інтегруватися у вже існуючі системи, не вимагаючи міграції.

Якщо пропустити це на шість місяців — яка ціна? Для більшості релізів — ніякої. Через шість місяців ви будете знати більше, і нові версії стануть більш зрозумілими. Ця перевірка дозволить вам без тривог пропустити 90% релізів. Але багато хто відмовляється, бо пропуск чогось здається відставанням. Насправді — ні.

Чи можете ви оцінити, наскільки це дійсно покращить вашого агента? Якщо ні — ви просто здогадуєтесь. Команди без систем оцінки працюють на інтуїції і ризикують випустити проблему у продакшн. Команди з оцінкою можуть дозволити собі дати даним відповідь: у цьому конкретному завданні цього тижня краще GPT-5.5 чи Opus 4.7.

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

За цим стоять справжні навички, які важко назвати. Це — здатність «не йти в ногу з модою». Той фреймворк, що став популярним на Hacker News цього тижня, через два тижні матиме свою команду прихильників, які здаватимуться дуже розумними. Але через шість місяців половина з них вже не підтримуватиметься, і ці прихильники перейдуть до наступної новинки. Ті, хто не приєднався, збережуть час і зосередяться на тих речах, що залишилися після «стандартних» трендів. Уміння стримуватися, спостерігати і казати «через шість місяців я все зрозумію» — справжній професійний навик у цій галузі. Всі читають оголошення, але майже ніхто не вміє ігнорувати їх і не реагувати.

Що вчити

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

Context Engineering

За останні два роки найважливішою зміною стало перетворення «Prompt Engineering» у «Context Engineering». Це справжня зміна, а не просто новий термін.

Модель вже не просто отримує розумну команду. Вона потребує, щоб кожен крок був обґрунтований і зібраний у контекст, що працює. Цей контекст включає системні інструкції, схеми інструментів, знайдені документи, попередні виходи, стан scratchpad і стислі історії. Поведінка агента — це результат спільної емердженції всього, що ви помістили у контекстне вікно.

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

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

Якщо прочитати одну статтю — рекомендується Anthropic «Effective Context Engineering for AI Agents». А ще — їхній огляд системи мультиагентних досліджень, де цифри показують, наскільки важливо ізолювати контекст при масштабуванні систем.

Дизайн інструментів

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

П’ять-десять добре названих інструментів — краще за двадцять посередніх. Назви мають бути дієсловами у природній англійській. Опис — чітким, коли і як їх використовувати. Повідомлення про помилки — це фідбек, на який модель може реагувати. «Перевищено ліміт 500 токенів, спробуйте зменшити» — краще за «Error: 400 Bad Request». У дослідженнях команда повідомляє, що переписування повідомлень про помилки зменшило кількість повторних спроб на 40%.

Anthropic «Writing tools for agents» — хороший старт. Після прочитання додайте спостереження за реальним використанням інструментів. Найбільший вплив на надійність агентів має саме інструментарій. Багато хто змінює prompt, але ігнорує найважливіше — інструменти.

Модель оркестратора і субагента

У 2024–2025 роках дискусії навколо мультиагентних систем зійшлися у концепцію, яку зараз активно застосовують. Ідея проста: паралельна робота кількох агентів без спільного стану — шлях до катастрофи, оскільки помилки накопичуються. Один агент у циклі може працювати набагато далі, ніж здається. Єдина робоча модель у продакшені — це оркестратор-агент, що делегує вузькі, лише для читання задач із ізольованими субагентами і потім інтегрує їхні результати.

Приклади — системи Anthropic, Claude Code, Spring AI та інші, що стандартизують цю модель. Субагенти мають невеликі, сфокусовані контексти і не змінюють спільний стан. Записи змін — відповідальність оркестратора.

Cognition «Don’t Build Multi-Agents» і Anthropic «How we built our multi-agent research system» здаються протилежними, але насправді говорять про одне й те саме — просто різними словами. Обидві статті варто прочитати.

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

Evals і золоті датасети

Кожна команда, що створює надійного агента, має системи оцінки. Без evals — важко створити надійний продукт. Це — найефективніший інструмент у цій галузі і найнедооціненіший у моєму досвіді.

Ефективна практика — збирати trace з виробничого середовища, позначати невдачі і додавати їх до регресійного набору. Коли з’являється новий провал — додавайте його. Використовуйте LLM як суддю для суб’єктивних оцінок, а для інших — точне співставлення або автоматичні перевірки. Перед будь-яким оновленням prompt, моделлю або інструментом — запускати тестовий набір. Spotify повідомляє, що їхній рівень суддів перехоплює близько 25% поганих відповідей перед тим, як вони потраплять до користувача. Без цього — кожен четвертий поганий результат доходить до кінця.

Цінність evals — у тому, що вони — юніт-тести для системи, що постійно змінюється. Вони допомагають переконатися, що агент не відхилився від своїх обов’язків. Без evals — система залежить від змінних і може з часом деградувати. Важливо мати їх з перших днів і регулярно оновлювати.

Приклади — Braintrust, Langfuse evals, LangSmith. Вони хороші, але не є головним бар’єром. Головне — мати позначений датасет. Починайте з 50 зразків — і за один день зробіть їх вручну. Немає виправдання — без оцінки не можна покращувати.

Зберігання стану через файлову систему і цикл Think-Act-Observe

Для будь-якого агента, що виконує багатоетапні задачі, важлива архітектура: думати, діяти, спостерігати і повторювати. Файлова система або структуроване сховище — джерело фактів. Кожна дія фіксується і може бути відтворена. Claude Code, Cursor, Devin, Aider, OpenHands, goose — всі йдуть цим шляхом.

Модель сама по собі — безстанна. Запускова платформа — збережена і має стан. Файлова система — базовий інструмент, зрозумілий кожному розробнику. Вона забезпечує checkpoint, відновлюваність, перевірку субагентів і sandbox. Це — дисципліна, що дозволяє контролювати процес.

Глибше — уявлення, що у будь-якому виробничому агенті, за яку платять, harness робить більше, ніж сама модель. Модель визначає наступну дію, harness її перевіряє, виконує у sandbox, фіксує вихід, вирішує, що з ним робити, коли зупинитися, коли зробити checkpoint і коли створити субагента. Заміна моделі на іншу — не руйнує систему, якщо harness зроблений правильно. Заміна на гіршу — призведе до агента, що забуде, що він робить.

Якщо ви створюєте складні системи — основне місце для інвестицій — harness. Модель — лише компонент.

Розуміння MCP

Не просто навчіться викликати MCP server. Вивчіть його модель. Вона створює чіткий розподіл між можливостями агента, інструментами і ресурсами, а також забезпечує масштабовану авторизацію і передачу. Зрозумівши це, ви побачите, що інші «агентські фреймворки» — це дешевий варіант MCP, і зекономите час на їхню оцінку.

Linux Foundation зараз керує MCP. Більшість провайдерів моделей підтримують його. Це — як «USB-C для AI»: вже не жарт, а реальність.

Sandbox — базова примітивна функція

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

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

Що використовувати для побудови

Ось конкретний вибір станом на квітень 2026 року. Він може змінюватися, але не дуже швидко. В цій сфері краще обирати «прості, але надійні» рішення.

Рівень оркестрації

LangGraph — стандарт у виробничому середовищі. Більшість великих компаній, що запускають агентів, використовують його. Його абстракція відповідає реальній структурі системи: типізовані стани, умовні межі, персистентні робочі процеси і контроль людського участі. Недолік — пишеться довго; перевага — коли агент виходить у продакшн, потрібно саме таке управління.

Якщо ви використовуєте TypeScript — Mastra є фактичним вибором. Це найзрозуміліша модель у цій екосистемі.

Якщо ваша команда віддає перевагу Pydantic і цінує типову безпеку — Pydantic AI — цілком логічний вибір. Вийшовши у 2025 році, він має перспективи.

Якщо потрібно працювати з провайдерами — наприклад, computer use, голосові інтерфейси, реальний час — використовуйте Claude Agent SDK або OpenAI Agents SDK у рамках LangGraph. Не намагайтеся зробити їх верховним оркестратором для гетерогенних систем. Вони оптимізовані для своїх сценаріїв.

Протокольний рівень

MCP — це основа.

Інтегруйте свої інструменти у MCP server. Взаємодійте з ним і через нього. Зараз MCP registry вже перетнув критичну точку: у більшості випадків, перед тим, як писати щось самостійно, можна знайти готовий сервер. У 2026 році — вже не потрібно писати власний plumbing.

Рівень пам’яті

Обирайте систему пам’яті залежно від автономності агента, а не популярності.

Mem0 — підходить для персоналізованого чат-інтерфейсу: вподобання користувача, легкий історичний контекст. Zep — для виробничих систем, де стан постійно еволюціонує і потрібно відслідковувати об’єкти. Letta — для агентів, що мають зберігати стабільність протягом кількох днів або тижнів. Більшість команд цим не потребують, але ті, що — дуже.

Помилка — починати з системи пам’яті, не визначивши проблеми. Спершу додайте до контексту те, що може поміститися у вікно, і візьміть в облік векторну базу даних. Лише коли чітко зрозумієте, які провали потрібно подолати — додайте повноцінну систему пам’яті.

Спостереження і evals

Langfuse — open source за замовчуванням. Можна розгортати самостійно, ліцензія MIT, підтримує трасування, версії prompt і базові evals з LLM як суддею. Якщо ви вже користуєтеся LangChain — інтеграція з LangSmith буде ще тіснішою. Braintrust — для дослідницьких eval-робочих процесів, особливо для порівнянь. OpenLLMetry / Traceloop — для багатомовних систем з vendor-neutral OpenTelemetry.

Вам потрібно і трасування, і evals. Трасування відповідає — «що саме зробив агент?», evals — «чи покращився він порівняно з вчорашнім?» Без них — запуск у продакшн ризикований. Перший день — налаштуйте їх. Це — дешевше, ніж потім виправляти.

Розгортання і sandbox

E2B — універсальний sandbox для виконання коду. Browserbase + Stagehand — для автоматизації браузерів. Anthropic Computer Use — для реального десктопу. Modal — для короткострокових задач.

Ніколи не запускайте неперевірений код без sandbox. Агент, що потрапив під промпт-інжекцію і працює у продакшені — це катастрофа.

Моделі

Грати у benchmark — важко і часто безглуздо. Практично, станом на квітень 2026:

• Claude Opus 4.7 і Sonnet 4.6 — для надійного виклику інструментів, багатоступеневої узгодженості і коректного відновлення. Для більшості задач — Sonnet оптимальний баланс ціна/якість.

• GPT-5.4 і GPT-5.5 — для найсильнішого CLI і термінального мислення, якщо ви вже працюєте на OpenAI.

• Gemini 2.5 і 3 — для задач із довгим контекстом і мультимодальністю.

• Якщо важливий бюджет — DeepSeek-V3.2 або Qwen 3.6 — для вузьких задач із чітким визначенням.

Розглядайте модель як змінний компонент. Якщо агент працює лише з однією моделлю — це не конкурентна перевага, а поганий знак. Визначайте, що запускати, за допомогою evals. Перевіряйте щокварталу, а не щотижня.

Що можна пропустити

Вам постійно радитимуть вивчати і використовувати ці речі. Насправді — можна пропустити без значних втрат і зекономити час.

AutoGen і AG2 — не для продакшну. Ці фреймворки вже перейшли у спільне користування, їхній темп оновлень уповільнився, і їхня архітектура не відповідає реальним потребам. Можна використовувати для досліджень, але не для продукту.

CrewAI — не для нових виробничих систем. Виглядає гарно для демонстрацій, але досвідчені інженери вже відмовляються від нього. Можна робити прототипи, але не закріплюватися.

Microsoft Semantic Kernel — якщо ви не глибоко інтегровані у Microsoft-екосистему і ваші клієнти цінують це — тоді так. Інакше — не варто.

DSPy — якщо ви не оптимізуєте prompt-програми на масштабі. Має філософське значення, але вузька цільова аудиторія. Не для універсальних агентських систем.

Використання окремого code-writing агента — архітектурне рішення, що ще не стало стандартом. Це — цікава дослідницька тема, але не для продакшну. Виникає багато питань безпеки і інструментарію.

«Автономний агент» — маркетингова стратегія. AutoGPT і BabyAGI — вже застаріли. Справжній тренд — «агентне інженерство»: з наглядом, межами і оцінкою. Продаж «агентів, що не потребують обслуговування після запуску» — залишився у минулому.

Магазини і маркетплейси агентів — обіцяють з 2023 року, але так і не отримали масового застосування. Бізнеси купують або вузькоспеціалізованих агентів, або самі створюють. Не варто будувати бізнес навколо ідеї app store.

Обережно з горизонтальними платформами типу «build any agent». Наприклад, Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio — можливо, колись стануть у пригоді, але зараз — хаос і повільні релізи. Вибір — або вузький агент, або вертикальний. Salesforce Agentforce і ServiceNow Now Assist — винятки, бо вже інтегровані у робочі процеси.

Не слід сліпо слідувати за рейтингами SWE-bench і OSWorld. У 2025 році дослідники з Berkeley зафіксували, що майже всі публічні benchmark можна «пробити» без реального вирішення задач. Тому не довіряйте беззастережно цифрам.

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

Нові продукти агентів не варто оцінювати за ціною за місце. Ринок вже перейшов до outcome- і usage-based моделей. Оплата за місце — зменшує прибутки і посилає сигнал клієнтам, що ви не впевнені у результаті.

Цього тижня у Hacker News з’явиться новий фреймворк? Почекайте шість місяців. Якщо він залишиться актуальним — зрозумієте самі. Якщо ні — зекономите час і зусилля.

Як діяти далі

Якщо ви не просто хочете «йти в ногу з агентами», а справді плануєте їх використовувати — цей порядок допоможе. Він нудний, але ефективний.

Спершу оберіть конкретний результат. Не починайте з амбіційних проектів «агентної платформи». Оберіть щось, що важливо для вашого бізнесу і що можна виміряти: зменшення кількості запитів у службу підтримки, перша юридична експертиза, відбір inbound-лидів, підготовка звіту за місяць. Успіх агента визначається саме цим результатом — з перших днів.

Це — найважливіший крок, бо він задає рамки для всіх подальших рішень. З конкретним результатом «вибір рамки» перестає бути філософським питанням — ви оберете той, що швидше дасть результат. Вибір моделі — не дискусія, а визначення, яка модель доведе свою ефективність у цьому завданні. Вирішуйте, чи потрібна пам’ять, субагенти, кастомний harness — лише коли стикаєтеся з конкретними провалами.

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

Перед запуском — налаштуйте трасування і evals. Виберіть Langfuse або LangSmith і підключіть їх. За потреби — зробіть невеликий золотий датасет з 50 зразків. Без оцінки — не можна покращувати. Це — дешевше, ніж потім виправляти.

Починайте з одного циклу Think-Act-Observe. Виберіть LangGraph або Pydantic AI. Модель — Claude Sonnet 4.6 або GPT-5. Дайте агенту три-чотири добре продумані інструменти. Використовуйте файлову систему або базу даних для стану. Запустіть на обмеженій аудиторії і спостерігайте за trace.

Розглядайте агент як продукт, а не проект. Він буде провалюватися несподіваними способами — і ці провали стануть вашим планом розвитку. Створюйте регресійний набір на основі реальних trace. Перед кожним оновленням prompt, моделлю або інструментом — тестуйте через evals. Більшість команд недооцінюють цю частину, але саме вона забезпечує надійність.

Коли отримаєте право масштабувати — додавайте складність. Коли контекст стане вузьким — вводьте субагентів. Коли стан стане нездатним — додайте пам’ять. Якщо API відсутній — використовуйте computer use або browser use. Не проектуйте це заздалегідь — нехай провали визначать, що потрібно.

Обирайте просту інфраструктуру. Інструменти — MCP. Sandbox — E2B або Browserbase. Сховище — Postgres або інше, що вже працює у вас. Авторизація і спостереження — за існуючими системами. Найважливіше — дисципліна.

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

Щокварталу оновлюйте модель, а не щотижня. Визначте квартал. Наприкінці кварталу — запустіть eval suite і порівняйте з актуальним передовим. Якщо потрібно — оновлюйте. Це дозволить отримати максимум від прогресу моделей і уникнути хаосу.

Як визначити тренд

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

Сигнали, що це шум: через 30 днів — лише демо-віде