# Kaip vertinti AI programavimo testus ir išvengti klaidinančių reitingų

> Ką matuoja HumanEval ir SWE-bench ir kaip vertinant AI programavimo reitingus atsižvelgti į agento aplinką, sąlygas, užduočių naujumą, rezultatų sklaidą ir kainą.

Source: https://ailoot.ai/blog/lt/read-ai-coding-benchmarks/
Canonical: https://ailoot.ai/blog/lt/read-ai-coding-benchmarks/
Language: lt
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-125
Revision: sha256-d96ad20166a4031b519cbbf0525ed40f14569e9e647c50157eb60d5d9a203aca


Trumpai tariant, skaičius „išsprendžia 76 procentus užduočių“ pats savaime beveik nieko nepasako. Svarbu, koks užduočių rinkinys davė šį rezultatą, koks modelis ir agent wrapper buvo vertinami kartu, ar užduotys naujos, ar senos ir kiek tai kainavo. Be šių sąlygų procentas tinka reklaminiam skydeliui, bet ne įrankiui pasirinkti.

Toliau paprastai paaiškinsiu, ką matuoja du pagrindiniai programavimo benchmarkai, kur slypi lentelių kabliukas ir kaip per minutę patikrinti bet kurį reitingą prieš juo pasikliaujant. Toliau aptariami istoriniai etaloninių testų apibrėžimai. Čia neatkuriama aktuali porinė lyderių lentelės būsena; dabartiniam balų ar kainos palyginimui reikia atskiros susietos lentelės, datos ir konfigūracijos.

Daugiau apie darbą su modeliais skaitykite [Ailoot dokumentacijoje](https://ailoot.ai/docs/).

## Ką iš tikrųjų parodo benchmarko procentinė išraiška?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

Benchmarko procentinė išraiška yra dalis užduočių iš konkretaus rinkinio, kurias įrankis atliko pateikdamas veikiantį rezultatą nurodytomis sąlygomis. Užduotys tikrinamos automatiniais testais: kodas testą arba išlaiko, arba ne; vertinimas yra objektyvus, nebūna „daugiau ar mažiau“. Tačiau užduočių rinkinys visada yra siauras ir žinomas iš anksto, o matavimo sąlygos kiekvienam skiriasi. Taigi šis skaičius atsako į klausimą: „Kiek šių užduočių šis įrankis išsprendė tokiu būdu?“ Jis neatsako į klausimą: „Ar įrankis susitvarkys su mano darbu?“

</div>

Benchmarkas veikia paprastai. Yra paruoštas programavimo užduočių sąrašas. Įrankiui pateikiama kiekviena užduotis, jis grąžina kodą, o sistema paleidžia automatinius testus ir patikrina, ar sprendimas veikia. Išlaikytų užduočių dalis yra lentelėje pateiktas procentas.

Privalumas tas, kad vertinimas objektyvus. Testas arba žalias, arba raudonas; niekas nevertina „iš akies“. Šiuo požiūriu benchmarkai yra sąžiningesni už bet kokias apžvalgas ar atsiliepimus.

Trūkumas yra visiškai toks pat. Užduočių rinkinys yra baigtinis ir iš anksto žinomas visiems, įskaitant modelius mokančius žmones. Kiekvienas matavimas turi savas sąlygas. Be to, rinkinio užduotys beveik neabejotinai nepanašios į tai, ką darote jūs. Dėl to kyla visi toliau aptariami pavojai. Procentas apibūdina įrankio veikimą pagal kažkieno kito uždarą užduočių sąrašą ir negali būti tiesiogiai pritaikytas jūsų projektui.

## Ką matuoja HumanEval ir kodėl pagal jį jau nebegalima rinktis?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

HumanEval yra senas 164 mažų Python užduočių rinkinys: modeliams pateikiamas funkcijos aprašas, jie parašo kodą, o automatiniai testai patikrina užduotį. Kai rinkinys buvo išleistas 2021 m., pirmasis Codex vienu bandymu išsprendė 28.8 procento užduočių. Šiandien pajėgūs modeliai išsprendžia beveik visas užduotis, todėl šis benchmarkas nebegali jų atskirti. Be to, tai žaislinės užduotys: viena funkcija pagal aprašą labai skiriasi nuo darbo su dideliu veikiančiu projektu. Aukštas HumanEval įvertis 2026 m. beveik nieko nereiškia.

</div>

HumanEval sukūrė OpenAI ir išleido 2021 m. kartu su Codex modeliu. Rinkinį sudaro 164 mažos Python užduotys: modeliams žodžiais pateikiamas funkcijos aprašas, jie parašo jos turinį, o automatinių testų rinkinys patikrina, ar ji veikia tinkamai.

Tuo metu tai buvo geras būdas atskirti modelius. Savo straipsnyje autoriai pateikia tokį skaičių: pirmasis Codex vienu bandymu išsprendė 28.8 procento užduočių, o įprastas GPT-3 neišsprendė nė vienos.

<figure>
<blockquote>
<p>HumanEval rinkinyje mūsų modelis išsprendžia 28.8 procento problemų, o GPT-3 išsprendžia 0 procentų, o GPT-J – 11.4 procento.</p>
</blockquote>
<figcaption>— OpenAI, straipsnis „Evaluating Large Language Models Trained on Code“</figcaption>
</figure>

Nuo tada modeliai patobulėjo, ir šiandien pajėgūs modeliai išsprendžia beveik visą HumanEval rinkinį. Kai visi surenka beveik 100 procentų, lentelė nebeparodo skirtumų: įrankių skirtumai išnyksta. Tai vadinama benchmarko prisotinimu, o HumanEval tokioje būsenoje yra jau seniai.

Antras trūkumas rimtesnis. Užduotys labai mažos: parašyti vieną funkciją pagal aprašą. Jūsų tikras darbas kitoks – tai didelis projektas su istorija, kur reikia suprasti kieno nors kito kodą, rasti klaidą ir nesugadinti greta esančio kodo. Tarp „parašyti funkciją nuo nulio“ ir „pataisyti klaidą veikiančiame projekte“ plyti praraja. Todėl aukštas HumanEval įvertis šiandien nebėra priežastis rinktis įrankį; jis veikiau rodo, kad „pagrindai įvaldyti“.

## Ką matuoja SWE-bench ir kuo jis artimesnis tikram darbui?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

SWE-bench sudarytas iš tikrų populiarių GitHub projektų defektų: 2,294 užduočių iš 12 Python saugyklų. Įrankiui pateikiamas problemos aprašas, jis pakeičia kodą, o sistema paleidžia testus, kurie prieš pakeitimą nepavyko ir po pataisos turėtų pavykti. Tai daug artimiau tikram darbui nei HumanEval, todėl šis benchmarkas naudojamas rimtiems įrankiams palyginti. Jo sudėtingumą rodo istorija: pirmasis paprastas metodas išsprendė mažiau nei du procentus užduočių.

</div>

SWE-bench iš esmės kitoks, todėl įdomesnis. Jis sudarytas iš tikrų issues ir pull requests populiariuose GitHub projektuose. Pasak autorių, jį sudaro 2,294 užduotys iš 12 didelių Python saugyklų; jis išleistas 2023 m. spalį.

Vertinimo logika objektyvi. Paimamas projekto momentas, kai jame buvo tikras defektas, ir testų rinkinys, kuris tuo metu nepavyko. Įrankiui pateikiamas problemos aprašas, ir jis pakeičia kodą. Tada paleidžiami tie patys testai: jei jie tampa žali, užduotis iš tiesų išspręsta; čia niekas nepasikliauja žodiniais pažadais.

<figure>
<blockquote>
<p>Surinkome 2,294 užduotis peržiūrėję pull requests ir issues iš 12 populiarių Python saugyklų. Kiekviena užduotis grindžiama pull request, susietu su issue, ir keičia bent vieną su testais susijusį failą.</p>
</blockquote>
<figcaption>— SWE-bench, oficiali benchmarko svetainė</figcaption>
</figure>

Pirmieji rezultatai rodo, kiek tai sunkiau už žaislines užduotis. Pirmasis pradinis metodas SWE-bench surinko vos 1.96 procento, o pirmasis agentas – 12.47 procento. Kitaip tariant, net priartėti prie tikro programavimo darbo buvo sunku. Vėliau procentai augo, bet pradžia buvo arti nulio.

Todėl šiandien AI coding agentų reitinguose matomi dideli skaičiai dažniausiai gaunami iš SWE-bench arba jo 500 užduočių poaibio, kurį patikrino žmonės ir kuris vadinamas SWE-bench Verified. Tai pagrįstas benchmarkas. Tačiau ir jis turi sąlygų, be kurių procentas klaidina. Apie tai kalbėsiu toliau.

Net ir sąžiningiausias lentelėje pateiktas benchmarkas dar neparodo rezultato jūsų projekte. Rezultatas priklauso nuo to, kaip dirbate su įrankiu, o pirmoji reitingo eilutė mažai ką nulemia. Švarus kontekstas jūsų asmeninį sėkmės rodiklį pagerina daug labiau nei modelio pasirinkimas iš lentelės.

## Kodėl tas pats modelis gauna skirtingą procentinį įvertį?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

Nes rezultatą lemia ne vien modelis. Kiekviename matavime dalyvauja bent trys dalykai: pats modelis, jį apgaubiantis agento apvalkalas ir įjungtas samprotavimo lygis. Pakeitus samprotavimo nustatymą, tam pačiam modeliui ir agento apvalkalui gali atsirasti skirtingos eilutės. Be apvalkalo pavadinimo, versijos, nustatymų ir datuoto šaltinio jos negali pagrįsti skaitinio palyginimo. Todėl reikia lyginti visas kombinacijas; vien modelio prekės ženklas daug ko nenulemia.

</div>

Čia slypi dažniausia benchmarkų skaitymo klaida. Žmonės lentelę skaito kaip modelių reitingą: šis modelis dviem procentais protingesnis už aną. Tačiau procentą veikia trys dalykai, o modelis tėra vienas iš jų.

Pirma, pats modelis. Antra, jį apgaubiantis agent wrapper: programa, leidžianti modeliui naršyti failus, vykdyti komandas, skaityti klaidas ir perrašyti kodą. Tas pats modelis išmaniajame ir paprastame wrapper duos skirtingus rezultatus, nes wrapper nulemia, kaip modelis dirba su projektu. Trečia, samprotavimo lygis – tai yra, kaip giliai modelis apgalvoja kiekvieną žingsnį. Kuo ilgiau jis galvoja, tuo didesnis paprastai būna procentas, bet ir kaina.

Atkuriamas palyginimas turi išlaikyti visą sąranką. Tai naudokite kaip ataskaitos šabloną, o ne išmatuotą lyderių lentelę:

| Laukas | Bandymas A | Bandymas B |
|----|----|----|
| Modelis ir tiksli versija | Užrašykite išbandytą versiją | Ta pati versija kontroliuojamam palyginimui |
| Agento vykdymo apvalkalas ir versija | Užrašykite saugyklą ir įrašą | Tas pats apvalkalas ir įrašas |
| Užduočių rinkinys ir vertinimas | Užrašykite pogrupį ir vertinimo versiją | Tas pats užduočių rinkinys ir vertinimas |
| Samprotavimo nustatymas | Užrašykite nustatymą A | Užrašykite nustatymą B |
| Rezultatas ir įrodymai | Išspręstų užduočių skaičius, vardiklis, žurnalai, data | Išspręstų užduočių skaičius, vardiklis, žurnalai, data |

Taip matyti, kas pasikeitė ir ar palyginimas iš tikrųjų izoliuoja samprotavimo nustatymą. Ankstesnis skaitinis pavyzdys be nuorodos nelaikomas išmatuotu rezultatu.

Taisyklė tokia: gerame reitinge visada nurodoma, kuris modelis, wrapper ir samprotavimo lygis naudoti. Jei lentelėje tėra modelio pavadinimas ir procentas, o wrapper nenurodytas, ja sunku pasitikėti: nežinote, kas iš tikrųjų buvo matuota. Daugiau apie tai, iš ko susideda „modelis ir wrapper“, paaiškinta straipsnyje apie [AI coding agentų reitingą](https://ailoot.ai/blog/lt/ai-coding-agent-rankings/).

Tai taip pat paaiškina, kodėl įrankis, turintis aukščiausią įvertį, kartais sunkiai susitvarko su jūsų užduotimis. Benchmarkas matuoja modelį kieno nors kito patobulintame wrapper, pagal kieno nors kito užduotis. Jūsų wrapper, projektas ir modeliui pateikiamas kontekstas kitokie. Jūsų projekte rezultatą lemia kontekstas; lentelės eilutė yra antraeilė.

## Kodėl užduotys „pasensta“ ir kas yra mokymo duomenų nutekėjimas?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

Modeliai mokomi naudojant milžiniškus kiekius tekstų ir kodo iš interneto, o populiarūs benchmarkai yra viešai prieinami. Jei užduotys ir jų sprendimai pateko į mokymo duomenis, modelis galėjo juos įsiminti ir vertinimo metu tiesiog atkartoti tai, ką įsiminė, užuot sprendęs užduotis. Tai vadinama užduočių nutekėjimu į mokymo duomenis. Kuo rinkinys senesnis ir geriau žinomas, tuo rizika didesnė: senas benchmarkas greičiau parodys modelio atmintį, o ne jo gebėjimą samprotauti. Nauji ir uždari užduočių rinkiniai patikimesni už senus ir viešus.

</div>

Štai kabliukas, kurio pačiame skaičiuje nematyti, bet jis labiau už viską sumenkina jo reikšmę. Modeliai mokomi naudojant didžiulius kiekius iš interneto surinktų tekstų ir kodo. Beveik visi coding benchmarkai viešai prieinami: užduotys, testai ir etaloniniai sprendimai.

Mechanizmas paprastas. Jei užduotis ir teisingas jos sprendimas pateko į mokymo duomenis, modelis galėjo juos įsiminti. Vertinimo metu jis ne tiek sprendžia užduotį, kiek atkuria iš atminties pažįstamą atsakymą. Tai atrodo kaip sprendimas, bet tėra atmintis. Tai vadinama mokymo duomenų nutekėjimu arba duomenų užteršimu.

Kuo užduočių rinkinys senesnis ir populiaresnis, tuo rizika didesnė. HumanEval internete prieinamas nuo 2021 m.; jis daugybę kartų buvo perrašytas, analizuotas ir įtrauktas į nesuskaičiuojamus duomenų rinkinius. Būtų keista tikėtis, kad šiuolaikinis modelis jo „nematė“. Todėl užduočių naujumas yra atskiras benchmarko kokybės rodiklis. Geras rinkinys arba reguliariai atnaujinamas, arba dalis jo užduočių laikomos uždaros, kad jų nebūtų galima iš anksto išmokti.

Ką daryti skaitant reitingą? Patikrinkite užduočių datą ir ar rinkinys atnaujinamas. Jei benchmarkas sudarytas iš pastarųjų mėnesių naujų defektų, juo verta labiau pasitikėti. Jei rinkinys penkerių metų senumo, aukštas įvertis daugiau pasako apie gerą modelio atmintį nei apie jo gebėjimą išspręsti naują jūsų užduotį. Šis konkretus poveikis parodytas pavyzdyje straipsnyje apie [naują FrontierCode benchmarką](https://ailoot.ai/blog/lt/frontiercode-benchmark-mergeable-ai-code/), kurio užduotys buvo tyčia naujos.

## Kodėl kelių procentinių punktų skirtumas dažnai nieko nereiškia?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

Benchmarkų rezultatai svyruoja: tas pats įrankis su tomis pačiomis užduotimis skirtingais paleidimais pateikia šiek tiek kitokius rezultatus, nes modelis ne visada atsako vienodai. Dėl to vieno ar dviejų punktų skirtumas tarp gretimų reitingo eilučių dažnai paskęsta triukšme ir nerodo tikro pranašumo. Atskirai patikrinkite ir kainą: panašūs procentai gali kainuoti daug kartų brangiau. Kainas lyginkite tik tada, kai nurodytos abi visos sąrankos, sėkmės rodikliai, apmokestinimo prielaidos ir kainos vardiklis.

</div>

Dar viena priežastis, dėl kurios lentelės viršūnė gali klaidinti: modelis kaskart neatsako vienodai. Į tą pačią užklausą jis gali reaguoti šiek tiek kitaip. Todėl kelis kartus paleidus tą patį įrankį su tuo pačiu užduočių rinkiniu, procentas šiek tiek keisis. Šis kitimas vadinamas rezultatų sklaida.

Praktinė išvada paprasta. Jei dvi reitingo eilutės skiriasi vienu ar dviem procentais, tas skirtumas gali būti tiesiog triukšmas. Kvaila vaikytis įrankio, kuris „dviem procentais geresnis“: per kitą paleidimą jie gali lengvai susikeisti vietomis. Skirtį verta laikyti reikšminga, kai ji aiškiai matoma ir išlieka dideliame užduočių rinkinyje; poros punktų tam nepakanka.

Ir paskutinis dalykas, kuris beveik visada svarbesnis už patį procentą, yra kaina. Panašūs rezultatai gali kainuoti labai skirtingai. Kainai palyginti reikia abiejų modelio ir vykdymo apvalkalo konfigūracijų bei visų vertinamam užduočių rinkiniui patirtų išlaidų, įskaitant nesėkmingus bandymus. Padalykite iš bandytų užduočių, jei norite kainos vienam bandymui, arba iš išspręstų užduočių, jei norite kainos vienai išspręstai užduočiai, ir aiškiai nurodykite pasirinktą matą. Šis straipsnis nepateikia šaltiniu pagrįsto porinio kainos matavimo. Todėl reitingo eilutę visada skaitykite kartu su kaina, nes vien procentas mažai ką reiškia. Straipsnyje apie [vienos išspręstos užduoties kainą](https://ailoot.ai/blog/lt/ai-agent-cost-per-solved-task/) paaiškinta, kaip sąžiningai lyginti įrankių kainą.

## Kaip per minutę perskaityti bet kurią benchmarko lentelę?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

Prieš pasitikėdami reitingu, užduokite jam septynis klausimus: Koks užduočių rinkinys? Ar užduotys naujos, ar senos? Koks modelis? Koks agent wrapper? Koks samprotavimo lygis? Kokia vienos užduoties kaina? Kokia rezultatų sklaida? Jei lentelė neatsako bent į pusę šių klausimų, ja negalima pasitikėti: greičiausiai tai reklama. Atskirai patikrinkite, ar rinkinio užduotys panašios į jūsų tikrą darbą, nes net sąžiningas procentas, gautas sprendžiant kieno nors kito užduotis, jūsų projektui nepritaikomas.

</div>

Apibendrinkime viską trumpu kontroliniu sąrašu. Atidarykite bet kurią reitingo lentelę ir iš eilės pereikite šiuos septynis punktus.

1. **Koks užduočių rinkinys?** Šiandien HumanEval silpnas, o SWE-bench artimesnis tikram darbui. Jei rinkinio pavadinimas apskritai nenurodytas, toliau skaityti neverta.
2. **Ar užduotys naujos, ar senos?** Naujas arba iš dalies uždaras rinkinys patikimesnis už seną viešą rinkinį, kurį modelis galėjo išmokti.
3. **Koks modelis buvo vertinamas?** Tikslus pavadinimas ir versija, o ne miglotas „AI“ ar modelių šeimos pavadinimas.
4. **Koks agent wrapper?** Procentas priklauso kombinacijai „modelis ir wrapper“. Jei wrapper nenurodytas, nežinote, kas buvo matuota.
5. **Koks samprotavimo lygis?** Tas pats modelis skirtingais lygiais pateikia skirtingus procentus ir kainuoja skirtingai.
6. **Kiek kainuoja užduotis?** Panašių rezultatų kainos gali skirtis kelis kartus. Procentą vertinkite kartu su kaina.
7. **Kokia rezultatų sklaida?** Vieno ar dviejų punktų skirtumas tarp eilučių dažnai tėra triukšmas.

Yra ir aštuntas klausimas – apie jus: **Ar rinkinio užduotys panašios į jūsų darbą?** Python užduočių benchmarkas mažai ką pasako žmogui, kuris kuria svetainę ar botą naudodamas kitokius įrankius. Net sąžiningas rezultatas sprendžiant kieno nors kito užduotis negarantuoja rezultato jūsų projekte. Yra tik vienas patikimas būdas tai patikrinti: pateikite įrankiui kelias jums būdingas užduotis ir patys įvertinkite rezultatą. Straipsnyje apie tai, [kaip patikrinti AI sugeneruotą kodą](https://ailoot.ai/blog/lt/check-ai-generated-code/), paaiškinta, kaip nustatyti, ar kodas veikia, jei patys neprogramuojate.

## Į ką galiausiai reikėtų žiūrėti?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Pagrindinė išvada

Žiūrėkite į sąlygas po pirmąja eilute, o ne tik į pačią pirmąją eilutę: užduočių rinkinį ir jo naujumą, kombinaciją „modelis ir wrapper“, samprotavimo lygį, vienos užduoties kainą ir rezultatų sklaidos dydį. Vien plikas skaičius be šių sąlygų nieko neįrodo. Atminkite, kad net sąžiningas rezultatas sprendžiant kieno nors kito užduotis jūsų projektui nepritaikomas: paskutinį žodį visada taria bandymai su jūsų tikromis užduotimis, o rezultatas labiau priklauso nuo to, kaip dirbate su įrankiu, nei nuo jo vietos reitinge.

</div>

Pagrindinė viso straipsnio mintis trumpa: vieta reitinge yra priežastis atidžiau pažvelgti į įrankį, bet toliau teks pasidomėti patiems. Didelis skaičius tik rodo, kad įrankis neblogai susidorojo su konkrečiu uždaru užduočių sąrašu nurodytomis sąlygomis. Procentas neparodo, ar tos sąlygos atitinka jūsiškes.

Todėl skaitykite, kas parašyta po reitingo eilute: kokios užduotys, kiek jos naujos, kokia modelio ir wrapper kombinacija, koks samprotavimo lygis, kiek tai kainuoja ir ar skirtumas nepaskęsta triukšme. Lentelė, neatsakanti į šiuos klausimus, tinka reklaminiam skydeliui. Apžvalgoje [kokį įrankį naudoti programavimui 2026 m.](https://ailoot.ai/blog/lt/ai-coding-tools/) paaiškinama, kokį įrankį apskritai pasirinkti savo užduotims.

O štai kas svarbiau už bet kurį benchmarką. Net geriausias reitingo įrankis sunkiai susitvarko su netvarkingu kontekstu, bet gerai veikia su švariu kontekstu. Jūsų asmeninė sėkmė priklauso nuo to, ką pateikiate modeliui ir kaip suformuluojate užduotį; lentelės eilutė yra antraeilė. Reitingas padeda atmesti akivaizdžiai silpnus variantus, bet rezultatą kuriate jūs.

<div class="section" role="doc-bibliography" aria-label="Sources">

### Šaltiniai

- [HumanEval - duomenų rinkinys openai/openai_humaneval (huggingface.co)](https://huggingface.co/datasets/openai/openai_humaneval) - 164 Python užduočių rinkinys, tikrinamas automatiniais testais

</div>

Vieta reitinge padeda atmesti silpnus variantus, tačiau jūsų projekto rezultatai priklauso nuo metodo.



Tolesniam darbui – [Ailoot](https://ailoot.ai/).

## Klausimai ir atsakymai

### Ką užfiksuoti prieš lyginant dvi etaloninio testo eilutes?

Užrašykite tikslų modelį, agento vykdymo apvalkalą ir versiją, samprotavimo nustatymus, užduočių pogrupį, vertinimo metodą, datą ir tiesioginį rezultato šaltinį. Be šių laukų balų skirtumo negalima priskirti vienam pakeistam nustatymui.

### Ar kaina vienai bandytai užduočiai yra tokia pati kaip vienai išspręstai?

Ne. Pirmam matui bendras vertinimo išlaidas dalykite iš visų bandytų užduočių, antram — iš išspręstų. Įtraukite nesėkmingų bandymų išlaidas ir prieš lygindami kainas nurodykite vardiklį.


## Ailoot · Įmonė ir jos projektų portfelis

Ailoot remiasi sukaupta veiklos patirtimi, plačia klientų baze, stabiliomis paslaugomis ir nuolatine KPI kontrole.

Įmonė ir jos projektų portfelis: milijonai klientų; mėnesio pardavimai siekia milijardus.

Ailoot šią veiklos patirtį pritaiko teikdama API prieigą prie DI funkcijų klientų produktuose, agentuose, programose ir automatizavimo sprendimuose.
