# Ei, pienet mallit eivät ole "budjettivaihtoehto" 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ö [Ollama](https://ollama.ai/)LM Studio, [ONNX-ajoaika](https://onnxruntime.ai/), tai vastaava ei ole (vain) rahan säästämistä. Kyse on valitsemisesta **jossa ei-determinismi saa olla olemassa**. [TOC] ## 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äonnistumiset**Ne 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ä](/blog/tencommandments). 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 kohta**Valitset 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](/blog/graphrag-minimum-viable-implementation) 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](/blog/semantic-search-with-onnx-and-qdrant) 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](/blog/rag-hybrid-search-and-indexing), 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](/blog/docsummarizer-tool) 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 askel**Se voi epäonnistua, ja silloin epäonnistuminen on ilmeistä, koska rakenne on jo oikea. ### TinyLLM: Paikallinen keskustelu rajausten kanssa [TINJLLM](/blog/texttospeech) 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 **pohja**Se 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](/blog/tencommandments): Valtio elää mallin ulkopuolella - [Määräys VII](/blog/tencommandments): Tee epäonnistumisesta äänekäs ja tylsä - [Määräys IX](/blog/tencommandments): 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ä](/blog/tencommandments) - Periaatteet tämän lähestymistavan takana - [Miksi en käytä LangChainia](/blog/why-i-dont-use-langchain) - Kehyksen monimutkaisuus vs. selkeys - [Miksi kaupalliset tekoälyhankkeet ovat typeriä](/blog/whycommercialaiprojectsaredumb) - Paikallisen tekoälyn tapaus ### Täytäntöönpano - [GrafRAG: Elinkelpoinen vähimmäistoteutus](/blog/graphrag-minimum-viable-implementation) - Käytännössä kolme eristystilaa - [Semanttinen haku ONNX:llä ja Qdrantilla](/blog/semantic-search-with-onnx-and-qdrant) - CPU-ystävällisiä upotuksia - [DocSummarizer-työkalu](/blog/docsummarizer-tool) - Rakenne ensin, LLM toiseksi - [Hybridihaku ja autoindeksointi](/blog/rag-hybrid-search-and-indexing) - Tuotantovalmis haku ### Arkkitehtuuri - [DiSE: LLM:ien kohteleminen epäluotettavana](/blog/blog-article-cooking-dise-part3-untrustworthy-gods) Epäluotettavat jumalat - [Bot Detection with LLM Advisors](/blog/botdetection-introduction) - LLM neuvonantajana, ei valvojana - [Zero-PII-asiakastiedustelu](/blog/zero-pii-customer-intelligence-part1) - Semanttinen ymmärrys ja rajat ## Ulkoiset resurssit - [Ollama](https://ollama.ai/) - Suorita LLM:t paikallisesti yhdellä komennolla - [ONNX-ajoaika](https://onnxruntime.ai/) - Alustan poikki ML-päätelmä - [LM Studio](https://lmstudio.ai/) - Työpöytäsovellus paikallisille LLM:ille - [laama.cpp](https://github.com/ggerganov/llama.cpp) - Tehokas C++-päätelmä