Жизненият цикъл на разработка на AI агенти (или как претеглих 22 ястия в името на науката)
В тази статия бих искал да представя един от многото възможни подходи за разработка на агенти. Не мога да твърдя, че е най-оптималният или че ще проработи точно при вас, но наблюденията ми показват, че е доста ефективен.
Как започна всичко
Разработката на софтуер в днешно време следва т.нар. цикъл на разработка на софтуер (SDLC), състоящ се от няколко фази: планиране, дефиниране на изискванията, дизайн (познатите HLD и LLD), разработка, тестване и поддръжка — която включва обратна връзка, нови функционалности и оперативни дейности като пачване.
Този цикъл се следва от всеки софтуерен продукт, в който съм участвал, без значение от методологията — kanban(waterfall с екстри), waterfall или „agile“, който всъщност е waterfall с daily-та.
Това ме накара да се запитам: как би изглеждал подобен цикъл при разработката на AI агент? За да не започвам от нулата, прочетох книгата AI Engineering на Chip Huyen. Тя разграничава следните фази, които се припокриват изненадващо добре със съществуващия цикъл: зараждане на идеята, методология за оценка, промпт инженерство, дизайн на търсенето и агента, фино напасване, оптимизация на процеса, системен дизайн и обратна връзка.
А какво се крие зад всяка от фазите, ще илюстрирам с нагледен пример.
1. Зараждане на идеята
Искам от снимка на храна да получавам вида ѝ и грамажа — нещо като дневник за консумирана храна, но без ръчното писане.
Имаме идея. Сега е моментът да я подложим на разпит със следния въпрос:
Може ли идеята да се изпълни без LLM? Тоест — можем ли да построим детерминирана система без участието на LLM? LLM (фокусиран върху текст) или, в днешно време, foundation model (FM — мултимодален модел, който приема изображения, звук и видео) работи с т.нар. logprobs (log probabilities). За да превърнем logprob във вероятност, използваме формулата:
probability = e^(logprob)
Заради този вероятностен характер работата с FM често се различава от работата с детерминирани системи. Конкретният проблем обаче е достатъчно интересен за разработка с FM — създаването на специализирана невронна мрежа би отнело значително време и е спорно дали резултатите ѝ ще са по-добри. FM се тренират върху огромни обеми данни (Common Crawl, Colossal Clean Crawled Corpus, LAION за изображения) и използват сложни архитектури като Mixture of Experts: входните данни се разпределят между „експерти“ и вместо да се минава през всички параметри на модела, се активира само частта, отговаряща например за изображения. Миксът от експерти подобрява скоростта, като използваната памет е по-голяма.
2. Оценка
Тук трябва да изберем подходящ модел. Моделите биват три вида - open weight (при тях не знаем с какъв датасет са тренирани, но знаем теглата и архитектурата), open model (тренировъчните данни и теглата на модела са публикувани публично) и затворени модели. Всеки модел си има място в публичните ранглисти и един от вариантите е просто да избереш от там. Това често не е достатъчно, защото част от данните или датасетовете, използвани за оценка, могат — умишлено или по погрешка — да попаднат в данните за трениране на модела. Ако приемем, че моделът е ученик, това означава, че ученикът е влязъл на изпита с отговорите в джоба. Вероятно ще изкара шестица, но дали това говори нещо за вашия проблем?
Затова се избират няколко модела от ранглистата, които после се тестват със снимки от телефона и тегла, валидирани с везна. С други думи — за всеки проблем е добре да се направи частен датасет. (Истината е, че това е трудоемко и много често се пропуска независимо от големината на компанията. Не се залъгвайте че големите ентърпраиз компании тестват, защото имат ресурси)
Първата стъпка е датасет от 22 различни храни, снимани с телефон, и JSON файл с храните и теглата им. Да, това означава да претеглиш ригатоните, преди да ги изядеш. Науката иска жертви. Пример:
{
"IMG_5476.HEIC": {
"items": [
{
"name": "cooked rigatoni pasta",
"grams": 173
},
{
"name": "white cheese",
"grams": 76
}
]
}
}
След като имаме 22 уникални храни, идва ред на тестовете — използвах Strands SDK evaluation в GitHub Actions и анализирах резултатите на моделите за конкретния проблем:
Защо GitHub Actions? Оценката много прилича на пайплайн — добре е да може да се повтаря при смяна на модела и/или при итерация към следващата версия на промпта и системния промпт.
За всички модели използвах LiteLLM като рутер — дава един общ API, върху който можеш да построиш нещо като фабрика за агенти. Разходите се следят лесно, а интеграцията със Strands, Bedrock и AWS е добра.
Няколко думи за пропуснатите: Fable е много добър особено при писане на код, но резултатите му за разпознаване на изображения и тегло не са толкова добри. Muse Spark 1.1 - този може би е най-добрият модел, до който съм се докосвал някога. За да мога да направя апи кал си дигнах инстанция в North Virginia. Ако опитам да направя апи кал от личния си лаптоп към Лама 4/Muse 1.1 моделите съм блокиран по IP. Точността при определяне на теглото или грешката бяха около 17%. Създателят на фейсбук обаче пропуска Европа заради EU AI Act. Аз реших да го пропусна също.
3. Промпт инженерство
Тази стъпка включва оптимизация на промпта. Може да стане автоматично с Prompt Optimization в Amazon Bedrock: пишеш първоначален промпт, а FM в Bedrock го оптимизира. Доста прилича на т.нар. meta prompting, където молиш модела да оптимизира промпта… за самия себе си.
Добра практика е промптът и системният промпт да имат версии и да се пазят някъде — git като минимум. Amazon предлагат и Prompt Management, което позволява да съхраняваш различни версии на промпта и да тестваш новата спрямо старата.
4. Дизайн на агента
Избираме подходящ фреймуърк, подаваме системния промпт и решаваме дали ще имаме един агент, или взаимодействие между няколко. Разликата между агент и обикновено извикване на модела е, че агентът представлява цикъл, който извиква инструменти. В момента, в който инструментите свършат работа и изходът не може да се подобри повече, се връща отговор.
5. Fine-tuning (фино напасване)
Обикновено не се налага, но идеята е да заредим датасет, който помага на модела да се справя по-лесно с нашия конкретен проблем. OpenAI поддържат fine-tuning и model registry в платформата си, което позволява напасване към специфичен проблем. Fine-tuning е една стъпка над промпт инженерството — тук се напасват самите тегла на модела към конкретен датасет, за да се представя по-успешно. (базовите тегла са замразени а се тренира малка част, тренират се под 1% от теглата)
6. Филтриране на данните
Тук е важно да дефинираме и т.нар. guardrail — защитата на крайния потребител от вредни изходи. Много хора си мислят, че това е „защитен промпт“, в който описваш какво моделът не трябва да прави. Само че моделът е вероятностен, което означава, че промптът не е достатъчен. Големите модели обикновено следват заложеното поведение, но при по-малките това е трудно, а понякога и невъзможно. Guardrail е допълнителен софтуерен слой, използващ машинно обучение, който проверява входовете и изходите, преди изобщо да стигнат до модела или до крайния потребител. Освен всичко друго guardrail-ите пазят и портфейла — никой не обича да плаща за промпт, който изобщо не е трябвало да стига до модела. Могат да се дефинират и на ниво организация в AWS.
7. Латентност
Ние, инженерите, имаме навика да избираме най-големите модели заради по-добрите резултати — по-голямото очевидно е по-добро, нали? Цената на този избор е, че скоростта намалява, а латентността за крайния потребител расте. Моделите, които „мислят“ повече, са по-бавни и не винаги дават по-добри резултати, както се вижда и от таблицата по-горе. Тук трябва да се намери балансът между скорост, производителност и цена.
Разходите е важно да се наблюдават и да се алармира при определена граница на токените
8. Обратна връзка
Обратната връзка от клиента често помага за развитието на продукта. В приложението може да се даде избор между два промпта (Human in the loop), а при мобилно приложение — да се пусне в TestFlight и мнението да се събере чрез анкета. Това спомага за цялостното развитие и помага да разбереш дали си в правилната посока, или е нужна стратегическа промяна (pivot), преди да излезеш на пазара. И най-важното — дали отговаряш на очакванията на клиента.
Обобщение
Надявам се разработката на агенти да се разрасне през следващите години и да видим повече автономни системи, които — макар и вероятностни — действат според очакванията ни.
Top comments (3)
Ме заинтересува подходът за разработка на агенти, описан в статията, особено идеята за зараждане на идеята и оценката на модела. Интересно е да видим как се прилагат принципите на SDLC при разработката на AI агенти, като се използват техники като промпт инженерство и фино напасване. Частта за оценка и избора на подходящ модел е много важна, тъй като подбрането на модел може да има значително влияние върху крайния резултат. Как би изгледало разширението на датасета от 22 храни до по-голям обем данни, и как би се увеличила точността на модела?
Примерът може би е повече за оценка и избор на модел. За увеличаване на датасета може да се ползва малка част от публичен датасет като github.com/google-research-dataset... макар и архивиран. Колко би се подобрила точността? Може би е добър пример за нова статия с малко внимание към разходите, тъй като SFT няма да е безплатно и трябва да се провери дали се поддържа gemini flash 3.5. (доколкото четох е възможно) Много бих се радвал на предложения, тъй като темата ми е интересна, а мисля че има още много да уча
Много добре структурирана и напълнена със съдържание статия!