Anthropicin insinööriosasto julkaisi jälleen yhden hitin. Heidän sisäinen pelikirjansa tekoälyagenttien arviointiin. Tässä on kaikkein vastoin intuitiota oleva oppi, jonka siitä opin: Älä testaa agenttisi tekemiä vaiheita. Testaa, mitä se oikeasti tuotti. Tämä on vastoin kaikkia vaistoja. Luulisi, että jokaisen vaiheen tarkistaminen varmistaa laadun. Mutta agentit ovat luovia. He löytävät ratkaisuja, joita et osannut odottaa. Yllättävien reittien rankaiseminen tekee arvioistasi hauraita. Tärkeintä on lopputulos. Testaa se suoraan. Käsikirja erittelee kolme arvostelijatyyppiä: - Koodipohjainen: Nopea ja objektiivinen, mutta hauras ja pätevissä variaatioissa. - Mallipohjainen: LLM-tuomari, jossa on arviointikriteerit. Joustavaa, mutta vaatii kalibrointia. - Ihmiset: Kultainen standardi, mutta kallis. Käytä säästeliäästi. Se kattaa myös arviointistrategiat koodausagenteille, keskusteluagenteille, tutkimusagenteille ja tietokoneen käyttäjille. Tärkeimmät huomiot: - Aloita 20–50 testitapauksella todellisista epäonnistumisista - Jokaisen kokeen tulisi aloittaa puhtaasta ympäristöstä - Suorita useita kokeita, koska mallin tulokset vaihtelevat - Lue pöytäkirjat. Näin havaitset arviointibugit. Jos olet tosissasi luotettavien agenttien lähettämisen suhteen. Suosittelen lämpimästi lukemaan sen. Linkki seuraavassa twiitissä.

Iso hetki agenttien rakentajille! Ohjelmistossa toistuu kaava. Ensinnäkin kaikki keskittyvät "rakentamisen" ongelmaan. Kehykset syntyvät, kypsyvät ja muuttuvat aidosti hyviksi. Sitten yhtäkkiä rajoite kääntyy käyttöön. Näimme tämän neuroverkoissa. PyTorch, TensorFlow ja Caffe olivat kaikki erinomaisia mallien rakentamiseen. Mutta niiden käyttöönotto tarkoitti erilaisten formaattien ja ajonaikaisten käsittelyä. ONNX antoi kehittäjille mahdollisuuden rakentaa haluamallaan kehyksellä, viedä sen standardimuotoon ja ottaa käyttöön missä tahansa. Seuraamme samaa kaavaa Agenttien kanssa juuri nyt. Kehykset kuten LangGraph, CrewAI, Agno ja Strands ovat tarpeeksi kypsiä, jotta agentin rakentaminen ei ole enää vaikein osa. Sen sijaan kyse on siitä, mitä tapahtuu sen jälkeen: käyttöönotto, suoratoisto, muistinhallinta, havaittavuus ja automaattinen skaalaus. Nämä eivät ole agenttiongelmia, vaan infrastruktuuriongelmia. Ja juuri nyt jokainen tekoälytiimi, jonka kanssa olen puhunut, ratkaisee ne alusta alkaen. xpander lähestyy tätä ongelmaa ONNX-mallilla, ja mielestäni se on oikea mentaalinen malli. Ydinidea on yksinkertainen: ota agentti mukaan (joka on rakennettu mihin tahansa kehykseen), ota se käyttöön xpanderin kautta ja hanki kaikki tuotantoinfrastruktuuri. Tähän sisältyy: - Palvelimeton käyttöönotto ~2 minuutissa - SSE-suoratoisto reaaliaikaiseen ajatteluun - Muistin hallinta istunto-/käyttäjätasolla - 2 000+ liitintä (Slack, GitHub ja muita) - Yhtenäinen API minkä tahansa agentin kutsumiseen riippumatta kehyksestä Unified API on luultavasti mielenkiintoisin osa tätä. Käytännössä jokainen agentti, jonka otat käyttöön (riippumatta kehyksestä), saa saman kutsupäätepisteen, samalla payload-rakenteella, suoratoistomuodolla ja tunnistautumismallilla. Tämä tarkoittaa, että frontendisi ei tarvitse tietää, onko agentti rakennettu LangGraphilla, CrewAI:lla vai jollain räätälöidyllä työkalulla. Se vain osuu loppupisteeseen ja saa vastauksen. Tämä on tärkeää, koska monissa organisaatioissa eri tiimit rakentavat agentteja, joilla on erilaiset kehykset heidän mieltymystensä tai käyttötapaustensa mukaan. Ilman yhtenäistä kerrosta he ylläpitävät useita integraatiomalleja ja suoratoistototeutuksia. xpander tarjoaa kuitenkin yhden API-sopimuksen jokaiselle agentille, joten käyttäjäsovelluksen ei tarvitse tietää, mihin kehykseen agentti on rakennettu. Alla oleva video esittelee xpanderin yhtenäisen API:n toiminnassa. Voit laajentaa saman standardoidun API-päätepisteen muodon mihin tahansa agenttiin, riippumatta kehyksestä, ja saada samat suoratoiston, muistin, havaittavuuden ja skaalaushyödyt ilman, että yhtään integraatiokoodiriviä tarvitsee muuttaa. Rakennus pysyy irrotettuna käyttöönotosta, mikä on juuri niin kuin sen kuuluukin olla. Olen jakanut GitHub-repon vastauksissa!

Kaikki nukkuvat tämän AWS:n uuden artikkelin äärellä. Malli, joka oli 100 kertaa pienempi kuin GPT, ja Claude murskasi heidät työkalujen kutsumisessa. AWS:n tutkijat ottivat Facebookin OPT-350M:n, vuoden 2022 mallin, jossa on 500 kertaa vähemmän parametreja kuin GPT:llä, ja hienosäätivät sitä ToolBenchillä yhdelle aikakaudelle. Tulokset ovat hurjia: ↳ Heidän SLM:nsä: 77,55 % läpäisyprosentti ↳ ChatGPT-CoT: 26% ↳ ToolLLaMA: 30% ↳ Claude-CoT: 2,73% Tässä mitä tapahtuu: Suuret mallit kärsivät "parametrien laimenemisesta". Suurin osa niiden kapasiteetista on optimoitu yleisiin kielitehtäviin, ei niihin tarkkoihin Ajatus-Toiminta-Toiminto-Syötekuvioihin, joita työkalukutsut tarvitsevat. Pieni malli, joka on koulutettu erityisesti työkalujen kutsumiseen, keskittyy täysin siihen yhteen asiaan. Ei häiriötekijöitä. Harjoitusjärjestely oli yllättävän yksinkertainen. Hugging Face TRL, 187K esimerkkiä, oppimisnopeus 5e–5 ja aggressiivinen gradientin leikkaaminen vakauden takaamiseksi. Mutta haluan tehdä yhden asian selväksi: Tämä ei tarkoita, että pienet mallit voittaisivat kaikkialla. Kirjoittajat myöntävät, että heidän mallinsa saattaa kamppailla monimutkaisten kontekstuaalisten vivahteiden tai epäselvien pyyntöjen kanssa. Se on asiantuntija, ei yleismies. Silti, jos rakennat agenttisia järjestelmiä ja haluat leikata päättelykustannuksia moninkertaisesti, tähän kannattaa kiinnittää huomiota. Olen jakanut linkin lehteen seuraavassa twiitissä.