Pienet ja paikalliset LLM:t on usein kehystetty halvaksi vaihtoehdoksi rajamalleille. Tuo kehystys on väärä. Ne eivät ole halventunut versio samasta asiasta. Ne ovat erilainen arkkitehtuurivalinta, joka on valittu valvonta, ennustettavuus, ja Selviytyvät vikatilat.

Olen yhtä syyllinen kuin kuka tahansa "ne ovat vapaita" -kerronnan työntämisestä... ikään kuin se olisi ainoa ratkaiseva tekijä. millaisia kauppoja teet.

Pienen mallin käyttö OllamaLM Studio, ONNX-ajoaika, tai vastaava ei ole (vain) rahan säästämistä. Kyse on valitsemisesta jossa ei-determinismi saa olla olemassa.

Todellinen ero: epäonnistumistilat

Suuret rajamallit ovat laajempia ja sujuvampia. Ne tiivistävät ihmisen ilmaisemaa logiikkaa, ulottuvat useammille alueille ja tuottavat vakuuttavampia perustelujä. vaarallisempi järjestelmissä, jotka vaativat takuita.

Rajamalleissa on järkeä, kun tarvitaan leveyttä ja lähdöt ovat suunnittelultaan neuvoa-antavia - luovaa muotoilua, avointa etsintää tai synteesiä tuntemattomilla alueilla. Mutta se ei ole useimpia tuotantojärjestelmiä.

Heidän epäonnistumisensa ovat semanttinen eikä rakenteellinen. Tämä on luokkavirhe: Probabilistisen komponentin kohteleminen ikään kuin se olisi järjestelmän raja. Ne tuottavat varteenotettavan näköisiä lähtöjä, jotka ovat virheellisiä hienovaraisesti. Nämä epäonnistumiset ovat:

• Kalliita havaita
• Kallista vianetsintää
• Usein näkyvissä vasta vahingon jälkeen

Pienet mallit epäonnistuvat eri tavalla.

Kun pieni malli on hämmentynyt, sillä on taipumus:

• Taukoskeemat
• Emit invalidi JSON
• Suorita lähdöt
• Rakenteen menettäminen

Nämä ovat halvat epäonnistumisetNe ovat havaittavissa yksinkertaisella varmennuksella. Ne laukaisevat takaiskuja tai varaiskuja välittömästi.

Tämä ei ole heikkous, vaan ominaisuus.

Mistä tämä periaate on lähtöisin

Tämä näkemys ei ole abstrakti teoria - se on perusta LLM:n kymmenen käyttökäskyä. Perusperiaate:

LLM:t tulkitsevat todellisuutta, eikä niiden pidä koskaan antaa määritellä sitä.

Kun noudatat tätä periaatetta, huomaat jotain yllättävää: kalliiden mallien tarve lakkaa. Paikallisesti toimiva 7B-parametrimalli voi luokitella, tiivistää ja tuottaa hypoteeseja aivan hyvin - koska sen ympärillä olevat deterministiset järjestelmät käsittelevät kaikkea, mikä itse asiassa tarvitsee olla oikein.

Pienet mallit eivät ole "heikkoja" - ne ovat usein riittävästi koska ongelma on jo pienentynyt siihen mennessä, kun se tavoittaa heidät.

Rajamallit myyvät sinulle luotettavuutta, jota sinun pitäisi rakentaa itse.

Oikea mielenmalli

Kuten DuckDB ei ole "halpa SQL" ja Postgres ei ole "huono Azure SQL", pienet LLM:t ovat suunnittelutilan eri kohtaValitset ne, kun:

Huolenaihe Pienen mallin etu |---------|----------------------| | Paikkakunta Toimii laitteessasi, verkossasi, toimialueellasi | Tarkastuskelpoisuus Jokainen päätelmä on kirjattavissa, toistettavissa, tarkistettavissa | Räjähdyssäde Epäonnistumiset on suljettu, niitä ei levitetä API-ketjujen kautta. | Asianmukaisuuden valvonta Validointi tapahtuu mallin ulkopuolella | Rajattu ei-determinismi Epävarmuus on tiukasti rajoitettua

Miten käytän tätä käytännössä

Tämä ei ole hypoteettista. Projektini osoittavat tämän kaavan toistuvasti:

GraphRAG kolmella poistotilalla

GraphRAG-toteutukseni tarjoaa kolme tilaa:

LLM kutsuu parastaan |------|-----------|----------| | Heuristista Puhtaasti determinismiä IDF:n ja rakennelman kautta | Hybridi 1 / asiakirja Pieni malli vahvistaa ehdokkaat | LLM 2 kappaletta kohti Maksimilaatu tarvittaessa

Erytropoietiini hybriditila On makea paikka: heuristinen poiminta löytää ehdokkaita (määritteleviä), sitten pieni paikallinen malli vahvistaa ja rikastuttaa heitä. Yksi LLM-puhelu per asiakirja, ei per kappale.

Kun Ollama juoksee paikallisesti, se maksaa $0. Mutta en käytä sitä siksi - kustannussäästöt ovat oikean abstraktion sivuvaikutus, en päämäärä. Käytän sitä, koska epäonnistumiset ovat halpoja ja ilmeisiä.

ONNX-kytkennät: Ei LLM-vaatimuksia

Semanttinen etsintä ONNX:n ja Qdrantin kanssa näyttää toisen kaavan: osa tehtävistä ei tarvitse LLM:tä lainkaan. ONNX Runtime -ohjelman kautta tehdyt BERT-syötteet antavat:

• CPU-ystävällinen päätelmä - GPU:ta ei tarvita
• Määritteleviä tuotoksia - sama syöttö tuottaa aina saman upotuksen
• Paikallinen toteutus - ei API-puheluita, ei latenssia, ei hintarajoituksia
• ~90MB-malli - juoksee minne tahansa

FINREP:n puolesta hybridihaku, Yhdistän nämä upotukset BM25-tulokseen. LLM ilmestyy vain synteesihetkellä - ja silloinkin pieni paikallinen malli toimii hyvin, koska se on selittäminen Deterministiset järjestelmät ovat jo vahvistaneet rakenteen.

DocSummarizer: Structure First, LLM Second

DocSummarizer se ilmentää tätä filosofiaa:

1. Parse Dokumentit deterministisillä kirjastoilla (OpenXML, Markdig)
2. Chunk Rakenteellisten sääntöjen mukainen sisältö (otsakkeet, kohdat, koodilohkot)
3. Upota ONNX BERT -kynällä varustettuja kappaleita
4. Hae merkitykselliset osat vektorihaun kautta
5. Synteesi Ollaman kanssa - ainoa todennäköinen askel

LLM on viimeinen askelSe voi epäonnistua, ja silloin epäonnistuminen on ilmeistä, koska rakenne on jo oikea.

TinyLLM: Paikallinen keskustelu rajausten kanssa

TINJLLM Osoittaa paikallisen LLM-käytön Windows-työpöytäsovelluksessa. Se tukee:

• Ollama-taustaosa
• Suora GGUF-mallin lataus
• RAG-muisti (deterministisellä haulla)

Chat-rajapinta on todennäköinen. Muisti, tiedostojen käsittely ja valtion hallinta ovat deterministisiä. Toisessa epäonnistuminen ei vahingoita toista.

Kolme kysymystä

Rajamallit ovat tehokkaita työkaluja, kun niitä käytetään tarkoituksella, mutta ne lisäävät ilmaisuvoimaa nopeammin kuin vähentävät riskiä. Pienet mallit, kun ne on upotettu deterministisiin järjestelmiin, antavat riittävästi epävarmuutta tutkia – ilman totuuden tai vastuun hämärtämistä.

Oikea kysymys ei ole "kumpi malli on paras?"

Se on:

1. Mihin todennäköisyys kuuluu?
2. Missä determinismin täytyy olla ehdotonta?
3. Mitä epäonnistumisia tämä järjestelmä voi kestää?

Jos vastaus sisältää valtion, sivuvaikutuksia, rahaa, politiikkaa tai takuita - mallin ei pitäisi koskaan olla johdossa. Ja jos malli on olemassa vain luokittelemaan, tiivistämään, luokittelemaan tai ehdottamaan olettamuksia, niin usein pieni paikallinen malli on oikea valinta, ei taloudellinen.

Malli: Tylsät koneet + pieni malli

Tämä on arkkitehtuuri, joka toimii:

┌─────────────────────────────────────────────────────┐
│                 DETERMINISTIC LAYER                 │
│  State machines, queues, validation, storage        │
│  (DuckDB, Postgres, Redis, file systems)           │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│                   INTERFACE LAYER                   │
│  Schema validation, retries, fallbacks             │
│  (Polly, FluentValidation, custom guards)          │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│                  PROBABILISTIC LAYER                │
│  Classification, summarisation, hypothesis gen     │
│  (Ollama, ONNX, small local models)                │
└─────────────────────────────────────────────────────┘

LLM: llä on pohjaSe ehdottaa, että deterministiset kerrokset hävitetään.

Luottamus ei ole epäonnistumisen välttämistä

Kaikki kolme näkökulmaa - kysymykset, kuvio ja tämä viimeinen periaate - lievenevät samaan sääntöön:

Luotettavuudessa on kyse siitä, että valitset epäonnistumisia, joista selviät.

LLM:ien kohdalla se tarkoittaa ei-determinismin hallintaa deterministisillä käytännöillä:

• Määräys I: Valtio elää mallin ulkopuolella
• Määräys VII: Tee epäonnistumisesta äänekäs ja tylsä
• Määräys IX: Rakenna tylsä kone ensin

Pienet mallit helpottavat tätä, koska niiden epäonnistumiset ovat kovaäänistä. Invalidi JSON. Tunkeutunut ulostulo. Schema-rikkomukset. Nämä ovat lahjoja - ne kertovat heti, että jokin meni pieleen.

Rajamallin epäonnistumiset ovat hiljaisuus. Uskottavalta kuulostava hölynpöly, itsevarmat hallusinaatiot, semanttinen ajelehtiminen, joka tulee näkyviin vain silloin, kun asiakas valittaa tai tarkastus epäonnistuu.

Otan kovaäänisiä epäonnistumisia joka kerta.

Aiheeseen liittyvää lukemista

Filosofia

• LLM:n kymmenen käyttökäskyä - Periaatteet tämän lähestymistavan takana
• Miksi en käytä LangChainia - Kehyksen monimutkaisuus vs. selkeys
• Miksi kaupalliset tekoälyhankkeet ovat typeriä - Paikallisen tekoälyn tapaus

Täytäntöönpano

• GrafRAG: Elinkelpoinen vähimmäistoteutus - Käytännössä kolme eristystilaa
• Semanttinen haku ONNX:llä ja Qdrantilla - CPU-ystävällisiä upotuksia
• DocSummarizer-työkalu - Rakenne ensin, LLM toiseksi
• Hybridihaku ja autoindeksointi - Tuotantovalmis haku

Arkkitehtuuri

• DiSE: LLM:ien kohteleminen epäluotettavana Epäluotettavat jumalat
• Bot Detection with LLM Advisors - LLM neuvonantajana, ei valvojana
• Zero-PII-asiakastiedustelu - Semanttinen ymmärrys ja rajat

Ulkoiset resurssit

• Ollama - Suorita LLM:t paikallisesti yhdellä komennolla
• ONNX-ajoaika - Alustan poikki ML-päätelmä
• LM Studio - Työpöytäsovellus paikallisille LLM:ille
• laama.cpp - Tehokas C++-päätelmä