Asystent AI, którego i tak sprawdzasz, niczego Ci nie oszczędza.
Zarządzam trzema skrzynkami mailowymi w ramach trzech tożsamości: jako CTO, w praktyce doradczej i w życiu prywatnym. To około stu maili dziennie. Każde narzędzie AI do obsługi poczty, które testowałem, zawodzi na jeden z dwóch sposobów: koszt rośnie wraz z szumem informacyjnym, a nie z liczbą ważnych wiadomości, albo raz pominie coś istotnego, a wtedy i tak zaczynasz samodzielnie sprawdzać skrzynkę. Ten drugi błąd jest kosztowniejszy – wracasz do punktu wyjścia, ale wciąż za to płacisz. Oto architektura, którą stworzyłem, aby uniknąć obu tych problemów, wraz z realnymi danymi z dziesięciu dni jej działania i omówieniem elementów, które były prawdziwym wyzwaniem.
Dwa scenariusze porażki, bez ogródek
1. Koszt skaluje się z wolumenem, a wolumen to głównie szum
Najprostsze rozwiązanie przekazuje każdy przychodzący e-mail do modelu. Ale skrzynka odbiorcza to nie strumień decyzji – to strumień paragonów, newsletterów, powiadomień z kalendarza i jałowych dyskusji na CC, z kilkoma prawdziwymi prośbami ukrytymi pośród nich. Płacenie modelowi za przeczytanie tego wszystkiego oznacza, że większość rachunku płacisz za informację „nic tu nie ma”. Co gorsza, krzywa kosztów zależy od ilości otrzymywanego szumu, a to jedyna zmienna, której nie kontrolujesz.
2. Jeden fałszywy negatyw i cały system jest bezwartościowy
To błąd, którego ludzie nie doceniają. System selekcji, który pominie ważną wiadomość, nie psuje się stopniowo – on się załamuje. Wracasz do samodzielnego czytania skrzynki, a teraz robisz to i płacąc za asystenta. Poprzeczką nie jest „zwykle działa poprawnie”. Poprzeczką jest „już nie otwieram skrzynki odbiorczej” i nic poniżej tego progu nie przynosi żadnych oszczędności.
Te dwa cele są ze sobą sprzeczne. Tanie rozwiązanie oznacza analizowanie mniejszej ilości danych. Godne zaufania – niepomijanie niczego. Cały problem inżynierski polega na osiągnięciu obu tych celów naraz, a nie rozwiązuje go lepszy prompt.
Struktura rozwiązania
Trzy etapy, z których najciekawszy jest pierwszy – deterministyczna bramka, która nie zużywa żadnych tokenów modelu i odrzuca większość pracy, zanim jakikolwiek model zostanie zaangażowany:
Bramka jest uruchamiana zgodnie z harmonogramem, cztery razy na godzinę dla każdej skrzynki, przez całą dobę. Porównuje nieprzeczytane wiadomości z małym plikiem stanu, zawierającym ID wiadomości, które już przekazała dalej. Jeśli nie ma nowych maili, kończy działanie po cichu i nic więcej się nie dzieje. Zawiera również dwie czarne listy – domen nadawców i fragmentów tematu – dla nadawców, którzy powracają w nieskończoność i nigdy nie wymagają oceny; te maile są oznaczane jako przeczytane i etykietowane bezpośrednio w kodzie.
Rzeczywiste, zmierzone oszczędności
Dziesięć pełnych dni, trzy skrzynki mailowe, każda liczba poniżej pochodzi z logów, a nie z szacunków:
| Etap | Liczba (10 dni) | Koszt |
|---|---|---|
| E-maile przychodzące na trzy skrzynki | 1,034 | — |
| Zaplanowane uruchomienia bramki | 2,880 | ~1s CPU na każde, zero tokenów |
| Uruchomienia, które dotarły do modelu | 567 20% | Koszt uruchomienia modelu |
| Uruchomienia, które cokolwiek znalazły | 202 z 567 | — |
| Powiadomienia faktycznie do mnie wysłane | 255 25% wiadomości przychodzących | — |
Cztery z pięciu zaplanowanych sprawdzeń nigdy nie angażują modelu. I to cała historia, jeśli chodzi o koszty. Wynika ona ze stu linijek zwykłego kodu, a nie z wyboru modelu czy dostrajania promptów. Następnie wkracza drugi filtr: spośród tych uruchomień, które docierają do modelu, około dwie trzecie dochodzi do wniosku, że nie ma nic wartego uwagi, i milczy. Zatem spośród stu maili dziennie, dwadzieścia pięć skutkuje powiadomieniem.
Ten schemat można uogólnić i jest to pierwsza rzecz, na którą zwracam uwagę w dowolnej funkcji AI: umieść deterministyczny filtr przed kosztowną oceną i spraw, by pomyłka w bezpieczną stronę była tania. Bramka, która od czasu do czasu niepotrzebnie wybudza model, kosztuje jedno uruchomienie. Bramka, która odrzuci ważny e-mail, kosztuje utratę wiarygodności systemu. Dlatego jest skonstruowana tak, by przepuszczać z nadmiarem, a właściwa selekcja odbywa się dopiero na poziomie modelu.
Problem wyników fałszywie negatywnych i nieoczywiste rozwiązanie
Osiągnięcie niskich kosztów było proste. Zapewnienie niezawodności wymagało jednak zmiany, której nie przewidziałem.
Pierwsza wersja zadawała jedno pytanie na każdy e-mail: Czy to wymaga odpowiedzi? Jeśli tak, przygotuj wersję roboczą i utwórz zadanie. Jeśli nie, wygeneruj krótkie, jednowierszowe podsumowanie. To działało przez kilka tygodni, aż w końcu system coś pominął, obnażając swoją wadę: pojawiła się nowa polityka rezerwacji podróży — zasada, której miałem odtąd przestrzegać, a która nie wymagała ode mnie żadnej odpowiedzi. System poprawnie uznał, że nie ma na co odpowiadać, podsumował to w powiadomieniu i przeszedł dalej. Powiadomienie w ciągu godziny zniknęło w natłoku rozmów na czacie, a wraz z nim nowa zasada.
Uświadomiłem sobie, że w całym tym systemie przetrwają tylko dwie rzeczy: zadanie i przypięta wiadomość. Wszystko inne jest wiadomością na feedzie, czyli czymś tymczasowym. Dlatego teraz każdy e-mail jest oceniany dwukrotnie, na podstawie dwóch zupełnie różnych pytań:
- Czy wymaga to ode mnie DZIAŁANIA? → zadanie z datą i priorytetem oraz wersja robocza odpowiedzi, jeśli jest potrzebna.
- Czy jest tu coś, co muszę WIEDZIEĆ? → przypięcie i odnotowanie zadania do przeczytania. Odpowiedź nie jest wymagana, ale informacja nie może po prostu zniknąć z oczu: zmiana polityki, fakt dotyczący umowy lub pieniędzy, cokolwiek związanego z moją rolą lub wynagrodzeniem, powiadomienie o bezpieczeństwie, podróż wpływająca na moje plany, decyzja podjęta przez innych, która jest dla mnie wiążąca.
Decyduje o tym jedna zasada: czy ta informacja zmienia coś, co muszę zrobić lub wiedzieć, w sposób, który wpłynąłby na moją decyzję? Jeśli nie, jest to informacja jednorazowa — aktualizacja statusu śledzonych prac, kończące temat „dzięki”, postępy w zadaniu kogoś innego. Kategorie te istnieją po to, by wyłapywać to, czego człowiek żałowałby, że przegapił, a nie po to, by zgarniać wszystko, co pasuje do słowa kluczowego. To rozróżnienie stanowi różnicę między systemem do triażu a drugą skrzynką odbiorczą.
Trzy decyzje projektowe, które wyniknęły z użytkowania, a nie z projektowania
Jeden e-mail, jedna wiadomość — bo pracuję z telefonu
Pierwsza wersja wysyłała jedno zbiorcze podsumowanie po każdym uruchomieniu. Dobrze się to czytało, ale było bezużyteczne. Zajmuję się tymi powiadomieniami w przerwach między spotkaniami, na telefonie: kciuk w górę, by oznaczyć jedno jako zrobione, odpowiedź „wyślij”, by zatwierdzić konkretną wersję roboczą. Zbiorcze podsumowanie nie daje możliwości indywidualnej reakcji, a odpowiedź na nie cytuje całą treść. Teraz każdy e-mail to osobna, samowystarczalna wiadomość — nadawca, jednowierszowe podsumowanie, priorytet i jego uzasadnienie, ID referencyjne oraz informacja o tym, co zostało utworzone. Format dostarczania jest podyktowany tym, jak praca faktycznie jest wykonywana, a tego nie da się określić z góry.
Zasady priorytetyzacji są w pliku, a nie w kodzie
Każde zadanie otrzymuje priorytet P1–P4, ponieważ płaska lista czterdziestu pozycji jest nie do ogarnięcia. Zasady, które je przypisują, znajdują się w prostym pliku markdown dla każdego kontekstu — priorytety zawodowe i osobiste naprawdę się różnią, a osobiste P1 oznacza przelew wychodzący z konta lub podróż w ciągu 48 godzin, a nie „napisał ktoś ważny”.
Ten plik jest wstrzykiwany do promptu w całości przy każdym uruchomieniu. Kusząca alternatywa — powiedzenie modelowi, żeby sam odczytał plik — zawodzi w niewidoczny sposób: pominięcie odczytu generuje zadania bez priorytetu i żaden błąd się nie pojawia. Interpolacja uniemożliwia pominięcie pliku. Korzyść jest taka, że edycja pliku markdown zmienia zachowanie triażu przy następnym uruchomieniu, bez wdrażania i bez zmiany kodu.
Tryb awaryjny głośno o sobie informuje, ale system wciąż działa.
Jeśli brakuje pliku z priorytetami, zadanie nie kończy się błędem, ale też nie jest po cichu kontynuowane. System wysyła ostrzeżenie, że zadania w tym cyklu są priorytetyzowane według prostego mechanizmu zastępczego, a następnie i tak przeprowadza triaż, używając celowo uproszczonych zasad, aby degradacja była widoczna w wynikach. Poczta wciąż musi być przetwarzana. Automatyzacja, która zatrzymuje się z powodu braku pliku konfiguracyjnego, to automatyzacja, którą będziesz debugować w niedzielę.
Jak wygląda przykładowe powiadomienie
Prawdziwe powiadomienie, ze zmienionymi nazwami i odniesieniami:
Kontynuacja porannego wątku dotyczącego nieaktualnych danych użytkowników. Product lead poprosił o spotkanie z właścicielami platformy w celu uzgodnienia konkretnej listy działań; następnie delivery lead potwierdził grupie, że temat ma już wysoki priorytet, został włączony do planu na wrzesień z terminem na 15 września, a inne zadania zostaną przesunięte, by zrobić na niego miejsce. Wyznaczono osobę odpowiedzialną, a spotkanie jest w trakcie organizacji.
Jesteś tylko w kopii, nic nie jest od Ciebie wymagane. Temat ma już akceptację, właściciela i zatwierdzony termin. Obniżyłem priorytet istniejącego zadania z P1 do P3 i przesunąłem je na 28 sierpnia, abyś mógł sprawdzić jego status po spotkaniu roadmapowym, zamiast żeby wisiało jako pilne, chociaż dziś nie masz już nic do zrobienia w tej sprawie.
Dopracowanie tego ostatniego akapitu zajęło najwięcej czasu. Podsumowanie mówi, co się wydarzyło. Ten akapit wyjaśnia, co system zrobił w Twoim imieniu i jaką ocenę zastosował — a to jedyny sposób, byś poczuł się na tyle pewnie, by przestać go sprawdzać.
Koszty i ograniczenia
- To nie jest filtr, który można ustawić i o nim zapomnieć. Listy blokad, nadawcy niewymagający zadań, zasady priorytetyzacji — dostrajałem wszystkie trzy od momentu uruchomienia i spodziewam się, że będę to robił nadal. System eliminuje konieczność czytania, a nie odpowiedzialność.
- Wersje robocze odpowiedzi nigdy nie są wysyłane automatycznie. Każda wiadomość wychodząca czeka na wyraźne zatwierdzenie. To twarda zasada, nie ustawienie, i istnieje, ponieważ jeden błędny, ale pewnie sformułowany e-mail kosztuje więcej, niż cały system jest w stanie zaoszczędzić.
- System działa na moich własnych skrzynkach pocztowych, jako ja. Wersja firmowa — wiele skrzynek pocztowych, współdzielone skrzynki odbiorcze, obowiązki retencji danych innej firmy, ścieżka audytowa tego, co przeczytał zautomatyzowany system — to zupełnie inny projekt, o innym profilu ryzyka. To nie jest kopia tego rozwiązania.
- Przedstawione powyżej dane liczbowe dotyczą poczty jednej osoby z okresu dziesięciu dni. Są autentyczne, ale nie stanowią punktu odniesienia dla czyjegokolwiek wolumenu poczty czy stosunku sygnału do szumu.
Dlaczego w rozmowie z CTO skupiłbym się na podejściu, a nie na narzędziu
W tym projekcie interesujące nie jest to, że model potrafi czytać e-maile. To wszyscy wiedzą. Chodzi o to, że dwie rzeczy decydujące o tym, czy funkcja AI przetrwa zderzenie z produkcją — jej koszt przy rzeczywistym wolumenie oraz to, co się stanie, gdy pierwszy raz popełni błąd — są rozstrzygane przez architekturę wokół modelu, a nie przez sam model. Deterministyczna bramka na wejściu. Druga, inaczej sformułowana ocena, by wyłapać klasę błędów, których pierwsza strukturalnie nie jest w stanie dostrzec. Zasady w konfiguracji, by zmieniać zachowanie bez wdrażania. Tryb awaryjny, który sam o sobie informuje. Wynik, który wyjaśnia, co system zrobił, a nie tylko co przeczytał.
To ta sama lista kontrolna, której używam podczas Audytu Efektywności Inżynierskiej, i ta sama, która decyduje, czy funkcja AI w ramach technicznego due diligence jest realną zdolnością, czy tylko demo z problemem kosztowym, który jeszcze się nie ujawnił. Jeśli Twój zespół ma pilotażowy projekt AI, który działa w wersji demo, ale nikt nie potrafi powiedzieć, ile będzie kosztował przy dziesięciokrotnie większym wolumenie, to właśnie o tym trzeba porozmawiać.
Masz funkcję AI, która działa w wersji demo? Porozmawiajmy o tym, jak poradzi sobie przy rzeczywistym obciążeniu.
Czytam każdą wiadomość i odpowiadam osobiście.