Målt, på maskinen som er oppgitt nedenfor

Den kjører på en boks dere allerede har, og den ringer aldri hjem.

To spørsmål avgjør om noe som helst slipper inn innenfor gjerdet. Hvor stor maskin trenger det, og hva kommer det til å gjøre med nettverket. Begge er regnestykker, så her er de som regnestykker. Alt nedenfor er målt på en Apple M4 med 10 kjerner, på Python 3.12.12. Et påstått hastighetstall uten en maskin knyttet til seg er ingen påstand.

449 sfor å kompilere et anlegg med 9 511 tagger, fra mappen med eksporter til en modell
0,6 GBdet meste minnet kompilatoren ba om, ved de samme 9 511 taggene
3,0 GBspråkmodellen vi leverer, på disk, på den samme boksen som alt annet
20 mset års simulerte målinger fra et vannnettverk i et referansedatasett, 43 tagger, kompilert

Hvor mye regnekraft

Et anlegg leverer en mappe med eksporter. Kompilatoren leser den, finner ut hva hver tag er, hva den er koblet til og hva som rett og slett er feil, og skriver en modell. Nedenfor ser du hvor lang tid det tar etter hvert som anlegget blir større, målt på anlegg fra 300 til 9 511 tagger, med hver størrelse kjørt i sin egen prosess slik at minnetallet er den størrelsens eget.

501002005001k2k5k10k0.010.020.050.10.20.5125102050100200500tagger i anleggetsekunder å kompilereC-TownHAImålt stigning n^2,232

Logaritmiske akser, så en rett linje er en potenslov. Den målte stigningen er n^2,232, som er verre enn lineært og ærlig om duplikatsøket: det sammenligner serier mot hverandre. Ved 9 511 tagger tar en hel kompilering 449 sekunder. De to hule punktene er publiserte datasett, ikke vår egen simulator: vannnettverket C-Town med 43 tagger og testriggen HAI med 86 tagger, og begge er ferdige på godt under en tidels sekund. Målingene stopper der fordi det å bygge et syntetisk anlegg dobbelt så stort krever mer minne enn maskinen har, og en tidsmåling tatt mens maskinen swapper, måler disken.

5001k2k5k10k2050100200500tagger i anleggetmegabyte kompilatoren ber ommålt stigning n^1,027

Hva kompilatoren selv ber om, målt med en allokeringssporer i en egen kjøring, fordi sporeren mer enn dobler kjøretiden og ville ha ødelagt tidsmålingen over. Det vokser som n^1,027, altså litt langsommere enn anlegget, og topper seg på 0,60 GB på et anlegg med 9 511 tagger. Det får plass i den ledige halvdelen av en vanlig industri-PC.

Den vil ikke ha kjernene dine

Låst til én kjerne, med alle trådbiblioteker holdt til én tråd, tar den samme kompileringen 2,80 s mot 2,81 s uten låsing. Forskjellen ligger innenfor støyen i målingen, så den ærlige lesningen er at den ikke trenger mer enn én kjerne i det hele tatt. Det er det nyttige tallet, for ingen kjøper en maskin for vår skyld. Det vi trenger, må få plass ved siden av det den boksen allerede gjør.

9%7%79%lese klokka 9 %finne duplikater 0 %lese navnene 5 %beskrive verdiene 7 %alt annet 79 %

Hvor sekundene faktisk går, fra en profilering og ikke en gjetning. Tid brukt inne i numpy er ført opp på den av våre egne funksjoner som ba om den, for å vite at en femtedel av en kompilering er ndarray.partition sier deg ingenting, mens å vite at den gikk med til å beskrive verdiene sier deg hvor du skal lete. Å finne duplikater er den største andelen og grunnen til at kurven over bøyer seg: det sammenligner serier mot hverandre, så det vokser raskere enn anlegget gjør.

Delen som er en språkmodell

Ett steg leser papirene: en instrumentindeks, et datablad, en manual på 50 sider. Det er det eneste stedet en språkmodell kjører, den kjører på den samme boksen, og den er liten. Ingenting sendes noe sted, og den får aldri brødteksten i et dokument, bare overskrifter og strukturerte felt. Hvert tall den produserer, sjekkes mot fakta datalaget har regnet ut, før det slippes ut.

1252050100gigabyte modell på disksekunder å lese papirenegemma3:1bqwen3.5:0.8bsmollm2:1.7bqwen2.5:3bllama3.2:3bgranite4:3bgranite4.2:3bphi4-mini:3.8bnemotron-3-nano:4bministral-3:3bgranite4:1bgemma3:4bhf.co/NbAiLab/borealis-open-4b-gguf:Q4_K_Mmistral:7bolmo2:7bgranite4.2:8bministral-3:8b

Lokale modeller, målt mens de leser de samme papirene. Vi leverer ministral-3:3b på 2,95 GB, laget av Mistral AI i Frankrike under Apache 2.0. Den leser hele settet på 80 sekunder og formulerer et funn på 8,6.

Hvor modellen vi leverer kommer fra

Vi leverer ministral-3:3b, laget av Mistral AI i Frankrike under Apache 2.0. Det er også den beste leseren vi har målt på denne jobben, og det har ikke alltid vært sant og fortjener å sies rett ut: en tidligere versjon av denne siden hevdet at det å levere en modell fra et land kjøperne våre er komfortable med, kostet oss reell nøyaktighet, og publiserte hvor stor den kostnaden var. Det var ikke sant. Sammenligningen bak satte den beste kinesiske modellen opp mot en av de svakeste modellene vi hadde, og avveiningen var en bieffekt av det valget, ikke et faktum om hvor modeller lages. Alle modellene vi har målt, står fortsatt i tabellen over, også dem vi ikke valgte.

Hva det ville ha kostet å gjøre dette i en sky

Ikke en konkurrents faktura, den kan vi ikke se. Et volum, og det er multiplikasjon. Et anlegg med 1 469 tagger som samples hvert sekund, er 1 112 GB i året over linja, jevne 0,28 Mbit i sekundet som aldri stopper. Samplet én gang i minuttet i stedet er det 18 GB, som er tallet de fleste egentlig har i tankene når de sier at dette er billig. Et anlegg med 20 000 tagger samplet hvert sekund er 15,1 TB i året. Innenfor gjerdet er alle disse null, og sikkerhetsvurderingen har én kanal mindre å krangle om.

Hvilke arbeidsoppgaver dette erstatter

Sju av dem, hver med målingen som underbygger den og den delen vi ikke gjør. To av dem er ting vi i dag er dårlige på, og de står i lista like store som resten.

Finne ut hva hver tag er

En integrator eller en automasjonsingeniør åpner tegningene og sløyfeindeksen og skriver ned, tag for tag, hva den måler og hva den er koblet til. Dette er byggingen av utstyrsmodellen, og det er steget uten noe verktøy bak seg.

det den gjør

På et vannnettverk ingen her har konstruert: 39 av 43 tagger plassert, 93 % av størrelsene og 100 % av maskinene riktige sammenlignet med nettverkets egen modell.

det den ikke gjør

Skrive connectoren for en sektor ingen har skrevet en for. Uten vann-connector plasserer den 0 av 43, og det er den ærlige formen på dette.

fikk 0,866 mot 0,526 for navnematching, kriteriet bestått

Finne ut hvordan anlegget henger sammen

Lese P&ID-ene og reguleringsbeskrivelsen for å finne ut hvilken pumpe som forsyner hvilken tank, hvilken likeretter som betjener hvilken linje. Der tegningene er utdaterte: spørre den som har vært der lengst.

det den gjør

6 av 6 tanker koblet til pumpen som fyller dem, på data holdt utenfor, bare ut fra verdiene. Nettverkets egen styringslogikk er enig i hver eneste én.

det den ikke gjør

Skille en pumpe som fyller en tank fra en pumpe som bare står oppstrøms for den. T6 ble navngitt og burde ha blitt avvist.

Finne punktene som er døde ute i felt

Stort sett ingen. En tag som har vist det samme tallet i et år, står fortsatt i taglista, i trenden og i rapporten, og blir oppdaget når noen til slutt går og ser på instrumentet.

det den gjør

Sju av de 43 vanntaggene flagget som døde eller i ytterkant av måleområdet, inkludert både mengde og status for begge reservepumpene, bare ut fra verdiene.

det den ikke gjør

Si hvorfor den er død. Det er en jobb for en person med multimeter.

Finne to navn på én sensor

Oppdages når to rapporter er uenige, eller aldri.

det den gjør

Målt på forsiden, og dette er ett av de to kriteriene som ikke ble nådd.

det den ikke gjør

Nå terskelen som ble satt for den før kjøringen.

fikk 0,867 mot 0,000 for navnematching, kriteriet ikke nådd

Gjøre rå tellerverdier om til ingeniørverdier igjen

En person kjenner igjen 0 til 27 648 som et analogt Siemens-ord eller 4 til 20 som en strømsløyfe, og bruker skaleringen fra databladet.

det den gjør

Målt på forsiden, og dette er det andre kriteriet som ikke ble nådd.

det den ikke gjør

Finne skalaen for et instrument som har flatet ut, eller for et punkt uten noe søsken noe sted i anlegget. Omtrent halvparten av bommene kan ikke løses av noe som helst.

fikk 0,671 mot 0,000 for navnematching, kriteriet ikke nådd

Sette alle kilder på én klokke

Å oppdage midt i en granskning at historian går i lokal tid uten offset og SCADA i UTC, og at én time i mars ikke finnes i den ene av dem.

det den gjør

Målt på forsiden, og det ble bestått.

det den ikke gjør

Rette en klokke som går feil, ikke bare er skrevet annerledes.

fikk 1,000 mot 0,378 for navnematching, kriteriet bestått

Si hvilke punkter som ikke kan plasseres, og hvorfor

Ingen får dette som oppgave. Et verktøy som ikke kan plassere et punkt, plasserer det som regel likevel.

det den gjør

39 av 86 avvist på HAI-riggen og 1 av 43 på vannnettverket, hver med begrunnelsen skrevet ved siden av.

det den ikke gjør

Gjøre den lista kortere. Den hører til første uke av installasjonen, den er ikke en feil.

Hvordan vi vet noe av dette

Alt over er tall, og et tall uten et intervall under seg kan ikke ta feil, og da er det en anekdote med desimaltegn. Så kriteriene på forsiden ble kjørt på nytt på femti anlegg holdt utenfor i stedet for fem, med bootstrap-intervaller, en paret test mot baseline og en nullhypotese under vannresultatet. To av de resultatene står nedenfor; alle fire står i auge_plant/P19_REPORT.md, også det som feilet, og hvorfor måten jeg formulerte det på gjorde feil til det eneste mulige utfallet.

Å avvise er bare nyttig hvis den avviser de riktige

En leverandør som nekter å svare, er bare verdt noe hvis punktene den avviser, er de den ville ha tatt feil på. Målt: 0,140 på aluminiumsverket over 14 844 tagger, 0,042 på transformatorstasjonen over 12 802 tagger, mot en grense på 0,5 satt før kjøringen. Enkelt sagt: når denne kompilatoren sier den er usikker, er den nesten alltid usikker på nettopp de taggene den har tatt feil på. En avvisningsliste på 37 tagger er ikke 37 tilfeldige tagger, den er nær de 37 et perfekt orakel ville ha valgt.

0%25%50%75%100%0%3%6%9%12%hvor stor del av anlegget den må svare forandel av svarene som er feilAluminiumsverkTransformatorstasjonAluminiumsverk, overskudd 0,14 Transformatorstasjon, overskudd 0,04

Tving kompilatoren til å svare for mer av anlegget, og den må begynne å ta med tagger den er mindre sikker på. Denne kurven viser hvor feil de besvarte taggene blir etter hvert som dekningen øker. Et system der selvtilliten ikke betydde noe, ville gitt en flat kurve. Overskuddstallet viser hvor arealet under kurven ligger mellom en perfekt rangering av kompilatorens egne feil og ingen rangering i det hele tatt: 0 er perfekt, 1 er ubrukelig.

Vi bygde en automatisk vurderer, og så kastet vi den

Forklaringene trenger en vurderer, og den eneste som kan kjøre innenfor et gjerde, er en liten lokal modell. Så vi bygde en, ødela 30 ekte forklaringer på fire kjente måter, og ba tre modeller fra tre produsenter om å fange dem. qwen3.5:0.8b fanget nesten alle ødeleggelsene og så ut som den klare vinneren. Den underkjente også 97 % av de ærlige forklaringene: den oppdaget ingenting, den svarte ja på alt, og en vurderer som roper ulv, fanger hver eneste ulv. Den reelle evnen til å skille en ærlig forklaring fra en ødelagt er 0,52, altså myntkast. Den beste av de tre, granite4:1b, når 0,67, og de to dommerne som er mest enige, er enige om 80 % av forklaringene, noe som høres respektabelt ut helt til tilfeldighetene trekkes fra og tallet blir en Cohens kappa på 0,13. Så den leveres ikke. En vurderer som har rett to av tre ganger, hører ikke hjemme mellom et anlegg og en påstand om utstyret der. Den blir liggende i repositoriet som en regresjonstest, og det er en annen og mye mindre jobb. Hele gjennomgangen, inkludert de to feilene som viste seg å ligge i vårt eget testoppsett og ikke i modellene, står i auge_plant/P21_REPORT.md.

Er forklaringene kausale, eller bare sanne

Forklaringene er stort sett tilstrekkelige (91 %, 78 %) og stort sett ikke nødvendige (32 %, 22 %). Det kompilatoren viser til, er virkelig nok til å komme fram til svaret; svaret ville også ha blitt nådd uten det, fordi noe annet bærer den samme informasjonen. Det er ikke løgn, og det er ikke pynt. Det er en sann beskrivelse av én vei til svaret, presentert som om det var veien. Høyst 7 % av kanalene som faktisk betyr noe, blir ikke nevnt, så forklaringene overdriver eksklusiviteten, ikke innholdet. Rettelsen hører hjemme i den delen som skriver begrunnelsen, ikke i plasseringslogikken: si hvilken vei som ble tatt, eller si at flere er enige.

transformatorstasjonaluminiumsverk00.20.50.70.9andel av forklaringene i utvalgetnødvendigtilstrekkeligbegge, en fullstendig forklaring

Utforskende og ikke forhåndsregistrert, så ingenting her blir bestått eller underkjent. Slett alt en forklaring viser til, og kompiler på nytt: flytter ikke svaret seg, er det ikke den siterte begrunnelsen som ga det. Slett så alt den ikke viser til: overlever svaret, var det siterte nok alene. Denne testen fant to feil i seg selv før den fant noe om kompilatoren, og begge står i P20_REPORT.md.

Hvor mange timer det utgjør

Dette er tallet hver leverandør i denne kategorien finner på, så her er den ærlige versjonen av det. Hvor lang tid en person bruker per tag, er ikke noe vi kan måle, så det er aksen og ikke svaret. Det som er målt, er andelen: 86,6 % av taggene plassert med maskin, størrelse og enhet riktig, på femti anlegg kompilatoren aldri hadde sett, mot 52,6 % for navnematching, som er det en god integrator gjør for hånd med et regneark.

0.512510200122.4244.8367.3489.7minutter en person bruker per tagtimer for ett anleggfor hånd, alt sammenAuge fjernernavnematching fjerner

Ett anlegg med 1 469 tagger. Velg ditt eget antall minutter per tag på den nederste aksen. Den midterste søylen er det den målte andelen fjerner, og søylen til høyre er det et regneark ville ha fjernet uansett, så avstanden mellom dem er den eneste delen som er vår. Resten er taggene kompilatoren avviser i stedet for å gjette på, og de blir liggende på noens pult.

Spart tid, og hvor vi ikke setter et tall

Alle leverandører i denne kategorien lover spart tid. Vår holdes til én regel: en besparelse estimeres bare der et publisert tall for hvor lang tid jobben tar og en måling av hvor mye av den vi gjør, møtes. På to ekte anlegg plasserte vi 175 av 212 tagger med riktig størrelse, og avviste resten med en begrunnelse. Ingen har publisert et tall for minutter per tag som ikke kommer fra en leverandør (“A 500-tag database that takes two days takes 30 minutes” (Tatsoft, leverandørens påstand)), så minuttene står som et spenn (Tatsofts tall blir omtrent to per tag), og en stikkprøve på 50 tagger er trukket fra.

taggerminutter per tagtimer for håndtimer spart
1 00011713
1 00023326
1 00058365
1 00010167129
10 0001167137
10 0002333274
10 0005833684
10 000101 6671 368

Jobbene under tar ekte tid, og console hjelper med hver av dem, men ingen har tatt tiden med og uten den, så timene vises som det som står på spill, ikke som spart:

Det som ville gjort disse om til estimater, er et tidtatt forsøk i en pilot: de samme menneskene, de samme jobbene, to uker uten console og to med, og minuttene ført av dem, ikke av oss.