«Мадэль — не самае важнае». Якія ШІ-інструменты (не) прыжыліся ў Flo

ШІ-стэкі інжынераў і не толькі

— Як у Flo выглядае тыповы ШІ-стэк, якім карыстаюцца вашыя супрацоўнікі?

З часам выбар зрабілі самі карыстальнікі, і цяпер асноўны інструмент распрацоўкі ў нас — Claude Code. Codex і Cursor мы адключаем. Плюс у нас заўсёды ёсць папярэдне ўсталяваныя харнесы, і мы падключаем пэўныя наборы канэктараў, якія нам патрэбны.

Для распрацоўкі мы выкарыстоўваем самыя моцныя францір-мадэлі. І не эксперыментуем з лакальнымі. Прычына ў тым, што вынік дае не мадэль сама па сабе, а звязка мадэлі і харнеса, гэта значыць усяго, што вакол яе: інструменты, кантэкст, правілы, skills, хукі, праверкі. Цяпер гэта называюць harness engineering, і формула тут простая: agent = model + harness. Добры разбор на гэтую тэму ёсць у Addy Osmani.

Skills закрываюць тое, дзе харнес і мадэль прамахваюцца. Агульны харнес не ведае нашай кодавай базы, нашых працэсаў і нашых памылак. Таму кожнае месца, дзе агент сістэматычна памыляецца, мы ператвараем у правіла або skill. Цяпер у агульным маркетплейсе кампаніі 109 skills, і ён аўтаматычна ўсталёўваецца на кожны рабочы наўтбук.

Акрамя таго, мы выкарыстоўваем Backstage — гэта такі dev-партал, які па сутнасці выступае для нас агенцкай базай ведаў. Там знаходзяцца ўсе сервісы, якія ёсць у нас на прадакшне, адтуль можна даведацца, як яны звязаныя адно з адным, хто за іх адказвае, якія там схемы API.

Адпаведна, калі агент пачынае працаваць, ён можа зайсці ў Backstage і ўдакладніць там кантэкст — якія архітэктурныя рашэнні ўжо прымаліся па розных сервісах і чаму іншыя рашэнні не былі прынятыя. Плюс у яго ёсць кодавая база, з якой ён працуе лакальна.

— Але гэта ўсё пра распрацоўшчыкаў. А што з ШІ-стэкамі ў іншых спецыялістаў?

— Дызайнеры зрабілі ўласныя Figma-плагіны з AI, у тым ліку AI-праверку макетаў. А AI-QA ў лакалізацыі правярае пераклады ў Figma за 15 хвілін замест 1–2 дзён.

Дарэчы, для перакладу мы выбралі не самую моцную мадэль, а тую, якая лепш за ўсё справляецца з задачай: Mistral.

Эксперыменты і фейлы

— Акрамя Codex і Cursor вы яшчэ спрабавалі нешта, што ў выніку у вас не прыжылося?

— Мы паспрабавалі Code Review ад Anthropic, дзе некалькі агентаў паралельна шукаюць багі і правяраюць знаходкі. Гэта моцная рэч, але для нашага аб’ёму PR яна аказалася занадта дарагой. Аплата ідзе з токенаў, і адно рэв’ю ў сярэднім каштуе $15–30. Калі памножыць на ўсе PR, а пры рэв’ю на кожны push яшчэ і на колькасць пушаў, лавіць багі такім спосабам атрымліваецца занадта дорага. Цяпер базавае AI-рэв’ю на PR у нас робіць GitHub Copilot. Яшчэ да каміта распрацоўшчык сам праганяе лакальны skill для рэв’ю і праверкі бяспекі, а ў CI працуе асобная security-праверка.

Яшчэ мы спрабавалі такую рэч, як памяць кампаніі — давай так назавём гэты кампанент. Агентам для працы над задачай патрэбен кантэкст. Наша першая спроба вырашыць гэтую задачу выглядала так: усё выгрузіць у нейкія MD-файлікі, як у Андрэя Карпатага ў LLM Wiki. Там яно ўсё ляжыць, і мы агенту даем гэты кантэкст.

У выніку ад гэтай штукі мы адмовіліся і перайшлі да сістэматызаванага Backstage і да GitBook. Там мы можам кіраваць іерархіяй, усё разбіта па праектах, па камандах. Агенту там прасцей арыентавацца, і ў яго няма неабходнасці адразу ўсё загружаць у кантэкст.

Ёсць яшчэ гіпотэза, якую мы правяраем проста цяпер, — крос-мадэльнае рэв’ю. Код піша адна мадэль, а правярае другая, з іншага сямейства: у розных мадэляў розныя сляпыя зоны. Тут, як мне здаецца, ёсць патэнцыял у open-weight мадэляў. Рэв’ю — больш вузкая задача, чым напісанне кода, і там танная мадэль можа даваць добрае суадносіны цаны і якасці. Але пакуль гэта ідэі і планы, вынікаў яшчэ няма.

І яшчэ крыху раскажу пра агенцкі цыкл для трыажу багаў. У адной камандзе запусцілі пілот на базе Linear. Агент разбірае трэйсы, заводзіць баг, ацэньвае яго ўплыў і стварае задачу ў Linear. Далей рашэнне прымае engineering manager: ці варты гэты фікс токенаў. Калі так, агент робіць фікс. Чалавек тут стаіць у адной кропцы, дзе трэба меркаванне, — у прыярытызацыі. А ўсё механічнае робіць агент. Асобная тэма — гэта тое, дзе праводзіць такія межы аўтаномнасці і як іх вымяраць. Тут спыняцца на гэтым не буду, але калі цікава — гэтае пытанне мы таксама абмяркоўвалі ў нашым падкасце.

Галоўная выснова з усіх нашых эксперыментаў такая: інструмент і мадэль — не самае важнае, і выбар паміж імі хутка ўстарэе. Дарэчы, мой суведучы па 3 AImigo Саша Паламодаў казаў, што паўраспад інструментаў харнеса цяпер складае ад 3 да 6 месяцаў. Таму важна ўсё тое, што назапашваецца паверх: правілы, skills, праверкі і працэсы. Усё гэта застаецца з вамі нават калі вы мяняеце мадэль або інструмент.

— Пра паскаральны перыяд паўраспаду цікавае назіранне. Падумаў, што яшчэ год таму я спрабаваў трымаць у галаве назвы флагманскіх ШІ-мадэляў, каб заставацца ў кантэксце. А цяпер ужо не раблю гэтага — зразумеў, што прасцей загугліць, каб не памыліцца, чым пастаянна трымаць іх у галаве.

— Усё правільна.

Чаму не лакальныя мадэлі?

— Нейкі час таму размаўляў з адным ШІ-энтузіястам на тэму таго, што адбудзецца, калі доступ да ШІ-агентаў раптам знікне. Скажам, метэарыт кудысь не туды ўрэжацца. Што ён будзе рабіць, апынуўшыся без гэтага інструмента? Ён меркаваў, што адбудзецца прыкладна тое ж самае, што здарылася б дзесь у нулявых, калі б у праграмістаў знік інтэрнэт. І ён спадзяецца, што ў будучыні добрыя мадэлі будуць больш даступнымі для лакальнай працы. У той жа час ты ўжо расказваў, што вы з лакальнымі мадэлямі як з інструментамі распрацоўшчыкаў не эксперыментуеце. Можа, дарма? І трэба неяк падстрахавацца?

— Я б падзяліў гэты сцэнар на дзве часткі. Для распрацоўкі мы выкарыстоўваем Claude Code ад Anthropic. Гэта топавы інструмент, верагоднасць таго, што з ім нешта здарыцца… Для гэтага, мабыць, сапраўды трэба нешта накшталт падзення метэарыта. Дарэчы, у чэрвені 2026 года доступ да Fable і Mythos сапраўды закрывалі амаль на тры тыдні. Але, як ужо казаў вышэй, правілы, skills і праверкі пераносныя. Таму змену інструмента мы таксама перажывём.

Іншая справа — убудоўваць ШІ-функцыі ў саму аплікацыю Flo. Тут добра працуе падыход з лакальнымі мадэлямі.

Адпаведна, тут ужо можна выкарыстоўваць лакальныя fine-tuning мадэлі, якія мы можам інферэнсіць. Яны становяцца нашым інструментам для таго, каб скейліць такую нагрузку.

Так, для распрацоўкі мы пакуль выкарыстоўваем Anthropic, але глядзім і ў бакі. Насамрэч лакальныя мадэлі становяцца даволі нядрэннымі. Я б не сказаў, што мы іх актыўна выкарыстоўваем або што мы робім на іх стаўку. Мы да іх прыглядаемся. Пакуль усё ж прасцей узяць нейкае SaaS-рашэнне ад таго ж Anthropic і выкарыстоўваць яго.

Як ствараць ШІ-фічы для вялікай аўдыторыі

— HealthTech — адна з самых адчувальных сфер ІТ. Пры гэтым у вашым прадукце ёсць AI-функцыя, AskFlo. Наколькі складана сумяшчаць строгія гайдлайны медычнага камплаенсу ды імавернасную прыроду генератыўнага ШІ?

— Складана, але вырашальна, калі ставіцца да гэтага як да інжынернай задачы, а не да пытання веры ў мадэль. У AI-прадукце промпт і агенцкая логіка становяцца бізнес-логікай, і гэтая логіка недэтэрмінаваная. Звычайныя юніт-тэсты яе не пакрываюць. Патрэбныя дзве рэчы: добрыя evals, якія даказваюць, што адказ карысны і бяспечны, і guardrails, якія не прапускаюць таго, што прайсці не павінна.

Менавіта для гэтага мы стварылі каманду AI Platform. Будаваць такую інфраструктуру ў кожнай прадуктавай камандзе нанова дорага, і робіцца гэта па-рознаму. Прынцып у нас просты, як у любой добрай платформавай каманды: We do the hard work so you don’t have to.

— Мабыць, з пункту гледжання гэтай працы вялікая аўдыторыя ў +80 млн — гэта не зусім добра? Калі б у вас было ўсяго 100 карыстальнікаў, хутчэй за ўсё, яны задавалі б нейкія тыповыя пытанні, і падладзіцца пад іх было б проста. Але калі іх 80 млн, нетыповых пытанняў прыходзіць вельмі шмат?

— Для вырашэння гэтай праблемы мы можам сегментаваць карыстальнікаў. Унутры Flo у нас ёсць розныя рэжымы. Чаму карыстальніца выкарыстоўвае нашу аплікацыю? Напрыклад, для таго, каб адсочваць цыкл. Або выкарыстоўвае яго тады, калі хоча зацяжараць. У такіх груп розныя патрэбы, і яны розныя з пункту гледжання бяспекі (даць нейкую параду цяжарнай жанчыне можа быць небяспечней, чым даць параду ў звычайным трэкеры).

Адпаведна, промпты, якія генеруюць інсайты, таксама можна падзяліць па групах карыстальнікаў. Інакш у цябе атрымаецца нейкі гіганцкі ўберпромпт, з якім проста немагчыма будзе працаваць. Таму што адказваць ён будзе вельмі дрэнна. І вось гэтыя промпты аптымізуюцца ўжо пад свае сегменты карыстальнікаў.

Цыкл стварэння ШІ-фічы ў спрошчаным выглядзе выглядае так.

• Рубрыкі. Усё пачынаецца з промпта, але адразу ўзнікае пытанне: як зразумець, што промпт добры? Што ён пакрывае нюансы і абмежаванні, а адказ карысны і пры гэтым бяспечны з медычнага пункту гледжання? Для гэтага трэба рубрыкі — апісанне таго, як выглядае добры адказ. Іх пішуць прадукт і медычныя эксперты.

• Датасеты. Прыклады рэальных сітуацый, якія размячаюць эксперты. На іх промпт калібруецца.

• Judges. Гэта аўтаматычныя праверкі. Яны бываюць дэтэрмінаванымі, а бываюць LLM-as-a-judge, і такіх суддзяў таксама трэба калібраваць па разметцы экспертаў. Інакш незразумела, ці можна давяраць іхнай ацэнцы.

• Сімуляцыі і аптымізацыя. Рэальная размова — гэта не адзін пытанне і адзін адказ, таму мы праганяем сімуляцыі дыялогаў. Калі промпт не праходзіць нейкі крытэрый, яго можна аптымізаваць аўтаматычна. Напрыклад, ёсць падыход GEPA: аптымізатар аналізуе, дзе промпт праваліўся, і перапісвае яго так, каб ён праходзіў праверкі.

• Рэліз і навучанне. Толькі пасля таго, як промпт прайшоў каліброўку афлайн на evals, мы яго выпускаем, прычым паступова. Спачатку на ўнутраных карыстальнікаў, супрацоўнікаў кампаніі, каб атрымаць ранні фідбэк і паглядзець, як людзі ўзаемадзейнічаюць з прадуктам. Потым на невялікі працэнт карыстальнікаў.

Кожны крок гэтага цыкла закрывае канкрэтны рызыку. Без рубрык ніхто не адказвае за тое, што такое добры адказ. Без датасэтаў памылкі знаходзяць позна і ўручную. Без суддзяў змены тыднямі чакаюць доказаў або выходзяць на маленькай ручной выбарцы.

Памер промпта ўплывае на latency і на кошт кожнага запыту. Таму на ўваходзе AI-дадатку часта ставяць маршрутызатар — танную хуткую мадэль, якая вызначае інтэнт, тэму або аўдыторыю. Далей ужо бізнес-логіка выбірае промпт пад канкрэтны сцэнар, і кожны промпт застаецца кампактным і правяраемым.

На фронцір-мадэлях можна хутка атрымаць добры бэйзлайн у якасці, але маштабаваць яго на ўсю аўдыторыю вельмі дорага. Тут мы прыходзім да файнт’юну ўласных мадэляў. Добры бэйзлайн і evals, якія ўжо ёсць дасюль, якраз і дазваляюць праверыць, што ўласная мадэль не горшая.

Падрабязней пра evals я расказваў на Podlodka AI Crew, а ў лістападзе буду гаварыць пра гэта на AI Summit Europe у Вільні.

«Мы нікога не прымушаем». Як стаць AI-native кампаніяй (а не такой, дзе ўсе неяк карыстаюцца AI) — прыклад Flo

Па тэме

«Мы нікога не прымушаем». Як стаць AI-native кампаніяй (а не такой, дзе ўсе неяк карыстаюцца AI) — прыклад Flo

«Трэнд — маленькія каманды і крос-людзі». Як ІІ мяняе інжынерныя ролі і найм у Flo (і наогул)

Па тэме

«Трэнд — маленькія каманды і крос-людзі». Як ШІ мяняе інжынерныя ролі ды найм у Flo (і наогул)