Hvad der faktisk sker, fra du lægger et manuskript ind i Bethaniel, til du får et med rettelser tilbage — gennemgangene, rækkefølgen de kører i, og hvorfor hver enkelt er der.
Seks afsnit, så detaljerne.
Trinnene kører i rækkefølge, og rækkefølgen bærer information: opdeling kan ikke ske før kapitelgenkendelse, og revieweren kan ikke bedømme en rettelse, der endnu ikke er foreslået.
DOCX, EPUB, PDF, Markdown eller ren tekst. DOCX kommer ind via mammoth; EPUB og PDF har deres egne læsere. PDF-læseren genopbygger afsnit, fremhævning og overskrifter ud fra, hvor tegnene fysisk sidder på siden — og afviser scannede dokumenter blankt frem for at lade som om, den læser dem.
Alt bliver til Markdown internt. Det ene interne format er det, der gør det muligt at skrive en rettelse fundet i kapitel 12 tilbage i den oprindelige DOCX med formateringen intakt.
Overskrifter genkendes, og manuskriptet deles op i redigerbare enheder. Afsnit under halvtreds ord — titelsider, en løsrevet overskrift, en dedikation — foldes ind i det kapitel, de hører til, frem for at blive deres eget enlinjes "kapitel", og det er det, der får et jobs fremdriftsliste til at ligne en bogs indholdsfortegnelse frem for en parsers output.
Scenebrudsmarkører genkendes og normaliseres samtidig, så et manuskript, der bruger *** ét sted og # et andet, kommer ud ensartet.
Hvert kapitel deles i bidder på cirka 2.500 ord, kun ved afsnitsgrænser, og med det sidste afsnit i én bid gentaget øverst i den næste. Overlappet er det, der forhindrer, at en rettelse ved en bid-grænse laves uden sammenhæng. Kapitelgrænser nulstiller overlappet — slutningen af kapitel 4 er ikke sammenhæng for starten af kapitel 5.
Før modellen ser noget som helst, kører de regelbaserede kontroller over bidden. De er hurtige, de er ens hver gang, og de finder aldrig på et ord. Det, de finder, ryger ind i rettelsessættet og ind i modellens prompt som hints — for en stavekontrol ved langt mere pålideligt, at et ord er forkert, end den ved, hvad ordet skulle have været, og modellen, der læser sætningen, er bedre til den anden del.
Bidden, de deterministiske hints, din stilguide, hvis du har givet en, og de indstillinger, du har valgt, samles til en prompt. Modellen returnerer foreslåede rettelser som par af original/rettet, ikke som en omskrevet bid — så en ændring altid kan lokaliseres, vises og afvises enkeltvis.
Ved siden af læser en separat gennemgang den samme bid efter én ting alene: et ord, der er faldet ud af en sætning. Den er beskrevet nedenfor under Manglende ord.
En anden prompt sender hver foreslået rettelse tilbage til modellen i rollen som skeptisk andenlæser: er dette faktisk en fejl, og er dette faktisk rettelsen? Hver får en tillidsscore fra 1 til 5. Alt under tærsklen markeres frem for at blive smidt væk, så et korrekt forslag, revieweren ikke brød sig om, er markeret til din opmærksomhed i stedet for forsvundet. Et fund fra ordbogen eller grammatikserveren tilsidesættes aldrig på den måde — en ordbog er ikke en holdning, en model får lov at stemme ned.
Revieweren kører parallelt med den næste bids redaktør, så den ekstra gennemgang koster langt mindre tid, end den ser ud til.
Hver overlevende rettelse skal forbi et sæt mekaniske vagter, før den må røre teksten. De beskrives nedenfor; den korteste måde at sige det på er, at en rettelse ikke må gøre manuskriptet værre på en måde, en menneskelig korrekturlæser aldrig ville.
Du får en diff på ordniveau, rettelse for rettelse, med begrundelsen hæftet på og tillidsscoren synlig. Acceptér, afvis, eller acceptér alle. Eksportér til Markdown, DOCX eller EPUB — og for en DOCX-import tilbage i det oprindelige dokument med dets egne typografier, frem for i et nygenereret.
Den centrale designbeslutning er, at de regelbaserede og de modelbaserede kontroller holdes som adskilte kilder, køres over den samme tekst og flettes bagefter. Ingen af dem kan gøre den andens arbejde.
a/an, dobbelte ord, manglende apostroffer, "PIN number"De hallucinerer aldrig. De kan heller ikke se, at their skulle have været there, for begge er rigtige ord.
Den læser sætningen. Den vil også af og til foreslå noget selvsikkert forkert, og det er derfor, intet af det, den siger, anvendes ugennemset.
Forhåndsgodkendelse på tværs af kilder. Når en deterministisk kontrol og modellen uafhængigt af hinanden laver den samme rettelse, anvendes den automatisk uden at behøve reviewerens velsignelse. En regel og en sprogmodel tager fejl på helt forskellige måder, så at de er enige, er et langt stærkere signal, end at nogen af dem er selvsikker alene.
Ægte Hunspell, kompileret til WebAssembly, som læser de almindelige .aff/.dic-ordbogspar uændret. Den markerer hvert ord i bidden, der ikke står i ordbogen, uden loft pr. bid, mens den beskytter navne fra din stilguide og ord, der opfører sig som egennavne.
At bruge den rigtige motor frem for en efterligning er det, der får de sammensættende sprog til at fungere. Dansk og tysk danner nye ord ved at sætte gamle sammen — rådhusarkivet, Werkstattfenster — og en roman på et af sprogene er fuld af sammensætninger, der ikke står i nogen ordbog. Hunspell sætter dem sammen af deres dele. En kontrol uden det maskineri læser hver eneste af dem som en stavefejl, hvilket i praksis betyder, at forfatteren slår stavekontrollen fra.
Ord, ordbogen aldrig kan fange, fordi begge stavemåder er rigtige: their/there, dansk nogen/nogle, tysk das/dass, spansk si/sí. Bethaniel har et kurateret sæt pr. sprog og lægger de relevante ind i modellens prompt — men kun når begge medlemmer af et par faktisk optræder nær hinanden i bidden. En regel, der slog ud på hver forekomst af their, ville oversvømme manuskriptet; et hint, der kun slår ud, hvor forveksling er mulig, koster næsten ingenting.
“They expect us to look each other in the same place.” Hvert ord, der står der, er stavet rigtigt, så ingen ordbog ser det for, der er faldet ud — og en forfatter læser lige hen over det, fordi hjernen selv sætter ordet ind. At bede redaktørmodellen om også at lede efter dem virkede ikke: den fandt ikke flere af dem og begyndte at overse fejl, den før havde fanget.
Så det er en gennemgang for sig, i tre trin. Modellen læser bidden i små portioner efter udeladte ord og intet andet. En regel beholder derefter kun et forslag, der indsætter præcis ét lille ord — en præposition, en artikel, et pronomen, et hjælpeverbum — mellem to ord, der allerede står der, hvilket smider næsten alt, hvad modellen foreslår, væk. Til sidst får modellen sætningen vist to gange, som den står og med ordet, og bliver spurgt, hvilken der er grammatisk. Det, der overlever, vises for dig som ethvert andet fund og tæller som en blokerende fejl i den afsluttende gennemlæsning. Det kører på alle fem sprog; performance-siden viser hvor godt, pr. sprog og pr. motor.
En lokal LanguageTool-server, der kører offline på din maskine, på dens strengere picky-regelniveau. De udgivne installationsfiler indeholder både LanguageTool og en passende Java-runtime, så der er intet at installere; mangler den, gør den ingenting frem for at få jobbet til at fejle.
En kort liste af LanguageTool-regler er slået permanent fra, hver med den måling, der satte den der. Tærsklen er bevidst hård — nul rigtige fejl fundet, mindst én opfundet — fordi en LanguageTool-rettelse springer revieweren over, så intet længere nede holder en regel tilbage, der slår forkert ud. Én spansk regel, som omskrev hvert lige anførselstegn til et vinklet, slog ud 248 gange på tværs af testkorpusset og havde ikke én eneste gang ramt en rigtig fejl.
Deterministiske kontroller kun for engelsk: a versus an, manglende apostroffer i sammentrækninger, dobbelte ord, overflødige akronymer og mellemrum mellem sætninger. De andre sprog springer denne gennemgang helt over frem for at få engelske regler anvendt på sig.
Reparation af anførselstegn er deterministisk, fordi forskellen mellem et begyndende og et afsluttende tegn er noget, en model læser hen over, og en regel aldrig gør. Den ejer anførselstegnene fuldstændigt, og derfor må grammatikserveren ikke røre dem. Normalisering af sprogvariant — britisk til amerikansk stavning eller omvendt — kører på samme måde, når du har angivet, hvilken manuskriptet er skrevet i.
Nogle ting, der ligner fejl, er valg. Bethaniels regel er, at hvor en konvention for alvor er omstridt, angiver forfatteren den, og først derefter håndhæves den — for en kontrol, der gætter, tager fejl cirka halvdelen af tiden og er højlydt uanset hvad.
| Sprog | Valget | Standard |
|---|---|---|
| Engelsk | Oxford-komma | Til |
| Engelsk | Komma efter indledende led | Fra — "Finally she turned" lades stå, som det er skrevet |
| Engelsk | Britisk eller amerikansk stavning | Amerikansk |
| Dansk | Grammatisk komma eller nyt komma | Grammatisk |
| Spansk | RAE's kommakonventioner | Anvendt |
Det danske er det klareste tilfælde. Dansk har to konkurrerende kommasystemer, begge godkendt af Retskrivningsordbogen og indbyrdes modstridende: grammatisk komma sætter komma foran hver ledsætning, nyt komma gør det for det meste ikke. At håndhæve et af dem uden at spørge er forkert for halvdelen af alle danske manuskripter. Dansk kommagenkendelse blev med vilje holdt svag, indtil denne kontakt fandtes.
Mellem revieweren og din skærm sidder et sæt mekaniske vagter. De findes, fordi hver enkelt beskriver noget, der faktisk skete under udviklingen, og hver enkelt er nu en test, der fejler, hvis det sker igen.
.,, intet dobbelt punktum. Og når modellen omskriver et afsnits sidste sætning og taber dets afsluttende punktum — hvilket den gør — sættes punktummet tilbage uden at kassere den berettigede rettelse, der fulgte med.Vagterne gælder for hver kilde, også de deterministiske. En regelbaseret rettelse er ikke privilegeret, bare fordi en regel lavede den.
Korrektur er én af fire gennemgange. De deler hele pipelinen ovenfor — opdeling, review, vagterne, eksportvejen — og adskiller sig i prompten og i det, de producerer.
| Gennemgang | Hvad den gør |
|---|---|
| Korrektur | Stavning, tegnsætning, grammatik, store bogstaver, gentagne ord. Det mekaniske lag. |
| Stilredigering | Stil, rytme, formulering, gentagelser. Forslag frem for rettelser — der findes ikke noget, der hedder et objektivt manglende komma her. |
| Oversættelse | Hele teksten til ethvert målsprog, derefter en poleringsgennemgang på målsproget, derefter en afsnit-for-afsnit gennemgang af flydende sprog, som polerer alt, der er bedømt som forvansket, igen. Kun i skyen — se nedenfor. |
| Analyse | Personkatalog, stedkatalog og tidslinje, flettet på tværs af hvert kapitel, plus et automatisk genereret prosaresumé og en bagsidetekst. |
Vælges korrektur og stilredigering sammen, flettes de til én gennemgang over hvert kapitel frem for at køre manuskriptet igennem to gange. Vælges flere analysegennemgange, sker det samme.
Pipelinen er identisk i alle fire tilfælde. Det eneste, der ændrer sig, er, hvor inferensen sker, og om teksten forlader din maskine.
| Model | Kører på | Teksten bliver lokalt |
|---|---|---|
| Local Betty — Qwen3.5 4B | Din maskine · ~3 GB, 8 GB ledig RAM | Ja |
| Custom Betty | Din maskine · enhver GGUF, du selv leverer | Ja |
| External Betty | Din egen API-nøgle, din valgte udbyder | Nej |
| Betty in the Cloud — hostet, EU | Bethaniels hostede tjeneste, betalt pr. job | Nej |
Local Betty er standarden, og appen kan bruges fuldt ud uden nogensinde at have rørt netværket. Før den er hentet, fortæller Kør-knappen, hvor lang tid en roman bør tage på den maskine, den står på. Cloud-mulighederne findes til maskiner, der ikke kan køre en 4B-model i et brugbart tempo — de tilvælges pr. job, og vilkårene siger ligeud, hvad der sker med teksten.
Den ene undtagelse er oversættelse. Den lokale model blev målt på det og var ikke god nok — en svag oversættelse er flydende, selvsikker og forkert, og en forfatter, der ikke læser begge sprog, kan ikke se det — så appen afviser et oversættelsesjob på en lokal model. Oversættelse kører kun på Betty i skyen, på en langt større model end den, redigeringsgennemgangene bruger, eller gennem din egen nøgle.
Den tilbød engang to til fire redaktøragenter pr. bid og flere reviewere, ud fra teorien om, at uafhængige vurderinger kunne samles. De blev målt, og der var ingen uafhængige vurderinger at samle.
Rettelser afkodes grådigt — modellen bliver bedt om det ene mest sandsynlige svar frem for en stikprøve, for at finde en fejl er et spørgsmål med et rigtigt svar og ikke et kreativt. Stil det samme spørgsmål på den måde to gange, og du får det samme svar to gange. Hver ekstra agent genlæste den samme bid med den samme prompt og returnerede en byte-identisk liste, som fletningen så foldede tilbage til én.
Målt på tværs af fire sprog og tre modeller: én redaktør og to gav identisk output i hvert eneste tilfælde — de samme rettelser, de samme forbiere, de samme markeringer på fejlfri tekst — og én var 15–20 % hurtigere. Så mulighederne blev fjernet frem for at blive stående som en indstilling, der koster dig tid og energi for ingenting. Den ene undtagelse er bevaret: når du leverer en stilguide, kører en anden agent med en for alvor anderledes prompt, og den kan være uenig.
Jeg synes, Betty er god. Jeg synes også, det er vigtigt at være tydelig om, hvor hun hjælper, hvor hun ikke gør, og hvad du siger ja til.
Betty er et værktøj, ikke en fagperson. Hun er et skrivehjælpemiddel — ikke en uddannet korrekturlæser, redaktør eller juridisk rådgiver. Hendes forslag er udgangspunkter, ikke domme. Den endelige afgørelse om hver eneste sætning er din.
Hun vil nogle gange tage fejl. Sprog afhænger af sammenhængen på måder, der er svære for alvor. Betty vil af og til markere noget, der var i orden, overse noget, der ikke var, eller foreslå en ændring, der gør tingene værre. Betragt hendes forslag som en second opinion, ikke en endelig redigering.
Lokalt som udgangspunkt; skyen kun hvis du beder om det. Overladt til sig selv behandler Betty tekst udelukkende på din egen hardware, og intet sendes videre. Undtagelsen er et cloud-job — tilvalgt job for job og betalt, før det kører: det afsnit, der redigeres, sendes krypteret til europæisk infrastruktur, som ikke skriver det til nogen database og ingen log. Uanset hvad beholder du alle rettigheder til dit manuskript og til det redigerede resultat, og intet af det, du skriver, bruges til at træne nogen model. Cloud-vilkårene siger rent ud, hvad der sker med teksten.
At køre lokalt kræver en kapabel maskine. Den lokale model har brug for 8 GB ledig RAM, mens hun kører — i praksis en maskine med 12 GB eller mere, eller 8 GB med alle andre programmer lukket — og cirka 3 GB ledig diskplads. Hastigheden afhænger af grafikken: en Mac med Apple Silicon eller et NVIDIA-kort med 8 GB grafikhukommelse redigerer en roman på cirka tre timer eller mindre, mens det på processoren alene tager det meste af en dag. Forventede køretider efter maskine. Hun udfører reelt regnearbejde — der findes ingen letvægtsudgave. Skyen er til præcis de maskiner: modellen kører i datacentret, og der skal ikke være plads til andet end selve appen på din.
Understøttede platforme. Betty fås i øjeblikket til macOS 12 eller nyere, Windows 10 (64-bit) eller nyere og Linux-systemer med glibc 2.31 eller nyere. Andre platforme understøttes ikke på nuværende tidspunkt.
Betty er gratis og har tænkt sig at blive ved med at være det. At køre Betty på din egen maskine har ingen brugsgrænse, intet abonnement og ingen prøveperiode, og det er produktet. Der er én betalt mulighed — en cloud-tjeneste, der betales pr. job, til maskiner, der ikke kan køre en model lokalt: 39 kr. pr. 100.000 ord for en redigering eller en slutgennemlæsning, 89 kr. for en oversættelse. Den er aldrig nødvendig for at bruge Betty. Hvis noget ved den gratis udgave ændrer sig, bliver det annonceret her, før det træder i kraft, med varsel nok til at træffe en overvejet beslutning.
Ingen garantier. Betty leveres, som hun er. Jeg giver ingen garantier for nøjagtighed, egnethed til et bestemt formål eller uafbrudt tilgængelighed. Brug hende efter eget skøn.
Hver påstand på denne side med et tal på stammer fra en benchmark, som enhver med repositoriet kan køre igen. Parrede tekster — en fejlfri tekst og den samme tekst med omkring hundrede fejl plantet på kendte tegnpositioner — køres gennem den rigtige pipeline, og det, der kommer tilbage, bedømmes mod det, der blev plantet.
Fejlteksterne er konstruerede, ikke annoterede: en generator planter hver fejl ud fra en plan pr. sprog og afviser enhver ændring, der ikke giver præcis ét stykke af den tilsigtede slags, så facitlisten ikke kan drive væk fra teksten. Gennemgangene bedømmes forskelligt, fordi de fejler forskelligt — recall og præcision mod de plantede fejl for korrektur, og chrF mod menneskelige referenceoversættelser plus kontrol af længdeforhold og uoversatte ord for oversættelse.
Resultaterne, pr. sprog, med forbierne opdelt efter, hvilken slags fejl der blev overset, findes på performancesiden.