Dostarczony produkt
Romance AI było pomysłem startupowym zrealizowanym jako aplikacja mobilna we Flutterze. Generowała personalizowane historie romantyczne i soft-erotyczne, uwzględniała preferencje czytelnika i przechowywała kupione historie po stronie klienta. Backend korzystał z Google Cloud i Firestore.
Czytelnicy mogli kalibrować doświadczenie wokół kilku kierunków inspirowanych fandomami i własnych preferencji. Generowanie wykorzystywało schematy opracowane na podstawie naszych badań, testów z użytkownikami i wskazówek ekspertów dziedzinowych. Schematy nadawały strukturę oryginalnym historiom odcinkowym, zamiast pozostawiać modelowi wszystkie decyzje na podstawie krótkiej instrukcji.
Literatura odcinkowa wymaga zachowania stanu opowieści między generowanymi rozdziałami. Tworzone przez aplikację historie odcinkowe musiały uwzględniać wcześniejsze motywacje, relacje i otwarte wydarzenia. To ograniczenie było podstawą projektowania adaptacyjnej literatury odcinkowej w produkcie.
Aplikacja generowała też niewielką liczbę nieerotycznych grafik dla rozdziałów i rozróżnienia opowieści. Stable Diffusion tworzył obrazy dopasowane do szczegółów historii, atmosfery tajemnicy i identyfikacji wizualnej produktu.
Dlaczego proza wymagała innego podejścia
Modele ogólnego przeznaczenia pisały nieprecyzyjną i nadmiernie skompresowaną prozę. W naszych testach potrafiły zamknąć w dwóch lub trzech akapitach materiał, który zawodowy autor rozwinąłby na pięciu do dziesięciu stronach książki. Taki sposób pisania bywa wystarczający w streszczeniach, marketingu lub dokumentacji, ale osłabiał tempo, atmosferę, postacie i spójność narracji.
Odpowiedzieliśmy rozbudowanymi instrukcjami narracyjnymi i przykładami. Powstał jeden z najdłuższych promptów systemowych, jakie wówczas zbudowaliśmy. Zajmował ponad 70% dostępnego kontekstu. Taka proporcja była potrzebna do kontrolowania tempa, konstrukcji scen, zachowania postaci, tonu i relacji między elementami opowieści.
Prompt był tylko jedną warstwą. Uporządkowane schematy opisywały postacie, świat, stan relacji, wydarzenia i otwarte wątki. Preferencje czytelnika i wybory podejmowane w rozdziałach mogły wpływać na opowieść bez generowania każdego rozdziału jako oderwanego zadania.
Wrażliwe treści i ograniczenia modeli
Kierunek romantic-plus powodował praktyczny problem wyboru modelu. Większość dostępnych modeli lub dostawców nie pozwalała niezawodnie obsłużyć dozwolonych treści soft-erotycznych w ramach ich ograniczeń. Modele różniły się też zdolnością do utrzymania jakości i struktury historii.
Ocenialiśmy je względem wymagań produktu, a nie ogólnego benchmarku. Sprawdzaliśmy, czy model przestrzega schematu, zachowuje ton, unika nadmiernego skracania i konsekwentnie tworzy treści w zamierzonej kategorii.
Aplikacja obsługiwała kilka kierunków preferencji, ale opis nie przypisuje nam praw do nazwanych światów należących do osób trzecich. Dostarczone schematy służyły do budowania oryginalnych historii na podstawie wskazówek ekspertów i informacji z testów.
Prywatność, dostęp i płatności
Historie i powiązane dane były szyfrowane end-to-end. Dostęp do aplikacji był chroniony, aby inna osoba posiadająca telefon nie mogła łatwo otworzyć prywatnej biblioteki. Miało to znaczenie, ponieważ treści i preferencje mogły być wrażliwe nawet bez typowych danych identyfikacyjnych.
Model komercyjny obejmował jednorazowe płatności za historie. Po zakupie opowieści były przechowywane po stronie klienta. Nie deklarujemy konkretnego certyfikatu szyfrowania, wolumenu płatności ani statusu regulacyjnego, ponieważ takich danych nie otrzymaliśmy.
Produkt mobilny łączył Flutter, Google Cloud i Firestore. Stable Diffusion odpowiadał za dynamiczne, nieerotyczne grafiki. Stos technologiczny ma znaczenie, ponieważ zakres obejmował aplikację mobilną, dane, prywatny dostęp, generowanie tekstu i media dopasowane do historii.
Dlaczego zatrzymaliśmy rozwój
Zatrzymaliśmy produkt, ponieważ kolejne generacje modeli coraz trudniej pozwalały utrzymać przewidywalną jakość w tej kategorii. Jednocześnie narzędzia takie jak ChatGPT i Claude ułatwiły użytkownikom samodzielne tworzenie historii. Rosły więc koszty utrzymania, a przewaga osobnej aplikacji malała.
Przy dzisiejszej technologii rozważylibyśmy zbudowanie tej funkcji jako skilla, pluginu albo serwera MCP używanego wewnątrz istniejącego asystenta. Jest to retrospektywny kierunek, a nie część dostarczonej aplikacji. Wymagałby też prostego onboardingu, ponieważ pierwotna grupa użytkowników nie była szczególnie techniczna.
Potwierdzony rezultat i granice
Potwierdzonym rezultatem jest aplikacja Flutter z szyfrowanym dostępem, jednorazowymi płatnościami, przechowywaniem historii po stronie klienta, schematami narracyjnymi, personalizacją, testami z użytkownikami i generowanymi grafikami rozdziałów. Projekt dostarczył też wiedzy o promptowaniu długiej narracji oraz ograniczeniach polityk i zmiennego zachowania modeli.
Opis nie deklaruje obecnej dostępności, aktywnych użytkowników, przychodów, zmierzonego zaangażowania, gwarantowanej jakości narracji ani praw do zewnętrznych fandomów. Aplikacja została zatrzymana z powodów utrzymaniowych i rynkowych opisanych powyżej.
W podobnym produkcie punktem wyjścia są polityka treści, schemat narracji, model prywatności i metoda oceny. Powiązana strona o systemach agentowych pokazuje, jak uporządkowany stan wspiera wieloetapowe generowanie.