Filar

Pytanie, które zawodziło za każdym razem, aż przestało

Testujemy ten produkt ostrzej, niż większość ludzi zadałaby sobie trud, testując narzędzie, którego nie sprzedaje. Nie dlatego, że lubimy znajdować własne błędy, ale dlatego, że twierdzenie “AI naprawdę zna twój biznes” jest nic niewarte, jeśli nikt nie sprawdził, czy to prawda pod realną presją.

Jedno pytanie uparcie zawodziło. Nie prawie trafnie, nie mgliście, tylko suche “Nie mam tego.”

Pytanie, i ile razy zawiodło

“Zaproponuj hybrydowy pakiet usług, oparty na tym, co faktycznie zadziałało.”

Zadaliśmy pewną wersję tego pytania w trzech osobnych rundach symulacji AlphaForge, pełnym teście dla branży kancelarii prawnych oraz teście dla branży usług ogrodniczych. Za każdym razem, przy starej metodzie wyszukiwania: jakaś wersja “Nie mam wpisów w Vaulcie ani zapisów pokazujących, które kombinacje zadziałały.”

Frustrujące nie było to, że pytanie zawodziło. Frustrujące było to, że informacja naprawdę nie brakowała. Vault miał ogólny wpis o cenach. Miał konkretny wpis o wyniku. Po prostu nigdy ich nie połączył, bo metoda wyszukiwania w tle wykonywała dopasowywanie słów kluczowych na żywo przy każdej wiadomości, do czterdziestu osobnych przeszukiwań bazy danych na pytanie, a dopasowywanie słów kluczowych nie wie, że “palety z darnią” i “pokrycie paletami” mówią o tym samym.

Co naprawdę zmieniliśmy

Nie to, co Vault przechowuje. Sposób, w jaki jest przeszukiwany.

Każdy wpis w Vaulcie jest teraz przekształcany w embedding, liczbową reprezentację jego rzeczywistego znaczenia, w chwili jego zapisania, a nie w chwili, gdy ktoś zadaje o nim pytanie. Wyszukiwanie stało się pojedynczym zapytaniem o najbliższego sąsiada na tej reprezentacji, zamiast przeszukiwania całego Vaulta od zera przy każdej wiadomości. To ta sama bazowa baza danych, Postgres, na tej samej instancji, którą już mieliśmy, z rozszerzeniem zbudowanym dokładnie do tego celu. Żadnej nowej kategorii infrastruktury. Tylko inny sposób znajdowania tego, co już tam było.

Dotarcie do tego wymagało realnej, mało efektownej pracy inżynierskiej, przy której większość takich wpisów się nie zatrzymuje: sprawdzenia, którzy dostawcy AI w ogóle oferują endpoint do embeddingów (nie wszyscy to robią), projektu uwzględniającego wielu klientów (tenant-aware), tak by używany był własny skonfigurowany dostawca każdej firmy zamiast jednego klucza dla całej platformy, oraz naprawdę wymagającego błędu, w którym embeddingi jednego dostawcy potrzebowały jawnej normalizacji, zanim porównania odległości w ogóle miały sens matematycznie. Przetestowaliśmy też pięciu kandydatów na model na prawdziwym pytaniu, zanim wybraliśmy jeden, i odkryliśmy coś wartego uwagi samo w sobie: najszybsza opcja pokonała najwolniejszą od dziesięciu do piętnastu razy, przy zerowej różnicy w jakości odpowiedzi na dokładnie to liczbowe pytanie, na którym ją testowaliśmy.

Ponowny test

Ten sam klient. To samo pytanie. Najpierw stara metoda, potem nowa, jedna po drugiej.

Stara odpowiedź: “Nie mam wpisów w Vaulcie ani zapisów pokazujących, które kombinacje zadziałały.”

Nowa odpowiedź, potwierdzona przez logi jako faktycznie wykorzystująca nową ścieżkę wyszukiwania, nie przypadek: realna, konkretna propozycja, nazwane usługi, prawdziwy klient wskazany z imienia, wyliczona wartość całkowita, rozumowanie powiązane z tym, jak faktycznie przebiega praca tej firmy. Nie nieco lepsza wersja starej nie-odpowiedzi. Zupełnie inny wynik, na pytaniu, które do tej pory identycznie zawodziło za każdym razem, przez cały program testowy.

Czego nie będziemy udawać

Uczciwy koszt pojawił się od razu, więc go raportujemy, zamiast go wygładzać. Uzupełnienie embeddingów wstecz dla już dużego Vaulta, ponad tysiąc wpisów, zajęło niemal pięć minut, niewygodnie blisko twardego limitu czasu żądania. Przy naprawdę dojrzałym Vaulcie, liczącym kilka tysięcy wpisów, to samo jednorazowe uzupełnienie prawdopodobnie zawiodłoby w połowie. Wiemy to teraz, bo to zmierzyliśmy, a nie zgadujemy. To realny, oznaczony punkt do dalszej pracy, a nie coś, co wypuściliśmy, cicho licząc, że nikt na to nie trafi.

Liczba stojąca za tym wszystkim

To jedno porównanie przed i po to tylko jeden test w ramach dużo większego programu: około dwadzieścia pięć symulowanych lat działalności biznesowej w kilku branżach, ponad dziewięć tysięcy prawdziwych wpisów w Vaulcie powstałych po drodze, jedenaście prawdziwych błędów znalezionych i naprawionych, w tym ta luka w wyszukiwaniu. Całkowity rzeczywisty wydatek na API dla całego, wielomiesięcznego programu: 9,57 USD.

Wolimy pokazać wam pytanie, które zawiodło pięć razy z rzędu, i dokładnie to, co było potrzebne, żeby je naprawić, niż zacząć od chwytliwej liczby i mieć nadzieję, że nikt nie zapyta, co naprawdę za nią stoi.

Pytania, które ludzie naprawdę zadają

Czy AI naprawdę brakowało tej informacji, czy to był problem z wyszukiwaniem?

Problem z wyszukiwaniem, potwierdzony bezpośrednio. Każdy fakt potrzebny do odpowiedzi na pytanie już znajdował się w Vaulcie. Stara metoda wyszukiwania używała dopasowywania słów kluczowych na żywo, więc pytanie ze słowem ‘palety’ nie zawsze trafiało na wpis zapisany słowem ‘paleta’, a szersze pytanie syntetyzujące nie zawsze łączyło dwa powiązane, ale inaczej sformułowane wpisy. Wiedza tam była. Wyszukiwanie po prostu jej nie znajdowało.

Co się właściwie zmieniło?

Wpisy w Vaulcie są teraz przekształcane w embedding, czyli liczbową reprezentację ich znaczenia, w chwili ich zapisania. Wyszukiwanie stało się pojedynczym zapytaniem o najbliższego sąsiada na tej reprezentacji, zamiast przeszukiwania słów kluczowych na żywo w całym Vaulcie przy każdej wiadomości. Ta sama wiedza bazowa. Zupełnie inny sposób jej znajdowania.

Skąd wiecie, że poprawa jest realna, a nie jednorazowa?

Powtórzyliśmy identyczne pytanie na tym samym kliencie, najpierw z wyszukiwaniem słów kluczowych, potem z wyszukiwaniem wektorowym, i porównaliśmy wyniki. Sprawdziliśmy też uczciwy koszt: opóźnienie, czas uzupełniania danych wstecz przy dużej skali, oraz realne ryzyko, które znaleźliśmy (jednorazowe uzupełnienie danych wstecz dla dużego Vaulta zbliżające się niebezpiecznie do limitu czasu żądania), zamiast raportować tylko sukces.

Dołącz do Early Crew →← Powrót do wszystkich tekstów

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.