Jak zbudowaliśmy LostInNotes: notatki, które odpowiadają zamiast zmuszać do szukania

Produkt, który postanowiliśmy zbudować

Każdy, kto robi notatki, buduje bazę wiedzy - świadomie albo nie. Notatki ze spotkań, pomysły, materiały, wycinki, rzeczy warte zapamiętania: przez miesiące i lata składają się na naprawdę wartościowy zapis tego, co ktoś wie. I dokładnie w chwili, gdy ta wiedza jest potrzebna, staje się prawie bezużyteczna, bo znalezienie właściwej notatki oznacza przewijanie, zgadywanie słów kluczowych i grzebanie w folderach, aż wreszcie wypłynie to, co pamiętało się połowicznie. Wiedza tam jest. Problemem jest jej wydobycie.

To właśnie tę frustrację LostInNotes ma usuwać. Jeśli ktoś ma już bazę wiedzy, nie powinien tracić czasu na jej przeszukiwanie. Szukanie to praca, którą oprogramowanie powinno wykonać za niego. Każda minuta, którą człowiek spędza na polowaniu na notatkę, o której wie, że ją napisał, to minuta zmarnowana, a dla kogoś, kto robi to w pracy, to stracony czas, który kosztuje. Idea produktu jest niemal wstydliwie prosta: gdy ludzie mają własny zasób wiedzy, powinni móc zadać mu pytanie i dostać odpowiedź, a nie iść szukać strony, która być może ją zawiera.

Produkt, który postanowiliśmy zbudować, nie był więc ładniejszym notesem. Był notesem, który odpowiada. Człowiek zapisuje to, co wie, tak jak zawsze, a gdy tego potrzebuje, zadaje pytanie zwykłym językiem i dostaje wprost odpowiedź wyciągniętą z własnych notatek, wraz ze źródłem. Robienie notatek to łatwiejsza połowa. Ta połowa, która czyni produkt wartym opłacenia, to zamiana sterty notatek w coś, z czym można po prostu porozmawiać.

Wiedza już tam jest. Produkt istnieje po to, żeby ją wydobyć, nie każąc ludziom szukać.

Choć brzmi to jak narzędzie dla każdego, największą wartość ma tam, gdzie wiedzy jest dużo i jest droga: u konsultantów, badaczy, prawników, osób prowadzących własne projekty - wszędzie tam, gdzie odpowiedź „gdzieś to zapisałem" kosztuje realny czas. Im więcej ktoś wie i im częściej musi z tej wiedzy korzystać, tym dotkliwszy jest koszt szukania, i tym większą różnicę robi możliwość po prostu zapytania. To właśnie dlatego zbudowaliśmy produkt wokół momentu potrzeby, a nie wokół samego gromadzenia: zbierać notatki potrafi każda aplikacja, ale dopiero szybkie, trafne wydobycie zamienia je z archiwum, do którego nikt nie zagląda, w narzędzie realnie oszczędzające czas.

Pytaj, nie szukaj

Szukanie to zły domyślny tryb dla własnej wiedzy i warto dokładnie powiedzieć dlaczego. Szukanie przerzuca robotę z powrotem na użytkownika. Zwraca listę możliwych trafień i oczekuje, że człowiek otworzy każde, przeczyta je i zdecyduje, które faktycznie odpowiada na pytanie. To w porządku, gdy ktoś przegląda nieznaną bibliotekę. To absurd, gdy biblioteka jest jego własna, a on już wie, że odpowiedź gdzieś tam jest. Nikt nie chce dziesięciu notatek wspominających o temacie; chce jednego zdania, które odpowiada na zadane pytanie.

Asystent AI świetnie się do tego nadaje. Mając pytanie i dostęp do zasobu wiedzy, może naraz przeczytać wszystko, co istotne, zebrać najważniejsze fragmenty i oddać odpowiedź zamiast listy do czytania. Dla osobistej lub zawodowej bazy wiedzy to zmiana jakościowa, bo wąskim gardłem nigdy nie było przechowywanie informacji. Było nim wydobycie. LostInNotes traktuje wydobycie jako funkcję centralną, a robienie notatek jako to, co je zasila.

To przeramowanie zmienia, pod co produkt jest optymalizowany. Klasyczna aplikacja do notatek optymalizuje pod zapisywanie i porządkowanie, po cichu zakładając, że znajdowanie zrobi użytkownik. LostInNotes optymalizuje pod moment potrzeby: człowiek ma pytanie i chce odpowiedzi z własnych materiałów jak najmniejszym wysiłkiem. Cała reszta produktu istnieje, żeby ten moment obsłużyć. To drobne przesunięcie akcentu zamienia miejsce, gdzie wiedza trafia na przechowanie, w miejsce, gdzie wiedza jest faktycznie używana.

Ta zmiana ma też konsekwencję, o której łatwo zapomnieć: skoro to asystent bierze na siebie znajdowanie, jego jakość staje się produktem. W klasycznym notatniku, gdy czegoś się nie znajduje, człowiek wini siebie - że źle nazwał plik. Gdy to narzędzie ma odpowiadać, każde nietrafienie jest jego winą, nie użytkownika. To podnosi poprzeczkę i przesuwa ciężar tam, gdzie powinien być: na oprogramowanie.

Precz z klawiaturą: głos zamiast pisania

Było drugie źródło tarcia, które chcieliśmy usunąć, a które większość aplikacji do notatek całkowicie ignoruje: klawiatura. Pisanie jest wąskim gardłem na obu końcach pętli. Zapisanie notatki przez pisanie jest wolne, zwłaszcza na telefonie i zwłaszcza w tych chwilach, gdy dobre notatki naprawdę powstają - po wyjściu ze spotkania, w samochodzie, w połowie myśli, gdy zatrzymanie się, żeby pisać, oznacza, że myśl ucieka. Wpisanie pytania to też tarcie, drobny podatek od tej właśnie rzeczy, którą produkt ma czynić bezwysiłkową.

Dlatego LostInNotes opiera się na STT i TTS. Użytkownik może podyktować notatkę, żeby ją zapisać, albo zadać pytanie i usłyszeć odczytaną odpowiedź. Speech-to-Text (STT) skraca drogę do zapisania myśli; Text-to-Speech (TTS) skraca drogę do jej odzyskania. Nie chodzi o nowinkę. Chodzi o to, że każde tarcie między myślą a jej zapisaniem, albo między pytaniem a odpowiedzią, zniechęca do sięgania po narzędzie. STT likwiduje największą z tych przeszkód - klawiaturę.

Zrobienie tego dobrze to więcej niż doklejenie przycisku mikrofonu do pola tekstowego. Mowa musi działać natychmiast, musi radzić sobie w wielu językach, a nie tylko po angielsku, a wypowiadana odpowiedź musi być czymś, czego człowiek naprawdę chce słuchać, a nie robotyczną ścianą tekstu. Sprawienie, żeby głos był naturalnym sposobem rozmowy z własną wiedzą, a nie gadżetem, wymagało realnej uwagi na szczegóły: tempo, informację zwrotną oraz to, jak inaczej buduje się odpowiedź mówioną niż pisaną.

Odpowiedź mówiona rządzi się innymi prawami niż pisana. Ściany tekstu nie da się przeskanować uchem, więc mówiona odpowiedź musi być krótsza, prowadzić od najważniejszego i unikać składni, która gubi słuchacza w połowie zdania. To pozornie drobiazg, a w praktyce decyduje o tym, czy ktoś w ogóle korzysta z odsłuchu, czy po pierwszej próbie wraca do czytania.

Jak podeszliśmy do budowy

Sposób, w jaki układamy kolejność prac, mówi o nas więcej niż jakakolwiek lista funkcji. LostInNotes to kompletny produkt - aplikacje mobilne, wersja webowa, backend, asystent AI, głos, płatności - a przy czymś tak szerokim kusi, żeby budować po trochu wszystkiego naraz i skończyć z wieloma rzeczami zrobionymi w połowie. Zrobiliśmy odwrotnie. Wzięliśmy się najpierw za części niosące największe ryzyko, te, które przesądzały, czy produkt w ogóle warto budować.

Najbardziej ryzykowne pytanie nie brzmiało, czy umiemy zbudować aplikację do notatek. Brzmiało: czy asystent odpowiadający z własnych notatek człowieka może być na tyle dobry, żeby mu zaufać - trafny, oparty na źródłach, uczciwy co do tego, czego nie wie. Gdyby to nie zadziałało, cała przesłanka się rozpadała, więc od tego zaczęliśmy. Równolegle wcześnie wzięliśmy na warsztat interakcję głosową, bo sterowanie głosem to obietnica kształtująca cały interfejs, a nie funkcja doklejana później.

Dopiero gdy te rzeczy były udowodnione, budowaliśmy na zewnątrz: sposób zapisywania, aplikacje wieloplatformowe, synchronizację, model subskrypcyjny oraz długi ogon pracy zamieniającej działający pomysł w produkt gotowy do wydania. Rozstrzyganie pytań być-albo-nie-być na początku to świadomy nawyk. To w dużej mierze powód, dla którego produkty, których się podejmujemy, docierają do prawdziwych użytkowników, zamiast utknąć jako efektowne demo, które nigdy nie staje się produktem.

Odpowiedzi z notatek użytkownika, nie z powietrza

Decyzją definiującą LostInNotes jest to, że asystent odpowiada z notatek użytkownika, a nie z pamięci ogólnego modelu o internecie. To różnica między narzędziem, na którym można polegać, a sztuczką na pokaz - i warto jasno powiedzieć, co znaczy.

Ogólny chatbot odpowiada ze wszystkiego, na czym go wytrenowano, co czyni go płynnym, a zarazem niepewnym wobec konkretnej wiedzy człowieka: nie wie, co jest w jego notatkach, a gdy czegoś nie wie, ma skłonność zmyślić wiarygodnie brzmiącą odpowiedź. To dokładnie złe zachowanie dla narzędzia do wiedzy. LostInNotes zamiast tego dla każdego pytania wyszukuje istotne fragmenty własnych notatek człowieka i buduje odpowiedź z tego, co faktycznie znalazł. Gdy ktoś o coś pyta, asystent nie sięga do mglistej puli wiedzy ogólnej. Czyta materiał tej osoby i z niego odpowiada.

W praktyce każde pytanie obsługujemy identycznie. Zapytanie trafia najpierw do warstwy wyszukiwania semantycznego: zamieniamy je na reprezentację wektorową i zestawiamy z wektorami notatek utrzymywanymi w bazie danych, wybierając te o najwyższym podobieństwie. Zbiór wynikowy jest z założenia ograniczony do zasobów osoby zadającej pytanie i opcjonalnie zawężony do wskazanego notatnika - i tylko on trafia do modelu językowego jako materiał, z którego wolno mu zbudować odpowiedź. Generowanie przebiega deterministycznie, a model zwraca odpowiedź ustrukturyzowaną zgodnie ze zdefiniowanym schematem, a nie swobodny tekst; dzięki temu treść, etykieta źródła i ewentualne załączniki są osobnymi polami, a nie czymś, co aplikacja musi wyłuskiwać z prozy.

Dwie decyzje w tej warstwie podjęliśmy na podstawie pomiarów, nie założeń. Pierwsza to kompromis między skutecznością wyszukiwania a szybkością działania: przetestowaliśmy różne rozmiary reprezentacji wektorowej i wybraliśmy ten, przy którym trafność wyników praktycznie nie spada, a rozmiar indeksu i czas odpowiedzi wyraźnie maleją - co ma znaczenie, gdy każde pytanie zaczyna się od przeszukania wektorów. Druga to możliwość podmiany modelu embeddingów bez przebudowy bazy: architektura pozwala zaindeksować nowy model równolegle ze starym i przełączać się między nimi, a skorzystaliśmy z tego już raz.

Trudność rośnie razem z bazą. Przy dziesięciu notatkach prawie wszystko da się przejrzeć; przy dziesięciu tysiącach asystent musi trafnie wybrać garść naprawdę istotnych fragmentów spośród ogromu, w którym wiele wygląda z pozoru podobnie. Im większa i cenniejsza staje się czyjaś wiedza, tym trudniejsze jest jej przeszukanie - a to właśnie moment, w którym produkt musi działać najlepiej, bo wtedy użytkownik polega na nim najmocniej.

Ogólny chatbot odpowiada z internetu. LostInNotes odpowiada z własnych notatek użytkownika - i pokazuje, skąd wzięła się każda odpowiedź.

Jak zrobiliśmy asystenta godnym zaufania

Asystent, który odpowiada z wiedzy człowieka, jest przydatny tylko wtedy, gdy można ufać jego odpowiedziom, a zaufania nie da się dokleić na końcu. Musi być zaprojektowane w sposób, w jaki asystent się zachowuje.

Mechanizm, na który się zdecydowaliśmy, to oznaczanie źródła, a nie odmowa. Każda odpowiedź kończy się jawną etykietą źródła - z notatek użytkownika albo z wiedzy ogólnej modelu - przetłumaczoną na język, w którym zadano pytanie. Asystent ma polecenie najpierw wyczerpać znalezione notatki i sięgać po wiedzę ogólną wyłącznie wtedy, gdy naprawdę jej tam nie ma, ale gdy już sięga, mówi o tym wprost. Wybraliśmy to zamiast płaskiego „nie znalazłem": oznaczona odpowiedź z wiedzy ogólnej jest bardziej użyteczna niż odmowa i znacznie uczciwsza niż nieoznaczona, a użytkownika stawia w pozycji, w której ocenia, zamiast zgadywać.

Dwie właściwości systemu utrzymują to zachowanie w ryzach. Pierwsza to powtarzalność: to samo pytanie zadane na tym samym materiale daje tę samą odpowiedź, a nie za każdym razem inaczej sformułowaną. Dopiero to czyni zachowanie modelu testowalnym, bo nie da się prowadzić testów regresji na systemie, który przy każdym uruchomieniu odpowiada inaczej. Druga to ustrukturyzowana odpowiedź: model zwraca dane w z góry określonym kształcie, wymuszonym przez system, a nie tekst, z którego aplikacja musi się domyślać. Asystent, który raz na jakiś czas odda wynik w innej postaci, niż aplikacja oczekiwała, to asystent, który raz na jakiś czas pokaże użytkownikowi błąd zamiast odpowiedzi.

Warstwa instrukcji sterujących modelem jest przy tym projektowana z założeniem, że ktoś będzie próbował ją obejść - bo część użytkowników spróbuje. Asystent ma pozostawać produktem także wtedy, gdy pytania dotyczą jego własnych reguł działania. W połączeniu z ograniczeniem zakresu wyszukiwania daje to asystenta, który trzyma formę pod naciskiem, zamiast takiego, którego da się namówić na wszystko.

Zaufanie trzeba też umieć zmierzyć, a nie tylko zadeklarować. Odpowiedzi asystenta sprawdzaliśmy na zestawach pytań o znanej, poprawnej odpowiedzi oraz na przypadkach, w których poprawną odpowiedzią jest przyznanie, że czegoś nie ma w notatkach. To drugie jest równie ważne jak pierwsze: model, który zawsze coś odpowie, wygląda mądrze na demie, a zawodzi dokładnie tam, gdzie użytkownik najbardziej potrzebuje uczciwości. Bez takiej oceny „lepszy asystent" to tylko wrażenie, a przy narzędziu, na którym ktoś ma polegać, wrażenie nie wystarcza.

Szukanie po znaczeniu, nie po słowach kluczowych

Pod asystentem leży zmiana w tym, jak w ogóle działa znajdowanie. Klasyczne wyszukiwanie dopasowuje słowa: człowiek wpisuje termin i dostaje notatki zawierające dokładnie ten termin. To zawodzi bez przerwy przy własnej wiedzy, bo ludzie rzadko pamiętają dokładne słowa, których użyli. Pamiętają myśl. Wyszukanie „ta rzecz o wycenie planu enterprise" nie zwraca nic, gdy notatka mówi „progi rabatu przy umowie rocznej", a wyszukiwanie po słowach kluczowych rozkłada ręce.

LostInNotes znajduje zamiast tego po znaczeniu. Rozumie, że pytanie i notatka, która na nie odpowiada, mogą dotyczyć tego samego, niemal nie dzieląc słów, i wydobywa notatkę na podstawie tego, o czym jest, a nie tego, jakie terminy przypadkiem zawiera. To rozumienie znaczenia sprawia, że działa i wyszukiwanie, i asystent: asystent może odpowiedzieć z notatek człowieka tylko wtedy, gdy potrafi niezawodnie znaleźć te istotne, a znajdowanie ich po znaczeniu, a nie po dosłownym brzmieniu, czyni to możliwym w prawdziwej, ludzkiej, niespójnie sformułowanej bazie wiedzy.

Pod spodem jest to wyszukiwanie wektorowe, nie tekstowe. Każda notatka ma swoją reprezentację liczbową opisującą, o czym jest, a pytanie zamieniane jest na reprezentację tego samego rodzaju. Znalezienie właściwych notatek staje się wtedy kwestią podobieństwa, a nie zgodności słów - i właśnie dlatego pytanie oraz notatka, które nie mają ani jednego wspólnego wyrazu, mogą wylądować obok siebie. Do modelu trafia wąski zestaw najbliższych trafień: na tyle szeroki, żeby dało się z niego odpowiedzieć, i na tyle wąski, żeby odpowiedź była szybka, a użytkownik sprawdzający wskazane źródła zdążył je realnie przeczytać.

Dla osoby, która z tego korzysta, to różnica między narzędziem, które pomaga tylko wtedy, gdy pamięta się dokładnie, jak się coś sformułowało, a takim, które pomaga zawsze, gdy pamięta się z grubsza, o czym się myślało. To drugie jest tym, jak naprawdę działa pamięć, a dopasowanie narzędzia do tego, jak ludzie faktycznie sobie przypominają, to duża część powodu, dla którego wydaje się naturalne, a nie upierdliwe.

Prywatne notatki traktujemy jak prywatne

Ludzie wrzucają w notatki swoje najbardziej osobiste myśli i najbardziej wrażliwe informacje, a produkt, który przegląda to wszystko, żeby odpowiadać na pytania, niesie realną odpowiedzialność. Potraktowanie tej odpowiedzialności poważnie kształtowało produkt od początku.

Notatki człowieka należą do niego. Istnieją, by mu służyć - by je przeszukiwać, by zasilały asystenta, by odpowiadały na jego pytania - a nie po to, by stać się cudzym aktywem. Ta zasada napędza szereg konkretnych decyzji o tym, jak informacje są obsługiwane, kto może do nich sięgnąć i jak starannie są chronione, wszystko w służbie prostej obietnicy: wartość, którą tworzy baza wiedzy, wraca do osoby, która ją zbudowała, i do nikogo więcej.

Izolacja jest wymuszona w jedynym miejscu, w którym nie da się o niej zapomnieć. Zapytanie o podobieństwo filtruje po identyfikatorze właściciela wewnątrz samego SQL-a, w tym samym zapytaniu, które wykonuje porównanie wektorów - a nie w kodzie aplikacji ponad nim, który późniejszy refaktor mógłby obejść. Nie ma w systemie ścieżki, która pobiera wektor bez jednoczesnego ograniczenia go do osoby będącej jego właścicielem. Opcjonalny filtr notatnika zawęża wyszukiwanie dalej i sam jest sprawdzany pod kątem własności, zanim zostanie zastosowany, więc podanie API cudzego identyfikatora notatnika nie daje absolutnie nic.

Granica wyszukiwania jest zarazem granicą prywatności dla modelu. Asystent widzi wyłącznie te notatki, które zwróciło jedno konkretne pytanie - nigdy otaczającego notatnika, nigdy niczego cudzego - a nic z tego nie jest używane do trenowania. Praktyczna konsekwencja jest taka, że pojedyncze zapytanie jest ograniczone do materiału jednej osoby - przez bazę danych, a nie przez konwencję. Taką właściwość znacznie łatwiej wykazać przed działem bezpieczeństwa klienta niż zapewnienie, że model językowy nie wykroczy poza przewidziane zachowanie.

Wybór modelu, na który stać produkt

Funkcja oparta na AI ma koszt jednostkowy, a w produkcie freemium spora część tego kosztu przypada na ludzi, którzy nie płacą nic. To ograniczenie ukształtowało wybór modelu w równym stopniu co jakość. Dobraliśmy model do zadania, zamiast sięgać po największy dostępny, bo trudną częścią odpowiadania z czyichś notatek jest wyszukiwanie, a nie rozumowanie. Gdy odpowiednie notatki są już wybrane, samo wygenerowanie odpowiedzi jest bliższe streszczeniu niż analizie - a model dobrany do takiego zadania wykonuje je w czasie nieporównywalnie krótszym niż model ogólnego przeznaczenia o znacznie większej pojemności. Dopasowanie modelu do faktycznego zadania utrzymuje funkcję AI responsywną i jednocześnie zdrową kosztowo.

Wejście głosowe przechodzi wcześniej przez drugą, tańszą decyzję. Najpierw mały call klasyfikujący rozstrzyga, czy człowiek zadaje pytanie, czy dyktuje nową notatkę, i zwraca ustrukturyzowaną akcję zamiast prozy. Podyktowana notatka leci prosto do zapisu, omijając wywołanie embeddingu, wyszukiwanie wektorowe i model główny w całości. Najtańsze zapytanie w każdym produkcie AI to takie, które nigdy nie dociera do drogiej ścieżki, a wiedza o tym, które zapytania to te, jest warta więcej niż dowolna optymalizacja promptu.

Szerokość wyszukiwania jest dźwignią kosztową w ten sam sposób. Wąski zestaw najbliższych trafień zamiast szerokiego utrzymuje krótki prompt, a długość promptu to większość tego, za co realnie płaci się przy wywołaniu modelu. Rzeczą, która czyni to zarządzalnym, a nie kruchym, jest to, że wszystkie trzy dźwignie - który model generuje, ile notatek wraca i która wersja embeddingów jest odpytywana - są konfiguracją, a nie architekturą. Ekonomię da się przestroić per zapytanie bez dotykania produktu, czyli dokładnie ta elastyczność, której chce się w dniu, w którym dostawca zmienia cennik.

Jeden produkt na iOS, Androida i web

LostInNotes nie jest aplikacją na iPhone'a z doklejoną stroną. To jeden produkt - na iOS, Androidzie i w wersji webowej - który ma sprawiać wrażenie tego samego produktu, gdziekolwiek ktoś go otworzy. Notatka wypowiedziana na telefonie jest na laptopie; pytanie zadane w wersji webowej dostaje tę samą odpowiedź co na telefonie. Ta spójność to obietnica dana użytkownikowi, a jej dotrzymanie to decyzja inżynierska podjęta wcześnie, a nie przypadek.

Zbudowanie trzech platform jako trzech osobnych aplikacji potroiłoby pracę i zagwarantowało, że się rozjadą, z funkcjami lądującymi na jednej przed drugą oraz subtelnie różnym zachowaniem. Zamiast tego zbudowaliśmy doświadczenie ze wspólnego fundamentu, tak że ta sama logika produktu napędza każdą platformę, a koszt dołożenia kolejnej pozostaje niski. To właśnie czyni realnym utrzymanie spójnego, naprawdę wieloplatformowego produktu przez mały zespół. To samo podejście pozwala nam dostarczać klientom mobile i web razem, bez budżetu na trzy osobne buildy.

Każda platforma nadal może wydawać się natywna tam, gdzie to się liczy. Telefon i przeglądarka to różne środowiska o różnych oczekiwaniach, a poszanowanie tych różnic przy jednoczesnym dzieleniu wszystkiego pod spodem to równowaga, która sprawia, że produkt wieloplatformowy jest wszędzie pełnowartościowy, a nie sprowadzony do najmniejszego wspólnego mianownika.

Spójność między platformami nie bierze się sama z użycia jednej technologii. To ciągłe decyzje o tym, co jest wspólne, a co świadomie różne - żeby aplikacja na telefonie korzystała z gestów i powiadomień, a wersja webowa z klawiatury i wielu okien, ale obie prowadziły do tej samej odpowiedzi z tych samych notatek. Utrzymanie tej równowagi w miarę rozrastania się produktu to praca, która nigdy się nie kończy.

Ten sam stan na każdym urządzeniu

Obietnica, że notatki są wszędzie takie same, brzmi prosto, a stoi za nią decyzja podjęta na samym początku: źródłem prawdy jest usługa, nie urządzenie. Każdy klient pracuje na tym samym stanie, zamiast utrzymywać własną kopię i próbować pogodzić ją później z resztą.

To świadomy wybór, który usuwa całą klasę problemów - rozjeżdżające się wersje tej samej notatki, duplikaty po ponownym połączeniu, ciche nadpisanie jednej zmiany przez drugą. Przy produkcie, w którym utrata choćby jednej notatki podważa sens całości, uznaliśmy tę cenę za niższą niż koszt utrzymywania mechanizmu scalania zmian, który i tak w części przypadków musiałby pytać użytkownika o decyzję.

To dokładnie ten rodzaj mało efektownej, niewidocznej-gdy-działa inżynierii, która odróżnia produkt, któremu ludzie ufają, od dema, które świetnie wygląda, a po cichu gubi dane w drugim tygodniu. Nigdy nie pojawia się na liście funkcji, a jest jedną z rzeczy najmocniej decydujących, czy ludzie zostają przy narzędziu.

Najważniejsze było jedno założenie: zapis nigdy nie może się nie udać. Człowiek, który ma myśl i chce ją zanotować, nie powinien nawet wiedzieć, czy w tej chwili jest online. Notatka ma zostać zapisana od razu, lokalnie, a synchronizacja ma zadziać się w tle, gdy tylko będzie mogła. Odwrócenie tego - najpierw sieć, potem zapis - to najprostszy sposób, żeby przy słabym zasięgu stracić dokładnie tę notatkę, na której najbardziej zależało.

Zbudowane tak, żeby było dostępne

Narzędzie, na którym ludzie polegają, że przechowa ich wiedzę, musi być na miejscu, gdy po nie sięgają - co czyni dostępność funkcją samą w sobie. Jeśli asystent jest niedostępny w chwili, gdy ktoś potrzebuje odpowiedzi, produkt zawiódł w jedynej rzeczy, która się liczy, niezależnie od tego, jak dobra byłaby ta odpowiedź.

Żeby to wesprzeć, backend działa w wielu regionach, a nie zależy od jednego miejsca. Rozproszenie usługi w ten sposób poprawia odporność - problem w jednej lokalizacji nie kładzie całego produktu - i utrzymuje szybkość dla ludzi w różnych częściach świata, zamiast być szybkim dla jednych, a ślamazarnym dla reszty. Zaprojektowanie systemu, który działa w takim układzie i zachowuje się poprawnie, gdy jeden z regionów przestaje odpowiadać, jest istotnie trudniejsze niż postawienie pojedynczego serwera. To rodzaj fundamentu, którego nie widać aż do dnia pierwszej awarii - i który dopiero wtedy zwraca poniesiony koszt.

Użytkownik nie widzi z tego nic i taka jest właśnie intencja. Zrób niezawodność porządnie, a nikt nigdy o niej nie pomyśli: aplikacja jest, jest szybka i odpowiada. To niepozorne doświadczenie sprawia, że narzędzie po cichu zamienia się w codzienny nawyk.

Dostępność to też kwestia zaufania, nie tylko techniki. Ktoś, kto raz sięgnie po odpowiedź i trafi na niedziałającą aplikację w ważnym momencie, drugi raz podejdzie z rezerwą - a przy narzędziu do wiedzy rezerwa oznacza, że powoli przestaje się na nim polegać. Dlatego traktowaliśmy „po prostu działa" jak funkcję, którą trzeba świadomie zaprojektować, a nie jak coś, co samo się wydarzy.

Praca w wielu językach

LostInNotes działa w wielu językach, a dla produktu zbudowanego wokół rozumienia znaczenia to znacznie więcej niż przetłumaczenie przycisków. Ludzie robią notatki we własnym języku, zadają w nim pytania i oczekują, że głos ich zrozumie oraz odpowie w tym samym języku. Każda część produktu, która operuje na znaczeniu, musi działać we wszystkich tych językach, nie tylko etykiety interfejsu.

To sięga głęboko w produkt. Znajdowanie notatki po znaczeniu musi działać, gdy pytanie i notatka są w tym samym języku, a asystent musi odpowiadać w języku, którego człowiek faktycznie używa. Głos znów podnosi poprzeczkę: rozpoznawanie mowy oraz wypowiadane odpowiedzi muszą trzymać poziom w szerokim zakresie języków i akcentów, a nie tylko dawać dopracowane doświadczenie po angielsku, a słabe wszędzie indziej. Porządna obsługa dziesięciu języków to zobowiązanie dotykające naraz zapisywania, wyszukiwania, asystenta oraz głosu.

Zyskiem jest produkt, który traktuje ludzi niepracujących po angielsku jak pełnoprawnych użytkowników, a nie dodatek - co dla firmy z Europy, budującej dla europejskiej i globalnej publiczności, nie jest miłym dodatkiem. To podstawa, a zrobienie tego dobrze od początku jest dużo tańsze niż doróbka, gdy produkt już wszędzie zakłada jeden język.

Wielojęzyczność zmienia też testowanie. Coś, co działa idealnie po angielsku, potrafi się posypać na języku o innej gramatyce, innym zapisie liczb czy innym sposobie skracania słów. Dlatego jakości nie da się sprawdzić raz i uznać za załatwioną - trzeba ją weryfikować w każdym obsługiwanym języku z osobna, bo użytkownik w danym języku widzi tylko swoją wersję, nie średnią.

Dlaczego takie narzędzie kumuluje wartość

Większość oprogramowania jest warta mniej więcej tyle samo w setnym dniu co w pierwszym. Narzędzie zbudowane wokół własnej wiedzy człowieka jest inne: staje się cenniejsze, im więcej się go używa. Każda dodana notatka to jedna rzecz więcej, z której asystent może odpowiedzieć, więc produkt nie tylko utrzymuje wartość w czasie, ale ją zwiększa. Baza wiedzy zbudowana w tym miesiącu poprawia odpowiedzi w następnym, a nawyk po cichu sam się napędza.

Ta kumulacja jest prawdziwym powodem, dla którego rama „pytaj, nie szukaj" tak bardzo się liczy. Jeśli znajdowanie własnych notatek boli, ludzie przestają ufać bazie, przestają ją zasilać i koło zamachowe nigdy nie rusza. Jeśli pytanie jest bezwysiłkowe, a odpowiedzi są rzetelne, karmią ją dalej, a każdy dodatek podnosi wartość wszystkiego, co już tam jest. Zadaniem produktu jest utrzymać tę pętlę w ruchu: sprawić, by zapisywanie było bez tarcia, by odpowiedzi były godne zaufania oraz by narzędzie było na miejscu za każdym razem, aż stanie się czymś, po co sięga się bez namysłu.

To także powód, dla którego przy takim produkcie tak bardzo liczy się mało efektowna robota. Niezawodność, synchronizacja, uczciwe odpowiedzi, działający głos - żadne z nich nie jest funkcją z nagłówka, ale każde chroni pętlę. Jedna zgubiona notatka, jedna pewna, lecz błędna odpowiedź, jedna awaria w złym momencie - i zaufanie człowieka do własnej bazy wiedzy dostaje cios, którego efektowna funkcja nie naprawi. Budowanie pod długą, kumulującą się relację, a nie pod efektowne pierwsze demo, to duża część tego, co odróżnia produkt, przy którym ludzie zostają, od takiego, który wypróbują raz. To ta sama soczewka, którą przykładamy do produktu klienta: pytanie nigdy nie brzmi tylko, czy dobrze wypada na demie, ale czy ktoś nadal będzie na nim polegał za rok.

Prawdziwy biznes subskrypcyjny

LostInNotes nie jest demem ani projektem na boku; to produkt subskrypcyjny, za który ludzie płacą, a wbudowanie modelu biznesowego w produkt to osobny kawał pracy. Model jest freemium: darmowy poziom na tyle hojny, by ludzie mogli naprawdę używać produktu i zobaczyć jego wartość, plus płatny poziom dla tych, którzy zaczynają na nim polegać. Asystent, oraz to, ile ktoś go używa, jest sercem tego, co odblokowuje subskrypcja.

Sprawienie, żeby freemium działało, jest subtelniejsze niż postawienie muru wokół kilku funkcji. Darmowy poziom musi być użyteczny na tyle, żeby ludzie zostali i dotarli do chwili, w której produkt sam się sprzedaje, a płatny musi być wyraźnie tego wart. Za tym stoi realna mechanika: rzetelne i sprawiedliwe liczenie zużycia względem limitów, obsługa momentu, gdy ktoś przechodzi na wyższy plan albo jego subskrypcja wygasa, oraz robienie tego spójnie w sklepach mobilnych i w wersji webowej, które obsługują płatności w zupełnie inny sposób. Subskrypcja, która działa idealnie na iOS, a psuje się w webie, nie jest działającą subskrypcją.

Zbudowaliśmy produkt wokół tego od początku, zamiast doklejać płatny mur na końcu, bo wciskanie modelu rozliczeń w produkt, który się go nie spodziewał, to znany sposób na stratę tygodni. Sprawienie, by droga od darmowego do płatnego była uczciwa i płynna, gdziekolwiek ktoś akurat korzysta z produktu, to część tego, co zamienia dobre narzędzie w biznes.

Sam próg między darmowym a płatnym też jest decyzją produktową, nie tylko cenową. Jeśli darmowy poziom jest zbyt skąpy, ludzie odchodzą, zanim zobaczą wartość; jeśli zbyt hojny, nikt nie ma powodu zapłacić. Trafienie w ten balans wymaga zrozumienia, w którym momencie produkt faktycznie się sprzedaje, oraz ustawienia limitów tak, żeby wypadały tuż za tym momentem, a nie przed nim.

Publikacja w App Store i Google Play

Produkt mobilny nie jest skończony, gdy działa na telefonie jednego dewelopera. Jest skończony, gdy jest dostępny w App Store i Google Play, a dotarcie tam to etap z własnymi regułami, który zaskakuje zespoły. Oba sklepy recenzują to, co publikują, a aplikacja łącząca subskrypcje, asystenta AI, głos oraz dostęp do prywatnych notatek człowieka daje recenzentowi mnóstwo do prześwietlenia.

Każdy sklep ma własne oczekiwania: jak przedstawiane i rozliczane są subskrypcje, jak proszone i wyjaśniane są uprawnienia takie jak mikrofon, jak dane użytkownika są obsługiwane i ujawniane. Spełnienie tego wszystkiego, w dwóch sklepach o różnych regułach, i przejście review bez serii odrzuceń, z których każde kosztuje dni, to dokładnie ten rodzaj pracy, którą pierwsze wydanie najczęściej niedoszacowuje. To także praca, przez którą przeszliśmy wiele razy - dlatego bierzemy ją na siebie jako część zadania, a nie traktujemy jako niespodziankę na końcu.

Nagroda, jak na tym etapie zawsze, jest niewidoczna: aplikacja, która przychodzi ze sklepu jak każde inne pobranie, przechodzi review bez walki i której człowiek ufa na tyle, by wypełnić ją swoją prywatną wiedzą. To zaufanie zdobywa się w setce drobiazgów, których żaden użytkownik nigdy nie zobaczy - i to różnica między produktem, który się wydaje, a takim, który grzęźnie tydzień przed metą.

Połączenie AI, głosu i dostępu do prywatnych notatek podnosi też poprzeczkę w tym, co trzeba jasno wyjaśnić - i użytkownikowi, i recenzentowi sklepu. Po co aplikacji mikrofon, co dzieje się z tym, co ktoś podyktuje, jak przedstawiona jest cena subskrypcji: to pytania, na które trzeba mieć czytelną odpowiedź, zanim aplikacja w ogóle trafi do recenzji. Przygotowanie tego z góry jest tańsze niż tłumaczenie się po odrzuceniu.

Co ten projekt mówi o tym, jak pracujemy

Podłączenie chatbota do bazy danych zajmuje weekend. Miesiące pochłania wszystko, co zamienia to w produkt: trafność, której nie trzeba sprawdzać, wyszukiwanie po znaczeniu, koszt znoszący darmowy plan i trzy platformy działające tak samo.

Kłopotliwe w budowaniu na modelu językowym jest to, że jakość nie ma kompilatora. Nic nie zapala się na czerwono, gdy asystent zaczyna odpowiadać odrobinę gorzej, więc kontrole trzeba było zaprojektować świadomie: stałe pytania na stałych notatkach, wymuszona powtarzalność, żeby dwa przebiegi dało się w ogóle porównać, i ktoś czytający wyniki, kto nie pisał promptu. Produkt AI ukrywa swoje najgorsze zachowania w odpowiedziach, które czyta się bez zarzutu - i właśnie dlatego jego autor jest złą osobą do ich oceny.

To właśnie jest tym, czego naprawdę dowodzi taki case study. Nie tego, że umiemy zbudować akurat aplikację do notatek, ale że umiemy wziąć pomysł - nawet taki oparty o AI, głos i realny model biznesowy - i dowieźć go aż do czegoś zainstalowanego, opłaconego i użytkowanego. Jeśli masz produkt, który musi przejść tę samą drogę, niezależnie od tego, czy przypomina ten, to właśnie jest praca, którą wykonujemy.

Co powiedzielibyśmy innemu zespołowi

Jeśli myślisz o zbudowaniu czegoś w tym kształcie - produktu AI nad prywatnymi danymi, dostarczanego na mobile i web z realną subskrypcją - oto pięć rzeczy, które mówimy każdemu klientowi przed pierwszym sprintem.

• Oprzyj AI na własnych danych. Asystent odpowiadający z ogólnego modelu będzie zmyślał na temat Twojej konkretnej wiedzy. Wyszukiwanie z prawdziwej treści i odpowiadanie z tego, co się znalazło, to różnica między narzędziem, któremu ludzie ufają, a takim, którego po cichu przestają używać.
• Zaprojektuj uczciwość od początku. Nauczenie asystenta mówić „nie wiem", zamiast wymyślać odpowiedź, jest trudniejsze, niż brzmi, i ważniejsze niż niemal każda funkcja. Pewna, ale błędna odpowiedź jest gorsza niż jej brak.
• Głos to usuwanie tarcia, nie gadżet. Jeśli zbudujesz go serio - szybki, wielojęzyczny, z odpowiedziami skrojonymi pod słuchanie - zmienia to, ile ludzie faktycznie używają produktu. Jeśli go dokleisz, zostaje przyciskiem, którego nikt nie naciska.
• Synchronizacja to problem pierwszej kategorii. Dla czegokolwiek, co przechowuje wiedzę człowieka, zgubienie lub zdublowanie danych to nie usterka, to złamana obietnica. Traktuj to jak rdzeń, nie jak hydraulikę.
• Wbuduj model biznesowy wcześnie. Freemium i rozliczenia wieloplatformowe to realna inżynieria. Wciskanie ich w produkt, który się ich nie spodziewał, kosztuje tygodnie, których nie zaplanowałeś.

Każdy z tych punktów podnieślibyśmy już na pierwszej rozmowie, bo każdy przesuwa budżet. Przepaść między demem AI a produktem AI, za który ludzie płacą, składa się niemal wyłącznie z tych pięciu rzeczy - i żadnej z nich nie widać, dopóki demo idzie dobrze.

Najczęstsze pytania klientów

Czy LostInNotes to Wasz własny produkt, czy zbudowaliście go dla klienta?

To nasz własny. Sami go wymyśliliśmy, zaprojektowaliśmy, zbudowaliśmy i wydaliśmy - w App Store, Google Play i w wersji webowej. Pokazujemy go, bo to dowód tego, co dowozimy, a dla klientów budujemy tak samo.

Czy zbudowalibyście asystenta AI, który odpowiada z naszych danych albo bazy wiedzy?

Tak. LostInNotes odpowiada w oparciu o własne notatki użytkownika, a nie o ogólny model, i to samo podejście działa nad firmowymi dokumentami, zgłoszeniami czy wewnętrzną bazą wiedzy. Wartością jest to, że ludzie zadają pytanie, zamiast szukać odpowiedzi.

Czy dodacie do naszej aplikacji sterowanie głosem i mówione odpowiedzi?

Tak. LostInNotes pozwala wypowiadać notatki i pytania oraz słuchać odczytanych odpowiedzi, w wielu językach. Głos usuwa tarcie pisania, a tę samą interakcję - zamianę mowy na tekst i syntezę mowy - możemy wnieść do innych produktów.

Czy budujecie jeden produkt na iOS, Androida i web?

Tak. LostInNotes to jeden produkt na iOS, Androidzie i w wersji webowej, zbudowany z jednej wspólnej bazy kodu, dzięki czemu doświadczenie jest spójne, a koszt dołożenia platformy pozostaje niski.

Jak powstrzymujecie asystenta AI przed zmyślaniem?

Najpierw wyszukujemy we własnej treści użytkownika i odpowiadamy z tego, co faktycznie znaleźliśmy, a potem oznaczamy każdą odpowiedź źródłem - notatki użytkownika albo wiedza ogólna modelu. Generowanie przebiega deterministycznie i w wymuszonym kształcie odpowiedzi, więc zachowanie jest powtarzalne, a przez to testowalne. Dla narzędzia do wiedzy odpowiedź z widocznym źródłem jest warta znacznie więcej niż taka, która po prostu brzmi pewnie.

Czy to my jesteśmy właścicielem kodu i kont w sklepach?

Tak. Wy jesteście właścicielem kodu, repozytoriów i kont w sklepach. Możemy przekazać wszystko Waszemu wewnętrznemu zespołowi, kiedy tylko zajdzie potrzeba, bez uzależniania od nas.