Typed feature flageket kínál az AI-alkalmazások éles teszteléséhez a Pydantic

Az AI-alkalmazásoknál több változót kell mérni

A Pydantic augusztus 18-án bemutatott megközelítése szerint egyetlen alapértelmezett felhasználói élmény ritkán felel meg minden helyzetnek. Ugyanaz az ügynök kiszolgálhat egy AI-ban jártas szakembert és egy első alkalommal próbálkozó felhasználót, miközben több nyelvet, eltérő szaktudási szinteket és eszközöket is kezel.

A hagyományos A/B tesztelés alapjai itt is érvényesek: a csapatok alternatívákat határoznak meg, forgalmat rendelnek hozzájuk, majd összehasonlítják az eredményeket. Az AI-rendszereknél azonban a kattintás vagy a konverzió mellett az eredmény minőségét, a feladat teljesítését, a sikeres kimenet költségét, a válaszidőt, az eszközök pontosságát, az újrapróbálkozásokat, a biztonságot és a megbízhatóságot is vizsgálni kell.

Három építőelem: modellek, promptok és eszközök

A Logfire managed variables három alapvető elemet kezel. A modell befolyásolja többek között a képességeket, a sebességet, a költséget, a kontextuskorlátokat és a szolgáltatói viselkedést. Egy karakterlánc típusú változóval például egy bekapcsolt felhasználói csoport új modellhez irányítható az alkalmazás kódjának módosítása nélkül. A forrás példakódjában az alapértelmezett modell az openai:gpt-5.2.

A promptok határozzák meg a feladat kereteit, a szakterületi útmutatást és az alkalmazás kommunikációját. A csapatok összevethetnek egy részletesebb, irányított élményt egy tömörebb változattal. Az eszközök azt szabják meg, hogy a rendszer mit kereshet meg, számíthat ki vagy módosíthat. A Pydantic szerint ehhez tipizált szabályzatot kell használni, nem végrehajtható kódot.

Egy példa három profilt különít el: answer_only, research és diagnostic. Ezekhez előre jóváhagyott eszközök és hívási korlátok tartoznak. Az eszközkód, a hitelesítő adatok, a jogosultságkezelés és a szükséges jóváhagyások továbbra is az alkalmazás kódjában maradnak.

Tipizált változók és célzott forgalomirányítás

A feature flagek itt nem kizárólag logikai kapcsolók. Lehetnek szövegek, számok, logikai értékek, strukturált adatok, Pydantic-modellek vagy futásidejű bemeneteket újrafelhasználható elemekkel kombináló sablonok. A kódban megadott alapérték szerződésként és biztonsági tartalékként működik. A Logfire a távoli értékeket a deklarált típus vagy JSON Schema alapján ellenőrzi, hibás vagy hiányzó érték esetén pedig az ismert, érvényes alapértéket használja.

A változókhoz olyan címkék rendelhetők, mint a production, canary, control és treatment. A forgalom százalékosan osztható el, a stabil targeting_key, például felhasználói vagy bérlői azonosító pedig állandó hozzárendelést biztosíthat. Feltételek alapján a rendszer figyelembe veheti többek között a nyelvet, a csomagot, a régiót, a munkafolyamatot, a szolgáltatás verzióját és a bétaengedélyezést.

Ez lehetővé teszi például, hogy egy irányított francia prompt csak a bevezetési folyamatban részt vevő, bekapcsolt felhasználóknál jelenjen meg, vagy egy kapacitásprobléma idején egy adott csomag olcsóbb modellhez kerüljön.

Visszaállítás újratelepítés nélkül

A változók metaadatai és az előállított sémák a logfire.variables_push() paranccsal tölthetők fel. Ehhez a forrás szerint a project:write_variables hatókörrel rendelkező LOGFIRE_API_KEY szükséges, míg a futó alkalmazás külön, project:read_variables jogosultságot használ.

A változók életciklusa ezután a Logfire-ban kezelhető. A csapatok megváltoztathatatlan verziókat hozhatnak létre, címkéket mozgathatnak, valamint módosíthatják a bevezetési arányokat és a célzási szabályokat. Visszaállításkor egy címkét az utolsó ismert, jól működő verzióra lehet irányítani, ehhez nincs szükség alkalmazás-telepítésre.

Minden feloldás nyomkövetési szakaszt hoz létre, a kiválasztott címke és verzió pedig továbbkerül a kapcsolódó műveletekbe. A Logfire ezeket az adatokat a nyomkövetésekkel és SQL-alapú irányítópultokkal kapcsolja össze. A termékoldali mérés a feladat teljesítését, a megszakítást, az ismételt használatot, az eszkalációt és a visszajelzéseket vizsgálhatja. A rendszeroldali nézet a késleltetést, a tokeneket, a következtetés költségét, az eszközhívásokat, az újrapróbálkozásokat és a hibákat csoportosíthatja azonos címkék, verziók és felhasználói csoportok szerint.