Pilíř

Otázka, která pokaždé selhala, dokud nepřestala

Tento produkt testujeme přísněji, než by se většina lidí vůbec obtěžovala testovat nástroj, který neprodává. Ne proto, že by nás bavilo hledat vlastní chyby, ale proto, že tvrzení “AI opravdu zná váš byznys” nemá žádnou hodnotu, pokud nikdo neověřil, jestli to platí pod skutečným tlakem.

Jedna otázka pořád selhávala. Ne skoro správně, ne mlhavě, ale suché “Tohle nemám.”

Otázka, a kolikrát selhala

“Navrhni hybridní balíček služeb založený na tom, co skutečně fungovalo.”

Nějakou verzi této otázky jsme položili ve třech samostatných simulačních bězích AlphaForge, kompletním testu vertikály advokátních kanceláří a testu vertikály zahradních úprav. Pokaždé, se starou metodou vyhledávání: nějaká verze “Nemám záznamy v Trezoru ani doklady o tom, které kombinace fungovaly.”

Frustrující nebylo to, že to selhalo. Bylo to, že informace opravdu nechyběla. Trezor měl obecný záznam o cenách. Měl konkrétní záznam o výsledku. Prostě je nikdy nespojil, protože metoda vyhledávání v pozadí prováděla u každé jednotlivé zprávy živé porovnávání klíčových slov, až čtyřicet samostatných prohledání databáze na otázku, a porovnávání klíčových slov neví, že “palety s drny” a “pokrytí paletami” mluví o stejné věci.

Co jsme skutečně změnili

Ne to, co Trezor uchovává. Ale způsob, jakým se prohledává.

Každý záznam v Trezoru se nyní převádí na embedding, číselnou reprezentaci svého skutečného významu, v okamžiku, kdy je zapsán, ne v okamžiku, kdy se na něj někdo zeptá. Vyhledávání se stalo jediným dotazem na nejbližšího souseda nad touto reprezentací, místo prohledávání celého Trezoru od nuly u každé zprávy. Je to stejná základní databáze, Postgres, na stejné instanci, kterou jsme už měli, s rozšířením postaveným přesně pro tento účel. Žádná nová kategorie infrastruktury. Jen jiný způsob, jak najít to, co tam už bylo.

Cesta k tomu vyžadovala skutečnou, nijak zvlášť okázalou inženýrskou práci, u které se většina takových článků nezastavuje: ověření, kteří poskytovatelé AI vůbec nabízejí endpoint pro embeddingy (ne všichni ano), návrh zohledňující jednotlivé klienty (tenant-aware), aby se používal vlastní nakonfigurovaný poskytovatel každé firmy místo jednoho klíče pro celou platformu, a opravdu záludná chyba, kdy embeddingy jednoho poskytovatele potřebovaly explicitní normalizaci, než byla porovnání vzdáleností vůbec matematicky platná. Před výběrem jsme také otestovali pět kandidátů na model na reálné otázce a zjistili něco, co samo o sobě stojí za zmínku: nejrychlejší varianta byla desetkrát až patnáctkrát rychlejší než nejpomalejší, při nulovém rozdílu v kvalitě odpovědi na přesně tu číselnou otázku, na které jsme ji testovali.

Opakovaný test

Stejný klient. Stejná otázka. Nejprve stará metoda, pak nová, hned po sobě.

Stará odpověď: “Nemám záznamy v Trezoru ani doklady o tom, které kombinace fungovaly.”

Nová odpověď, potvrzená logy jako skutečně vzniklá novou cestou vyhledávání, ne náhodou: reálný, konkrétní návrh, pojmenované služby, skutečný klient uvedený jménem, vypočtená celková hodnota, zdůvodnění navázané na to, jak práce dané firmy skutečně probíhá. Ne mírně lepší verze staré ne-odpovědi. Zcela odlišný výsledek u otázky, která do té doby v celém testovacím programu pokaždé selhávala naprosto stejně.

Co nebudeme předstírat

Poctivá cena se projevila okamžitě, takže ji uvádíme, ne že bychom ji zahlazovali. Zpětné doplnění embeddingů pro už velký Trezor, přes tisíc záznamů, trvalo skoro pět minut, nepříjemně blízko tvrdému limitu časového limitu požadavku. U opravdu zralého Trezoru, hlubokého několik tisíc záznamů, by stejné jednorázové zpětné doplnění pravděpodobně selhalo v polovině cesty. Teď to víme, protože jsme to změřili, ne proto, že hádáme. Je to skutečný, označený úkol do budoucna, ne něco, co jsme vypustili a tiše doufali, že na to nikdo nenarazí.

Číslo, které za tím vším stojí

Toto jediné srovnání před a po je jeden test v rámci mnohem většího programu: zhruba dvacet pět simulovaných let obchodní činnosti napříč několika obory, přes devět tisíc reálných záznamů v Trezoru vzniklých po cestě, jedenáct skutečných chyb nalezených a opravených, mezi nimi i tato mezera ve vyhledávání. Celkové skutečné výdaje za API za celý několikaměsíční program: 9,57 $.

Raději vám ukážeme otázku, která pětkrát za sebou selhala, a přesně to, co bylo potřeba k jejímu opravení, než abychom začali velkým číslem a doufali, že se nikdo nezeptá, co za ním doopravdy stojí.

Otázky, které lidé skutečně kladou

Chyběla AI opravdu ta informace, nebo šlo o problém s vyhledáváním?

Problém s vyhledáváním, přímo potvrzený. Každý fakt potřebný k zodpovězení otázky už byl v Trezoru. Stará metoda vyhledávání používala živé porovnávání klíčových slov, takže otázka se slovem ‘palety’ spolehlivě nenašla záznam napsaný se slovem ‘paleta’, a širší syntetizující otázka spolehlivě nespojila dva související, ale odlišně formulované záznamy. Znalost tam byla. Vyhledávání ji prostě nenacházelo.

Co se skutečně změnilo?

Záznamy v Trezoru se nyní v okamžiku zápisu převádějí na embedding, tedy číselnou reprezentaci jejich významu. Vyhledávání se stalo jediným dotazem na nejbližšího souseda nad touto reprezentací, místo živého prohledávání klíčových slov v celém Trezoru u každé zprávy. Stejná základní znalost. Zásadně jiný způsob, jak ji najít.

Jak víte, že je zlepšení skutečné, a ne jen jednorázová náhoda?

Stejnou otázku jsme znovu spustili na stejném klientovi, nejprve s vyhledáváním podle klíčových slov, poté s vektorovým vyhledáváním, a výsledky porovnali. Ověřili jsme také poctivou cenu: latenci, čas zpětného doplnění při velkém objemu dat, a skutečné riziko, které jsme našli (jednorázové zpětné doplnění velkého Trezoru se nebezpečně blíží tvrdému limitu časového limitu požadavku), místo abychom hlásili jen úspěch.

Přidat se k Early Crew →← Zpět na všechny texty

Recorded on a live database and a live screen, but run by automated scripts standing in for a human's clicks and typing, not performed live. When Stark answers faster than the script expects, the screen can hold still for a beat before the next step starts. That's left in on purpose. The goal was never a polished demo reel, it was proof the feature actually works. Dejan's own verdict, after watching the raw footage: rough, but the best demo video we've made.