W skrócie.
Regułę dla modelu, który pisze szkic, można przekazać na dwa sposoby. Można ją zapisać w instrukcjach i liczyć, że model się do niej zastosuje. Albo oprogramowanie może sprawdzić gotowy szkic i odrzucić go, gdy łamie regułę.
W naszym najwyraźniejszym przykładzie zapisana reguła się rozjechała. Przez mniej więcej dwa tygodnie instrukcje mówiły modelowi dokładnie, jak zakończyć wiadomość. Spośród 178 szkiców z tego okresu 40 miało zakończenie dokładnie zgodne z instrukcją, 93 inne, a 45 nie miało go wcale.
Dlatego reguły, które mają znaczenie, są teraz kontrolami, które odrzucają, a każde odrzucenie jest zapisywane razem z regułą, która je spowodowała. Ten tekst pokazuje, co wychwyciły te kontrole. Nie pokazuje, że wiadomości stały się lepsze, a przykład dotyczy jednej konfiguracji i nie jest ogólnym wskaźnikiem.
Jedna instrukcja, dwa tygodnie bez kontroli.
Przestrzeń robocza może ustalić, jak kończą się jej wiadomości: słowa pożegnania i podpis. To najprostsza reguła, jaką mamy. Nie wymaga oceny, tylko przepisania.
Mniej więcej od 7 do 20 września instrukcje dla modelu podawały zakończenie, a wyniku nic nie sprawdzało. Przejrzeliśmy szkice napisane w tym czasie przez model i porównaliśmy ich końcówki z ustawionym zakończeniem.
Te liczby mają trzy ograniczenia. Wszystkie szkice policzone jako „inne” pochodzą z jednej konfiguracji i różnią się w ten sam drobny sposób. Porównaliśmy dawne szkice z zakończeniem w obecnym ustawieniu. A początek okresu to data zapisania instrukcji, nie data, od której zaczęła działać. Widać tu więc, jak rozjeżdża się jedna konfiguracja. To nie jest ogólny wskaźnik tego, jak często model pomija instrukcję.[1]
Wieczorem 20 września zakończenie stało się kontrolą. Szkic bez właściwego zakończenia jest odrzucany. Od tego czasu kontrola odrzuciła 46 razy: 44 razy, bo zakończenia brakowało, i dwa razy, bo było inne.
Tych 46 odrzuceń nie można zestawiać ze 178 szkicami. Odrzucenie to zdarzenie, a jeden szkic może zostać odrzucony kilka razy. Obie liczby mierzą co innego, w innych okresach.
Co odrzuciły kontrole.
SYNC pisze dwiema ścieżkami. W pierwszej między 7 a 29 września zapisano 527 odrzuceń. Tabela porządkuje je według tego, czego dotyczyło odrzucenie.
| Co odrzuciła kontrola | Odrzucenia | Od kiedy |
|---|---|---|
| Tekst nie ma podziału na akapity | 86 | 11 wrz |
| Wiadomość podaje swoje źródło albo mówi, że ktoś coś sprawdził | 65 | 7 wrz |
| Liczba o nadawcy, której nie ma we własnym opisie nadawcy | 63 | 9 wrz |
| Pytanie na końcu prosi o termin lub formę, na które reguły pisania nie pozwalają | 60 | 7 wrz |
| Brak zakończenia | 44 | 20 wrz |
| Follow-up powtarza wcześniejszą wiadomość poniżej wstępu | 42 | 9 wrz |
| Zdania powtarzają już wysłany e-mail | 39 | 7 wrz |
| Szkic wrócił bez jednej części | 25 | 11 wrz |
| Data, której nie potwierdza analiza firmy | 24 | 11 wrz |
| Pierwsze słowo zakazane przez reguły pisania | 22 | 9 wrz |
| Odpowiedzi nie dało się odczytać jako szkicu | 20 | 7 wrz |
| Ten sam argument co w niedawnych wiadomościach do innych firm | 11 | 20 wrz |
| Wiadomość poucza czytelnika | 8 | 9 wrz |
| Wyrażenie zakazane przez reguły pisania | 7 | 21 wrz |
| Wiadomość przeskakuje między formą „Pan/Pani” a „ty” | 5 | 25 wrz |
| Zakończenie różni się od ustawionego | 2 | 23 wrz |
| Inne | 4 | różne |
To nie jest ranking błędów modelu. Kontrole dodawano tydzień po tygodniu, co widać w ostatniej kolumnie. Kontrola, która działa od trzech tygodni, miała więcej czasu na odrzucenia niż taka, która działa od czterech dni. Błąd, dla którego nie ma kontroli, w ogóle się tu nie pojawia.
Druga ścieżka zapisuje każdą próbę pisania, od 21 sierpnia. Pokazuje, na co idzie wysiłek.
| Druga ścieżka pisania | Liczba |
|---|---|
| Próby napisania szkicu | 221 |
| Zaakceptowane szkice | 54 |
| Próby, które nie przeszły kontroli | 133 |
| Z nich najpierw zatrzymane przez kontrolę formatu | 122 |
| Z nich najpierw zatrzymane przez kontrolę stylu | 11 |
| Próby, w których zawiodło połączenie | 34 |
Według naszego własnego wyliczenia to około czterech prób na każdy zaakceptowany szkic. Większość niepowodzeń nie ma nic wspólnego z treścią. W 122 ze 133 nieudanych kontroli model nie zwrócił odpowiedzi w wymaganej formie, więc nie było żadnego szkicu do oceny.
Co mówią inne badania.
Nie znaleźliśmy badań na ten temat dotyczących e-maili sprzedażowych. Najbliższe badania sprawdzają, czy model, któremu polecono popierać twierdzenia źródłami, rzeczywiście to robi. Dwa badania to zmierzyły.
„nawet najlepsze modele w 50% przypadków nie mają pełnego oparcia w cytowanych źródłach”
Ten wynik dotyczy jednego zestawu pytań wymagających długich odpowiedzi. Drugie badanie sprawdziło cztery publiczne wyszukiwarki, które odpowiadają pełnymi zdaniami ze źródłami. Ustaliło, że średnio „zaledwie 51,5% wygenerowanych zdań ma pełne oparcie w cytowanych źródłach”.[3]
Podanie modelowi materiału źródłowego pomaga. Jedno badanie wykazało, że modele, które przed pisaniem wyszukują fragmenty tekstów, tworzą bardziej rzeczowy język niż modele, które tego nie robią.[4] Inne wykazało, że wyszukiwanie fragmentów wyraźnie ogranicza zmyślone fakty w rozmowie.[5] Oba odnotowują spadek. Żadne nie twierdzi, że problem zniknął.
Co zmieniliśmy w produkcie.
- 01Reguła, która ma znaczenie, jest kontrolą gotowego szkicu. Gdy szkic łamie regułę, oprogramowanie go odrzuca.
- 02Każde odrzucenie jest zapisywane razem z regułą, która je spowodowała. Z tego zapisu pochodzą tabele w tym tekście.
- 0320 września zakończenie przeszło z instrukcji do kontroli.
Co przemawia przeciw.
Nie potrafimy wykazać, że kontrole poprawiły wiadomości. Liczymy odrzucenia, a odrzucenie mówi tylko tyle, że pasował pewien wzorzec. Odrzucony szkic mógł być w oczach człowieka w porządku, a szkic, który przeszedł, nadal może być słaby.
Kontrola może sprawdzić tylko to, co da się sprawdzić programowo. Podział na akapity, zakończenie i zakazane słowo to łatwe sprawy. To, czy wiadomość ma znaczenie dla czytelnika, już nie. Najważniejsze cechy wiadomości pozostają radą, a według naszego własnego ustalenia rady się rozjeżdżają.
Kontrole kosztują próby. W drugiej ścieżce 221 prób należy do 98 przebiegów, a 44 z nich nigdy nie dały zaakceptowanego szkicu. Każda odrzucona próba kosztuje czas i pieniądze, a surowy zestaw kontroli może zostawić firmę bez wiadomości.
Nasz najwyraźniejszy przykład jest wąski. Liczby dotyczące zakończenia pochodzą z bardzo niewielu konfiguracji, a wszystkie odmienne szkice z jednej z nich. Początek okresu jest przybliżony: to data dodania instrukcji, nie data zapisana przy każdym szkicu. Wszystkie nasze liczby pochodzą z trzech przestrzeni roboczych i z kilku tygodni.
Zewnętrzne badania dotyczą odpowiadania na pytania i rozmów. Żadne nie badało e-maili sprzedażowych i żadne nie porównywało reguły zapisanej z regułą sprawdzaną. Traktujemy je jako najbliższe dostępne dane, nie jako dowód.
Policzyliśmy odrzucenia w zapisie każdego szkicu i tego, co się z nim stało: 527 w pierwszej ścieżce pisania, od 7 do 29 września, i 133 nieudane kontrole w drugiej, od 21 sierpnia do 29 września. Podajemy wszystkie przestrzenie robocze łącznie. Nie podajemy wskaźnika odrzuceń, bo odrzucenia to zdarzenia, a jeden szkic może zostać odrzucony więcej niż raz.
Kategorie w pierwszej tabeli powstały przez dopasowanie wzorców w tekście powodu zapisanego przy każdym odrzuceniu. W przypadku zakończenia przejrzeliśmy szkice napisane przez model w pierwszej ścieżce, w przestrzeniach roboczych, które ustawiły zakończenie. Pominęliśmy: szkice z drugiej ścieżki, szkice napisane po uruchomieniu kontroli oraz szkice sprzed 7 września, bo początek okresu jest przybliżony i nie wiemy, według jakich instrukcji powstały.
Dane są aktualne na moment pomiaru. Mierzymy ponownie w dniu publikacji.
- [1]iSyncSO. Decyzje dotyczące szkiców, odrzucenia według reguły i próby pisania, do 29 września 2026. Zmierzone 29 września 2026.nasz własny pomiarniewielka liczba przestrzeni roboczych
- [2]Gao, T., Yen, H., Yu, J. & Chen, D. (2023). Enabling large language models to generate text with citations. arXiv:2305.14627.tylko streszczenieprzeczytane na arXiv; odpowiadanie na pytania, nie e-maile sprzedażowe
- [3]Liu, N. F., Zhang, T. & Liang, P. (2023). Evaluating verifiability in generative search engines. arXiv:2304.09848.tylko streszczenieprzeczytane na arXiv; cztery wyszukiwarki, nie e-maile sprzedażowe
- [4]Lewis, P. et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. NeurIPS 2020. arXiv:2005.11401.tylko streszczenieprzeczytane na arXiv
- [5]Shuster, K., Poff, S., Chen, M., Kiela, D. & Weston, J. (2021). Retrieval augmentation reduces hallucination in conversation. arXiv:2104.07567.tylko streszczenieprzeczytane na arXiv