Gdzieś w karcie klienta, w środku zwykłej notatki o zwykłej rozmowie telefonicznej, jest zdanie takie jak to: “Budżet jest teraz napięty, ustaliliśmy, że odezwiemy się do nich za dwa miesiące, żeby wrócić do tematu.”
Napisane raz. Nigdy więcej nieprzeczytane. Nie dlatego, że ktoś zapomniał, że to ważne, ale dlatego, że nic w nim nie wyglądało jak zadanie. To nie był wpis w kalendarzu. To nie było przypomnienie. To było po prostu zdanie, robiące to, co zdania w notatkach robią: siedzące tam, technicznie prawdziwe, funkcjonalnie niewidoczne.
Chcieliśmy wiedzieć, czy system potrafi wychwycić coś takiego samodzielnie, bez konieczności, żeby ktoś pamiętał, że trzeba wrócić i ręcznie zamienić zdanie w zadanie.
Co faktycznie zbudowaliśmy, a czego celowo nie
Instynkt przy takiej funkcji podpowiada, żeby pozwolić AI zająć się wszystkim — przeczytać notatkę, ustalić datę, zdecydować, że termin minął, może nawet napisać przypomnienie. Zamiast tego celowo to rozdzieliliśmy.
Jedynym zadaniem modelu jest rozumienie języka: przeczytać ostatnie notatki klienta i rozpoznać zobowiązanie skierowane w przyszłość, coś w rodzaju “wrócimy do tematu za dwa miesiące” albo “odezwiemy się po ich posiedzeniu zarządu.” Szacuje sugerowane opóźnienie prostymi słowami. To wszystko. Całe rzeczywiste liczenie dat — termin, czy dzisiaj już go minęliśmy — dzieje się później, w zwykłym, deterministycznym kodzie. Model nigdy nie liczy i nigdy nie podejmuje ostatecznej decyzji o tym, co jest przeterminowane. On czyta. Kod decyduje.
Ten podział ma większe znaczenie, niż się wydaje. Rozumienie języka to dokładnie ten rodzaj niejasnego, zależnego od kontekstu zadania, w którym model jest dobry. Liczenie dat to dokładnie ten rodzaj zadania, w którym nie chce się, żeby model improwizował, choćby odrobinę.
Prawdziwy test
Nie ograniczyliśmy się do sprawdzenia, czy endpoint zwraca coś, co wygląda sensownie. Napisaliśmy prawdziwą notatkę na prawdziwej karcie klienta: “…ustaliliśmy, że odezwiemy się do nich za 2 miesiące, żeby wrócić do tematu budżetu.” Wywołaliśmy endpoint. Poprawnie wyodrębnił zobowiązanie, obliczył sugerowane opóźnienie 60 dni i wyliczył termin dokładnie 60 dni od rzeczywistego znacznika czasu notatki, poprawnie oznaczony jako jeszcze nieprzeterminowany.
Drobne, i o to właśnie chodzi. System nie musiał usłyszeć, że jest jakieś zobowiązanie do znalezienia. Przeczytał zdanie, które ktoś napisał dla siebie, nie na formularz, i wyciągnął z niego prawdziwy termin.
Część, którą łatwo przeoczyć
Notatki w Craft11 można tylko dopisywać. Nikt ich nie edytuje, nikt ich nie usuwa, nawet Stark. To ta sama zasada, która utrzymuje uczciwość surowej strony każdej karty: to, co faktycznie napisałeś, zostaje dokładnie takie, jak napisałeś. Kiedy później musieliśmy usunąć testową notatkę, nie było przycisku usuń, po który moglibyśmy sięgnąć, bo z założenia nie powinno go tam być. Potrzebna była bezpośrednia operacja na bazie danych, najpierw potwierdzona, zaraz potem cofnięta.
To dla nas drobna niedogodność podczas testów. To zresztą ten sam powód, dla którego wykrywanie zobowiązań w ogóle zasługuje na zaufanie: czyta prawdziwe, niezmienione, nieoczyszczone ludzkie pismo, a nie jego wysterylizowaną wersję.
Dlaczego w ogóle warto to robić
Nic z tego nie zastępuje menedżera zadań. Zastępuje konkretny, cichy sposób, w jaki sprawy się rozmywają — gdy jedynym zapisem obietnicy jest zdanie, którego nikt nigdy nie przeczyta ponownie. System nie potrzebuje, żebyś pisał inaczej, strukturyzował notatki albo pamiętał, żeby cokolwiek oznaczyć. Potrzebuje tylko, żebyś zapisał, co się naprawdę wydarzyło, tak jak zapisałbyś to dla siebie, a on zajmie się zauważeniem.