Behavioural Inference: Hur jag lärde mig att sluta oroa mig och älska sannolikhetssystem (Svenska (Swedish))

De flesta programfarkoster antar fortfarande att världen kommer att ge dem rena ingångar och stabila regler Tillverkning gör oftast inget av båda.

Denna skrift är den genomgående "-" -lynn bakom ett antal saker som jag har byggt. DiSE, Begränsad otydighet, CFMoM, Reduzerad RAG, StyloFlow, De tio budorden av AI-teknik, och Stylobot.

Jag kom inte dit genom att börja med en stor teori... Jag kom hit genom att titta på verktyg som jag fann intressanta och försökte lista ut vad de verkligen gjorde... sammanfattningar, .. Kodexgenerering, .. Absorbering,.. Utvinning, M SK6. Rangering.

Efter att ha byggt tillräckligt med system som den där, slutade jag tänka på dem som separata trick och började se samma arkitektur under dem.

att samla svaga signaler
behålla osäkerheten tydlig
att samla bevis över tid
Låt deterministisk politik äga den slutgiltiga handlingen

Det är grunden till vad jag menar med beteendesuppfattningssystem.

Det förklarar också varför dessa strukturer fungerar bra med koder LLMs.

Förr i denna serie:

Problemet : Dynamiska miljöer, Delaktiga bevis

De flesta produktionssystem når fortfarande en av två dåliga standardmängder

Lägg till fler regler.
Lägg till en större modell.

Båda kan arbeta ett tag.

Vad många riktiga system faktiskt har är detta

flowchart LR
    A[Messy Input] --> B[Partial Signals]
    B --> C[Conflicting Evidence]
    C --> D[Uncertain Interpretation]
    D --> E[Need to Act Anyway]

    style A stroke:#ef4444,stroke-width:2px
    style E stroke:#22c55e,stroke-width:2px

exempel:

bot-detektor
utvinning av dokument
förslagssystem
publiksegmentering
bedrägeriscoring
anpassningsoptimerad arbetsflödesruttering

I dessa områden får man sällan en avgörande fakta. Man får fragment.

Det är därför jag fortsätter att återvända till signaler

Om du vill få ett system att förbättras, måste du se vad det observerade, vad det trodde, och varför det agick.

DiSE: Arkitektur under valtryck

Det viktiga steget in DiSE var inte "med hjälp av en LLM-förändringskod Det var det här

att hantera arkitektur som något som kan dyka upp under urvaltrycket

DiSE omformar mjukvara från " bygga , skepp ♫ , ♫ patcha ♫" ♫ till ♪ " ♫ uppfatta ♫

flowchart LR
    subgraph Traditional["Traditional Software"]
        T1[Build] --> T2[Ship] --> T3[Patch]
    end

    subgraph DiSE["DiSE"]
        D1[Perceive] --> D2[Evaluate]
        D2 --> D3[Mutate]
        D3 --> D4[Select]
        D4 --> D1
    end

    style Traditional stroke:#ef4444,stroke-width:2px
    style DiSE stroke:#22c55e,stroke-width:2px

Det spelar roll eftersom man i många system inte vet i förväg

vilka detektörer som är viktiga
vilka kombinationer av bevis
vilka tröskeln överlever den faktiska trafiken
vilka dyra komponenter är värda att köra

Så systemet behöver plats att utforska

Men enbart utforskande räcker inte.

begränsad otydlighet : Håll väggarna

Begränsad otydighet är kontrolllayret som stannar upp att allting blir mush .

Reglerna är enkla:

sannolikhetskomponenter kan föreslå

flowchart TB
    I[Input] --> S[Deterministic Substrate]
    S --> P[Fuzzy Proposer]
    P --> C{Constrainer}
    C -->|Pass| O[Output]
    C -->|Partial| R[Rewrite / Hedge]
    C -->|Fail| F[Fallback]
    S -.evidence.-> C

    style S stroke:#22c55e,stroke-width:3px
    style P stroke:#f59e0b,stroke-width:3px
    style C stroke:#ef4444,stroke-width:3px

DiSE säger: "" ", utforska .", begränsad oförklarhet säger ", inuti dessa gränser, ."

Utan dessa gränser gör probabilistiska system vad de alltid gör.

överskattning
att dra
gömma osäkerhet bakom den flytande utgången
att bli belastad på platser de aldrig borde äga

Det är därför De tio budorden av AI-teknik sak. "LLMs ska inte äga stat ", | | "LLMS ska inte vara den enda orsaken till biverkningar M SK4verkningar, ", och |" Säg aldrig till en LLM att bestämma sig för ett booleiskt derivat " är inte stilbeteckningar

Samma mönster syns överallt:

i RAG, skapar modellen, men har inte egen data lagring eller filtering
i bildledningar , synmodeller föreslår captioner men beräknade fakta begränsar dem
i Bot-detektorn emiterar detektorer bevis men beslutet äger handlingen
i arbetsflöden, delar släpper ut signaler men orkestering har eskalation och biverkningar

flowchart LR
    A[DiSE<br/>Search and Selection] --> B[Constrained Fuzziness<br/>Bounded Proposal]
    B --> C[Behavioural Inference<br/>Evidence Over Time]

    style A stroke:#3b82f6,stroke-width:2px
    style B stroke:#f59e0b,stroke-width:2px
    style C stroke:#22c55e,stroke-width:2px

Lägga ihop de två idéerna och du får ett praktiskt mönster

Signaler : Den verkliga primitiva

Det här är Reduzerad RAG, StyloFlow, och signalen CFMoM alla upp i kön.

När du slutar låtsas att en modell eller en regelmotor ska göra allt signal.

Ett bra tecken är:

billigt att räkna
komponerande
tillräckligt specifik för att vara viktig
revīzijasbar
användbar under osäkerhet

Det viktigaste är att en signal är komprimerad beteende. Det är inte hela världen, det är den delen du kan bevara.

flowchart LR
    R[Raw Reality] --> X[Extraction]
    X --> S1[Signal]
    X --> S2[Evidence Pointer]
    X --> S3[Confidence]
    S1 --> A[Accumulation]
    S2 --> A
    S3 --> A
    A --> I[Inference]

    style R stroke:#64748b,stroke-width:2px
    style A stroke:#3b82f6,stroke-width:2px
    style I stroke:#22c55e,stroke-width:2px

Olika domener avger olika signaler:

bot-detektorn: tidning-entropin , otänkbara opskriftekombinationer, TLSM SK3 Http motsägelser
dokument extraktion : fältnärahet, OCR-förtroende M SK2 tabellers regelbundenhet , entitetsdänklighet
tillämpningssystem : sessiedrift, inflytande mönster, repetition collapseM SK3 omvandlingsintention
arbetsflödessystem : återförgångar, latensspetsar , cache churn M SK3 vägsdiskriminering MSC4 nedbrytning av förtroende

Signaler låter dig röra dig från " modellen tror " till " systemet har bevis

Det är rörelsen bakom Reduzerad RAG: extrahera signaler istället för att stuffa större kontextfenster Det är också StyloFlow: koordinater runt utsläppta fakta , inte osynliga komponentuppdrag

När signaler är uppenbara, kan man ställa bättre ingenjörsfrågor.

vilka signaler faktiskt driver beslut
vilka är högljudda?
var är vi på väg att eskalera för tidigt?
vilka trösklar är för konservativa?
vilka mönster som korrelerar med falska positiva
var hör en ny detektor till?

Det är skillnaden mellan att leverera en funktion och att justera en maskin

Behavioural Inference Systems

Traditionella system ser ofta ut så här

Rules -> Decisions

Behavioural inference systems ser mer ut som detta:

Signals -> Evidence accumulation -> Behaviour inference -> Deterministic action

flowchart TD
    subgraph Old["Old Shape"]
        O1[Rules] --> O2[Decision]
    end

    subgraph New["Behavioural Inference Shape"]
        N1[Signals]
        N2[Evidence Accumulation]
        N3[Inference]
        N4[Policy Action]
        N1 --> N2 --> N3 --> N4
    end

    style Old stroke:#ef4444,stroke-width:2px
    style New stroke:#22c55e,stroke-width:2px

Vad drar dessa system slutsatsen?

avsikt
avvikelse
kategori
struktur
koordinering
att dra

Vanligtvis utan att någonsin få en enda perfekt fakta

Behavior är ofta lättare att dra slutsatser än identitet.

Det är tillräckligt för att styra fram, throttle, utmaning, kluster, prioritera , eller eskalera.

Det gör också dessa system bra anpassade till kod LLMs.

explicita gränser
observationella tillståndsövergångar
mätbara utfall
lokala tunning ytor
upprepade utvärderingsloopar

Ett beteendesuppfattningssystem exponerar dessa saker naturligt.

Stylobot som ett beteende-inferanssystem

Stylobot - en del 2 är förmodligen det tydligaste konkreta exemplet än så länge

Stylobot är inte bara en hög av detektörer. Det är ett beteendemässigt gisselsystem.

flowchart LR
    R[Request] --> D[Detector Signals]
    D --> E[Evidence Aggregation]
    E --> T[Signature + Temporal Context]
    T --> I[Behaviour Inference]
    I --> P[Probability + Confidence + Risk]
    P --> A[Policy Action]
    A --> F[Response Feedback]
    F --> D

    style D stroke:#3b82f6,stroke-width:2px
    style T stroke:#8b5cf6,stroke-width:2px
    style P stroke:#f59e0b,stroke-width:2px
    style A stroke:#22c55e,stroke-width:2px

Några saker i det pipelinet kommer direkt från tidigare arbeten.

1. Detektorlayret är i form av DiSE

Ingen enskild detektor antar att vara tillräckligt. . Du har en population av specialiserade bidragande personer som emiterar bevis,

Det är inte en full självständig evolution, men det är samma instinkt. Architekturen blir raffinerad under tryck.

2. Politiska ytan är begränsad otydlighet

Stylobot håller sannolikhet och självförtroende separat, men handling är deterministisk.

Allow
Throttle
Challenge
Block

Evidens kan vara fuzzy. Kontrolloberyter kan inteM SK1

3. Signaturmodellen skapar beteendemässig minne

Istället för att reducera en Besucher till en IP eller en användare, bygger Stylobot en multi- -vektorsignatur och orsaker över tid.

Det är inte längre en enkel klassificering.

4. Inferensen och utövningen är separata

Hög sannolikhet med lågt självförtroende bör inte utlösa samma reaktion som hög sannolikheten med hög självför troende.

Systemet håller otydighet kvar tills det har tillräckligt med bevis för att rättfärdiga starkare handlingar

5. Upplevbarhet gör det anpassningsbart

Stylobot är konstruerat så att du kan undersöka nästan varje meningsfull del av beslutsbanan:

som detektorer aktiverade
vilka signaler som skickats ut
vad bevis som har samlats
vilka kännetecken som hör ihop
varför förtroendet förändrades
var den tidiga utgången skedde
vilken policygräns som utlöste handlingen

Det gör den till en anpassningsbar motor snarare än en svart låda

flowchart TD
    S1[Observable Signals] --> S2[Compare Outcomes]
    S2 --> S3[Tune Thresholds / Weights / Waves]
    S3 --> S4[Re-run on Traffic]
    S4 --> S5[Observe Drift / Improvement]
    S5 --> S1

    style S1 stroke:#3b82f6,stroke-width:2px
    style S3 stroke:#f59e0b,stroke-width:2px
    style S5 stroke:#22c55e,stroke-width:2px

Den loopen är precis där kod LLMs hjälper.

lägga till eller raffinera detektorer
föreslå kors- -signalkontroller
klang tröskeln
omstrukturera vågordning
bygga diagnoser kring falska positiva och misslyckande

Det fungerar bara för att arkitekturen är tillräckligt synlig för att stödja anpassning från början.

Varför LLM-koden spelar roll

Den användbara förändringen är inte " LLM kan skriva mjukvara nu ." Den linjen blev tråkigt nästan omedelbart

Vad som är viktigt är att koder LLM gör utforskning billigare

RAG publicerades i Maj 2020. Att få tag i det identifiserade ämnet, , att bygga in en eftersökning, , signalextraktioner, M SK3 och bevispaket är inte nya idéer.. Vad som ändrades var kostnaden för att itera på dem.. Det brukade vara dyrt att skissa ut tjugo kandidater till detektörer,,, kablarnas utvärderingsapparater och ,, att inspektera skyddet mot signaler,,, och justera tröskeln,MSC9. De flesta grupper skulle bygga ett projekt, MST10, skicka det, Mst11, och sedan leva med varenda hörn de hade klippt,MST12

Kod LLM förändrade ekonomin i den kretslet

De hjälper dig med prototypen:

detektörer
omvandlar
överenskommelser
utvärderare
Rangeringssystem
syntetiska tester
diagnostiska synpunkter
tunning harnesser

flowchart LR
    A[Human Hypothesis] --> B[Code LLM Acceleration]
    B --> C[More Candidate Signals]
    C --> D[More Evaluation]
    D --> E[Better Selection Pressure]
    E --> F[Stronger Inference System]

    style B stroke:#8b5cf6,stroke-width:2px
    style F stroke:#22c55e,stroke-width:2px

LLM behöver inte vara beslutsfattaren för att vara strategiskt användbar.

Men de tidigare reglerna gäller fortfarande

LLM har inte egen stat
LLM har inga biverkningar
LLM kan inte omdefiniera sanningen
det deterministiska substratet är

Så ja, koder LLM spelar roll. De spelar roll eftersom de snabbar upp sökandet och justering. De gör det inte för att de tar bort behovet av arkitektur.

Genom "-" -linjen genom de andra systemen

Samma form visar sig hela tiden.

Reduzerad RAG

I Reduzerad RAG, du extraherar deterministiska signaler vid ingestionen , lagrar bevis separat , och låter LLM syntetisera från ett begränsat bevispaket

Inte " ge modellen allt och hoppas på det ." extrahera först, , begränsa ytan, , och syntetisera från bevisen

lucidRAG

Där Stylobot drar slutsatser om beteende från uppgifter över tid, lucidRAG drar slutsatsen om mening från multimodella bevis : dokumentstrukturen, OCR-förtroendet M SK2 entitetsgrafer , rangordesignaler

Olika substrater . Samma form.

flowchart LR
    subgraph Stylobot["Stylobot"]
        SB1[Request Signals]
        SB2[Temporal Evidence]
        SB3[Behaviour Inference]
        SB4[Policy Action]
        SB1 --> SB2 --> SB3 --> SB4
    end

    subgraph LucidRAG["lucidRAG"]
        LR1[Content Signals]
        LR2[Evidence + Retrieval]
        LR3[Meaning Inference]
        LR4[Bounded Synthesis]
        LR1 --> LR2 --> LR3 --> LR4
    end

    style Stylobot stroke:#3b82f6,stroke-width:2px
    style LucidRAG stroke:#22c55e,stroke-width:2px

Inget av dem är egentligen en "app." De båda är inferensmotorer som arbetar över olika ingångar

CFMoM

I Begränsad Fuzzy MoM, flera sannolikhetskomponenter kan föreslå , men de kommunicerar genom utskrivna signaler och deterministisk logik bestämmer vad som överlever

Det är multi- -modellkoordination utan att ge upp kontroll.

Kontext dragning

I Begränsat Fuzzy Kontexttdragning, systemet behåller ett begränsat minne och bevarar de delar av sammanhanget som är viktiga tillräckligt länge för senare tolkning

Inferens behöver tid. Kontext dragning gör tid tillgängligt utan att låta minnet växa utan gränser.

StyloFlow

I StyloFlow, komponenter ropar inte på varandra direkt . De släpper ut signaler M SK2 och orkestern reagerar på de signalerna och deras självförtroende

Det är beteendesuppfattningar som tillämpas på arbetsflödets infrastruktur

"Behavioural inference systems " är en bättre skyddsrum än "agentiska system

Designregler

Om jag var tvungen att komprimera hela släktet till några regler

Ska inte förväxla flytande resultat med systemkunskaper.
Extrahera signaler tidigt.
Bevara osäkerhet längre än man känner sig bekväm med
Håll handlingen deterministisk även när slutsatsen är probabilistisk.
Lagera bevispunkter , inte bara sammanfattningar.
Låt komponenter föreslå
Treat time as part of the truth.
Använd LLM för att utforska utrymmet
Att bygga något som du kan tända som en motor, inte bara konfigurera som en app.

Standardversionen av dessa regler är De tio budorden av AI-teknik. Detta artikel är den arkitektoniska versionen.

flowchart LR
    A[Ten Commandments] --> B[Architectural Constraints]
    B --> C[Behavioural Inference Systems]
    C --> D[Tuneable Engines]

    style A stroke:#8b5cf6,stroke-width:2px
    style B stroke:#ef4444,stroke-width:2px
    style C stroke:#22c55e,stroke-width:2px
    style D stroke:#3b82f6,stroke-width:2px

mindmap
  root((Behavioural Inference))
    DiSE
      Search
      Mutation
      Selection
    Constrained Fuzziness
      Substrate
      Proposer
      Constrainer
    Signals
      Evidence
      Confidence
      Provenance
    Time
      Memory
      Drift
      Temporal Context
    Action
      Policy
      Thresholds
      Deterministic Boundaries

Varför det här spelar roll

De AI-system som överlever produktionen är vanligtvis inte gigantiska autonoma cirklar De är inte också oändliga högar med regler

De är system som

samla ihop smala signaler
att samla bevis över tid
bevara tvetydighet ärligt
exponera deterministiska kontrolloberyter
vara noggrann för att utvecklas

Det är en bättre ingenjörshistoria än "" ", modellen blev smartare "".

Modeller kommer att förbättras

Behavioural inference systems tar dessa begränsningar seriöst

Slutsatsen

Linjern ser uppenbart ut i efterhand:

flowchart LR
    D[DiSE<br/>Explore and Select] --> CF[Constrained Fuzziness<br/>Bound the Uncertain]
    CF --> BI[Behavioural Inference Systems<br/>Infer from Weak Signals]
    BI --> ST[Stylobot / Reduced RAG / StyloFlow<br/>Working Architectures]

    style D stroke:#3b82f6,stroke-width:2px
    style CF stroke:#f59e0b,stroke-width:2px
    style BI stroke:#22c55e,stroke-width:2px
    style ST stroke:#8b5cf6,stroke-width:2px

DiSE gav mig ett sätt att tänka på arkitektoniska sökningar Begränsad Fuzziness gav mig ett sätt att hålla sannolikhetskomponenter inom tydliga gränser. Behavioural inference systems är vad man får när idéerna tvingas överleva produktionen.

Stylobot är bara det nuvarande exemplet

När du börjar se system som bevisaccumulatorer med deterministiska handlingsoberyter, så slutar en hel del moderna programvara att se ut som , ", AI-features, " och ser ut som samma mönster i olika områden.