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:

• Matlagning med DiSE (Teil | 4): | Byggnader som lär sig
• begränsad otydlighet : Ett kontrollsystemsmönster för sannolikhetskomponenter
• Begränsade fuzzy MoM: Signalkontrakt över agent Chatter
• Begränsat Fuzzy Kontexttdragning
• Reduzerad RAG: Stopp att fylla i kontexten Windows och börja extrahera signaler
• StyloFlow: Begränsade fuzzysignaler -drivna arbetsflöden
• De tio budorden av AI-teknik
• StyloBot-delen 2: Handtekeningsrör och arkitektur

Problemet : Dynamiska miljöer, Delaktiga bevis

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

1. Lägg till fler regler.
2. 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

1. Ska inte förväxla flytande resultat med systemkunskaper.
2. Extrahera signaler tidigt.
3. Bevara osäkerhet längre än man känner sig bekväm med
4. Håll handlingen deterministisk även när slutsatsen är probabilistisk.
5. Lagera bevispunkter , inte bara sammanfattningar.
6. Låt komponenter föreslå
7. Treat time as part of the truth.
8. Använd LLM för att utforska utrymmet
9. 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.