This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Wednesday, 26 November 2025
"Rakennamme tekoälyä hyödyntävää tieto-avustajaa, joka mullistaa työntekijöiden tiedonsaannin..."
- Jokainen työpaikkailmoitus, kenttä- ja konsulttiehdotus vuosina 2024-2025
Olen viettänyt viimeiset kuukaudet kunnolla uppoutuneena kaupalliseen tekoälyn tilaan. Lue lukuisia määriä markkinointipummia. Porsas yli kymmeniä työpaikkailmoituksia. Istuin läpi enemmän tuotedemoja kuin haluan myöntää. Ja olen tullut melko masentavaan lopputulokseen.
Se on melkein sama asia.
"AI-voimainen yritystietopohja." "Älykäs asiakirjahaku." "Asiakas chatbotti yritystietoineen." Poista hengästyttävä markkinointikopio, niin löydät saman arkkitehtuurin, samat epäonnistumistilat ja samat pettyneet sidosryhmät noin puolen vuoden päästä.
Asiakkaan chatbottiversiot ovat erityisen viihdyttäviä – niistä voi tulla PR-katastrofeja hämmästyttävän nopeasti, kun rakennuttajat, jotka eivät ymmärrä suojaraiteita, päästävät ne julkisuuteen. Mikään ei muistuta sitä, että tukisi bottia, joka tarjoaa hyvityksiä, joita et anna, keksii tuotteita, joita ei ole olemassa, tai jatkaa filosofista tangenttia olemassaolon merkityksestä, kun joku kysyy lähetysajoista. Ilman asianmukaisia rajoitteita nämä botit lupaavat ilomielin mitään, myöntävät rikoksille, joita yrityksesi ei tehnyt, tai kehittävät vahvoja mielipiteitä kilpailijoista. Canoninen esimerkki on edelleen Air Canadan chatbot, joka keksi itsevarmasti säästämiskäytännön, jota ei ollut olemassa – ja yhtiö, jota pidettiin oikeudessa.
Tässä on likainen salaisuus, jota kukaan johtoportaassa ei halua kuulla: Suurin osa kaupallisista tekoälyhankkeista ei ole innovatiivisia.
Ennen kuin menen pidemmälle, vastuuvapauslauseke: En ole "AI:n visionääri" tai mikä tahansa tämän hetken kohuhenkinen otsikko onkaan (enimmäkseen entiset "lohkoketjuvisionäärit", jotka ovat sopivasti kääntyneet). Olen ohjelmistoinsinööri, joka on rakentanut tällaisia järjestelmiä – etsintää, tiedonhallintaa, luonnollista kielen käsittelyä, päätöksentekotukea – lähes kolmen vuosikymmenen ajan. Olen nähnyt tämän kuvan aiemmin asiantuntijajärjestelmillä, semanttisella verkolla, isolla datalla, lohkoketjulla. Teknologian muutokset; ylilupaamisen ja alisuorittamisen malli ei.
Poista markkinointipaska ja huomaat, että noin 95 prosenttia kaupallisista "AI" -hankkeista kuuluu jompaankumpaan kahdesta kategoriasta:
Tämä on ylivoimaisesti yleisintä. Jokainen "yritys tekoälyratkaisu" noudattaa tätä kaavaa:
flowchart LR
A[Documents] --> B[Document Ingestion Pipeline]
B --> C[Vector Database / RAG]
C --> D[Construct Prompts]
D --> E[LLM API Call]
E --> F[Hybrid Search]
F --> G[Response to User]
style B stroke:#ff0000,stroke-width:4px
Kaikki hajoaa tuossa punaisessa laatikossa.
Puhe kuulostaa vaikuttavalta: "Olemme rakentaneet tekoälyn, joka ymmärtää yrityksesi dokumentteja ja osaa vastata kysymyksiin älykkäästi!"
Todellisuus: Olet rakentanut hakukoneen, jossa on lisäaskeleita ja 10 000 puntaa kuukaudessa.
"Olemme kouluttaneet oman tekoälymallimme nimenomaan sinun alallesi!"
Todellisuus: Olet ottanut jonkun toisen mallin ja hienosäätänyt sitä aineistolla, joka on luultavasti liian pieni, liian likainen ja liian kapea, jotta sillä olisi merkitystä, että käyttäisit vain pohjamallia hyvillä vinkeillä.
flowchart TD
A[Existing LLM] --> B[Collect Training Data]
B --> C[Clean Data - Maybe]
C --> D[Fine-tune Model]
D --> E[Deploy Model]
E --> F[Discover it's not much better than base model]
F --> G[Keep paying for inference anyway]
G --> H[Hope nobody notices]
Useimmat näkemäni hienosäätöhankkeet olisivat olleet hyödyllisempiä, jos ne olisivat käyttäneet samat rahat vihjeiden ja hakujärjestelmien parantamiseen.
Puhutaanpa siitä punaisesta laatikosta aluekaaviossa. Dokumenttien nieleminen on se osa, joka useimmiten epäonnistuuJa se on se osa, joka saa vähiten huomiota näyttävissä demoissa.
Myyntidemo näyttää tämän:
Näin oikeasti käy:
PDF on painajaismainen. Ne on suunniteltu tulostukseen, ei strukturoitujen tietojen keräämiseen. Jokaisessa käyttämässäni pdf-jäsennyslaitteessa on eri vikatilat:
Ne ovat vain pdf-muodossa.
Kun olet kopioinut tekstiä (köyhästi), sinun täytyy pilkkoa se vektoritietokantaasi. Täällä tapahtuu lisää taianomaista ajattelua.
"Käytämme semanttista pilkkomista!" Hienoa, 200-sivuinen sopimuksenne on nyt 500 kappaletta, eikä tekoälyllä ole aavistustakaan, mitkä niistä ovat sukua tai missä järjestyksessä ne näkyvät.
"Käytämme kiinteäkokoisia kappaleita päällekkäin!" Täydellinen, olet juuri jakanut lauseen kahtia ja upotus on nyt hölynpölyä.
flowchart TD
A[Original Document] --> B[Chunk 1: This contract shall be governed by]
A --> C[Chunk 2: the laws of the State of California]
B --> D[Embedding: Legal stuff?]
C --> E[Embedding: Geography?]
D --> F[User asks about jurisdiction]
E --> F
F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows]
Hyvä aluetukialue tarvitsee hyviä metatietoja, mutta metatietojen poimiminen asiakirjoista on vaikeaa:
Useimmilla organisaatioilla on vuosikymmeniä asiakirjoja, joissa on epäjohdonmukaisia nimityksiä, kansiorakenteita, jotka olivat järkeviä vuonna 2003 lähteneelle, sekä metatietoja, jotka ovat joko puutteellisia tai vääriä.
Haluan tehdä selväksi, että hienosäätämisellä on paikkansa, mutta useimpien yritysten tapa lähestyä sitä on perustavanlaatuisesti rikki.
Hienosäätö vaatii laadukasta koulutustietoa. Useimmilla yrityksillä ei ole sitä. Heillä on:
Tukilippusi ovat täynnä turhautuneita asiakkaita, virheellisiä tietoja juniorihenkilökunnalta ja terävimpiä tapauksia, jotka eivät edusta normaalia käyttöä.
"Tarkoitatko niitä, joissa myyjät antavat lupauksia, joita tuote ei pysty pitämään?"
Mistä tiedät, onko hienostunut mallisi oikeasti parempi? Useimmat yritykset eivät voi vastata tähän, koska:
Olen nähnyt, kuinka yritykset käyttävät puoli vuotta mallin hienosäätämiseen, eikä niillä sitten ole mitään keinoa todistaa, että se olisi parempi vaihtoehto kuin vain käyttää GPT-4:ää hyvällä järjestelmänopeudella.
Hienosäädetyt mallit kaipaavat päivittämistä, liiketoimintasi muuttuu, tuotteesi muuttuvat, prosessisi muuttuvat. Tammikuussa hienosäätämäsi malli antaa nyt vastauksia vanhentuneiden tietojen perusteella.
Päivittäminen tarkoittaa kuitenkin:
Suurin osa yrityksistä hienosäätää kerran ja sitten vain elää ajelehtimisen kanssa. Mallista tulee pikkuhiljaa vähemmän ajankohtainen, kun kaikki teeskentelevät, että se tuo yhä lisäarvoa.
Älä ymmärrä väärin, on olemassa käyttökelpoisia tapauksia:
flowchart TD
subgraph RAGWorks["✅ RAG Works When"]
R1[Well-structured docs]
R2[Clear metadata]
R3[Search + synthesis use case]
R4[Heavy ingestion investment]
R5[Feedback loops exist]
end
subgraph FTWorks["✅ Fine-Tuning Works When"]
F1[Large high-quality dataset]
F2[Base model truly struggles]
F3[Ongoing maintenance budget]
F4[Clear eval metrics]
F5[Already tried prompting + RAG]
end
style R4 stroke:#00aa00,stroke-width:2px
style F5 stroke:#00aa00,stroke-width:2px
Vihreät laatikot ovat edellytys useimmille projekteille. "Olemme jo optimoineet kehotuksen ja aluetuen" on rima hienosäätöön. "Raskas nielty sijoitus" Jos jätät nämä väliin, rakennat hiekkaa.
Samalla kun kaikki rakentavat samaa RAG-putkea, kaupallisen tekoälyn itse asiassa kiinnostavat ongelmat sivuutetaan:
Suurin rajoitus tekoälyn teholle ei ole malli, vaan data. Useimmissa organisaatioissa on:
Mutta "tietojen laatua koskeva aloite" ei tuo Forbesin artikkelia, kuten "AI:n muutos" tekee.
Tekoälypuhelimen pudottaminen olemassa olevaan prosessiin ei tee siitä maagisesti parempaa. Prosessia on uudistettava tekoälyn kykyjen ja rajoitusten ympärille. Useimmat yritykset vain nappaavat tekoälyn rikkinäisiin prosesseihin ja ihmettelevät, miksi se ei auta.
Parhailla tekoälyn toteutuksilla parannetaan ihmisten kykyjä sen sijaan, että ne yritettäisiin korvata. Mutta se on vaikeampaa myydä kuin "AI, joka tekee X:n automaattisesti!"
Ihmiset ja tekoäly yhdessä vaativat:
Useimmat kaupalliset tekoälyprojektit kohtelevat ihmistä jälkiviisaana.
Todella arvokkaat tekoälysovellukset eivät ole "chatbotti dokumenteissasi". Ne ovat hakemuksia, jotka:
Mutta ne ovat vaikeita. RAG-putkistot ovat helppoja (no, helpompia).
Konsultointiekosysteemi on merkittävä tekijä typerissä tekoälyhankkeissa:
flowchart TD
A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics]
B --> C[Consultancy Deploys Army of Juniors]
C --> D[Recommendations: RAG + Fine-Tuning]
D --> E[Build Same Thing as Last 20 Clients]
E --> F[Demo Goes Well]
F --> G[Reality: Real Data Breaks Everything]
G --> H[Consultancy Moves On]
H --> I[Internal Team Struggles]
I --> J[Project Quietly Fails]
J --> K[Nobody Admits It]
K --> A
style G stroke:#ff0000,stroke-width:3px
style J stroke:#ff0000,stroke-width:3px
Olen nähnyt tämän kuvion kymmeniä kertoja. Neuvonnasta maksetaan, johtajat saavat sanoa, että tekoäly on tehty. Insinöörit jäävät jumiin pitämään yllä jotain, mikä tuskin toimii, ja varsinainen liiketoimintaongelma on edelleen ratkaisematta.
Startup-yritykset ajautuvat hieman erilaiseen ansaan. Kyse ei ole konsultaatioista, jotka ajavat toimintahäiriöitä, vaan rahoitusympäristöstä.
timeline
title Technology Requirements for VC Funding
2005 : Web 2.0 - "You need social features"
2010 : Mobile - "You need an app"
2015 : Cloud - "You need to be cloud-native"
2018 : Blockchain - "You need a token"
2023 : AI - "You need an AI strategy"
Kuulostaako tutulta? Muutaman vuoden välein on olemassa uutta teknologiaa, jonka VC:t päättävät. Jos kansi ei mainitse sitä näkyvästi, et saa rahoitusta. Teknologialla ei ehkä ole merkitystä tuotteen kannalta – sillä ei ole merkitystä. Tarvitset muotisanaa.
Seurasin tätä blockchainilla 2017-2018. Yritykset, joilla ei ollut mitään asiaa olla lohkoketjussa, myivät tuotteitaan kengänkiillokkeilla, koska siitä saatiin rahoitusta. Suurin osa lohkochainin ominaisuuksista katosi kaikessa hiljaisuudessa, kun raha oli turvattu.
Nyt se tapahtuu tekoälyn kanssa.
Startup-yritykset ruuvaavat LLM-ominaisuuksia tuotteisiin, jotka eivät tarvitse niitä, koska:
Tulos: Tuotteita, joissa on kiusallisia tekoälyominaisuuksia, joita käyttäjät eivät huomioi. Kiitorata poltettiin hienosäätökokeilla, jotka eivät etene mihinkään. Insinööriaika kului RAG-järjestelmiin, kun yksinkertainen tietokantakysely toimisi paremmin.
Pahinta on: Monet perustajat tietävät, että tämä on hölmöä. He rakentavat tekoälyominaisuuksia, joihin he eivät usko, koska heidän on selviydyttävä tarpeeksi kauan rakentaakseen sen, mistä he oikeasti välittävät. Jotkut onnistuvat tässä pelissä. Useimmat eivät.
Jos olet startup-yrityksen perustaja, jota kehotetaan lisäämään tekoäly, kysy itseltäsi:
Jos kyseessä on jälkimmäinen, rakenna pienin elinkelpoinen tekoäly-ominaisuus, joka rastittaa laatikon, ja keskity sitten siihen, mikä on oikeasti tärkeää. Älä anna rahoitusympäristön häiritä jonkin arvokkaan rakentamista.
Tässä on epämiellyttävä totuus, josta kukaan tekoälyssä ei halua puhua: lähes kaikilla ekosysteemissä olevilla on taloudellinen kannustin pitää kohu käynnissä.
flowchart TD
subgraph Researchers["🔬 Frontier Labs"]
R1[Need billions for compute]
R2[Must show progress to justify spend]
R3[Hype generates investment]
end
subgraph Companies["🏢 Tech Companies"]
C1[Need AI angle for valuation]
C2[Must justify AI team costs]
C3[Hype drives stock price]
end
subgraph Investors["💰 Financial Backers"]
I1[Massive capital deployed]
I2[Need exits and returns]
I3[Hype maintains valuations]
end
subgraph Media["📰 Tech Media"]
M1[AI stories get clicks]
M2[Access depends on positive coverage]
M3[Hype drives engagement]
end
R3 --> I1
C3 --> I1
I3 --> R1
I3 --> C1
M3 --> R3
M3 --> C3
Tutkijat Rajalabrat tarvitsevat miljardeja laskelmia seuraavan sukupolven mallien kouluttamiseen. Rahat tulevat sijoittajilta ja isolta teknikolta. Kulutuksen perustelemiseksi niiden on osoitettava edistystä – ja "edistyminen" muuttuu hengästyttäväksi ilmoitukseksi kyvyistä, jotka saattavat toteutua käytännön sovelluksissa. Jos kohu kuolee, rahoitus kuivuu.
Yritykset (sekä tekoälylaboratoriot että kaikki tekoälyä käyttävät) tarvitsevat tarinankerronnan jatkumista. OpenAI:n arvostus riippuu uskosta, että AGI on kulman takana. Jokaisen "AI-käyttöisen" startup-yrityksen moninkertaisuus riippuu siitä, että tekoäly pysyy kuumana sektorina. Heti kun tunne muuttuu, miljardien paperivarallisuus haihtuu.
Sijoittajat Tekoälyyn on sijoitettu valtavia määriä pääomaa. He tarvitsevat uloskäyntejä. Musiikkia tarvitaan, jotta he voivat soittaa tarpeeksi pitkään saadakseen tuottoja. Realistinen arvio lähiajan tekoälyvalmiuksista kraatteroi koko sektorilla.
Tiedotusvälineet is sai selville, että tekoälytarinat herättävät valtavasti kiinnostusta. Nuancedin uutisointi ei saa klikkauksia. "AI vie työsi" ja "AI läpimurto ratkaisee X:n". Pääsy tekoälyyrityksiin riippuu usein positiivisten suhteiden ylläpitämisestä, mikä tarkoittaa, että kriittinen uutisointi rajoittaa uraa.
Seurauksena oli itseään vahvistava kohukierre, jossa kaikilla on syytä jatkaa odotusten paisuttamista, ja hyvin harva hyötyy totuuden kertomisesta.
Tämä ei tarkoita, etteikö tekoäly olisi aidosti hyödyllinen – se on ehdottomasti, kuten olen koko tämän artikkelin ajan puhunut. Mutta ero luvattavan ja toimitettavan välillä on valtava, ja kannustimet ovat linjassa, jotta ero voidaan pitää piilossa.
Kun joku sanoo, että tekoäly mullistaa yrityksesi, kysy itseltäsi: mitä he hyötyvät siitä, että uskot niin?
Jos harkitset tekoälyprojektia, tässä rehelliset neuvoni:
Älä kysy: "Miten tekoälyä voi käyttää?" Kysy: "Mitä ongelmaa yritämme ratkaista?" Jos tekoäly on oikea ratkaisu, hienoa.
Ennen kuin rakennat RAG-putken, korjaa asiakirjasotkusi. Ennen kuin puhdistat harjoitustietosi, tekoäly ei korjaa dataongelmiasi, vaan vahvistaa niitä.
Älä käynnistä massiivista "AI-muutosta". Rakenna pieni todiste konseptista, testaa sitä oikeilla käyttäjillä ja opettele, mikä oikeasti toimii. Laajenna sitten.
Dokumenttien nielemisputki ei ole seksikäs, tietojen puhdistus ei ole jännittävää. Arviointikehys ei ole sellainen, jota voi demoida johtokunnalle, mutta tämä ratkaisee menestyksen tai epäonnistumisen.
Nykyiset LLM:t hallusinoivat. RAG-järjestelmät kaipaavat dokumentteja. Hienosäädetyt mallit ajautuvat. Aseta realistisia odotuksia.
Järjestelmän rakentaminen on ehkä 30 prosenttia ponnistuksesta, sen ylläpitäminen, sen parantaminen ja sen tarkoituksenmukaisuus on toinen 70 prosenttia.
Ehkä tarvitset vain parempaa off-the-shelf -työkalujen käyttöä. ChatGPT, jossa on omat ohjeet, saattaa riittää. Kaikki ei tarvitse mittatilaustyönä tehtyä tekoälyalustaa.
Olen käyttänyt reilusti sanoja mainosten tekoälyprojekteihin. nämä projektit voivat oikeasti toimia, jos niitä lähestytään järkevästi.
Ongelmana ei ole RAG tai hienosäätö konsepteina, vaan laiska toteutus, epärealistiset odotukset ja perusasioiden sivuuttaminen.
Suurin virhe, jonka näen, on se, että tekoälyä pidetään olemassa olevien prosessien korvaajana eikä tehostamisena. Yritykselläsi on jo toimivia työnkulkuja. Sen sijaan, että se repisi ne irti ja korvaisi ne "AI-käyttöisellä" versiolla, kiinnitä tekoäly aukkoihin.
flowchart TD
subgraph Traditional["Traditional Workflow"]
A[Document Arrives] --> B[Human Reviews]
B --> C[Decision Made]
C --> D[Action Taken]
D --> E[Results Logged]
end
subgraph Enhanced["AI-Enhanced Workflow"]
A2[Document Arrives] --> AI1[AI: Extract Key Info]
AI1 --> B2[Human Reviews - With AI Summary]
B2 --> AI2[AI: Suggest Decision Based on History]
AI2 --> C2[Human Makes Final Decision]
C2 --> D2[Action Taken]
D2 --> AI3[AI: Auto-categorise & Log]
AI3 --> E2[Results Available for Future AI Training]
end
Huomaa, mikä on erilaista:
Tämä on paljon vankempaa kuin "AI hoitaa kaiken ja joskus ihmisen tarkastukset".
Tässä likainen salaisuus: et todennäköisesti tarvitse GPT-4:ää tai Claudea useimpiin tehtäviin, eikä sinun todellakaan tarvitse lähettää luottamuksellisia asiakirjojasi OpenAI:n palvelimille.
Kustannusongelma
Suurimmillaan API-kustannukset täsmäävät nopeasti. Kiireinen RAG-järjestelmä voi tehdä tuhansia LLM-puheluita päivässä. 0,01-0,03 dollarilla 1K-kuponkia kohden se on oikeaa rahaa. Ja kun mittaat, tilanne pahenee.
Luottamuksellisuusongelma
Monet organisaatiot eivät voi (tai niiden ei pitäisi) lähettää asiakirjojaan ulkoisiin sovellusrajapintoihin:
Ratkaisu: paikalliset mallit
Modernit avoimen lähdekoodin mallit ovat hemmetin hyviä.
flowchart LR
subgraph Cloud["Cloud API Approach"]
A1[Your Documents] --> B1[Internet]
B1 --> C1[OpenAI/Anthropic]
C1 --> D1[£££/month]
C1 --> E1[Privacy Concerns]
end
subgraph Local["Local LLM Approach"]
A2[Your Documents] --> B2[Your Server]
B2 --> C2[Local LLM]
C2 --> D2[Fixed Hardware Cost]
C2 --> E2[Data Never Leaves]
end
FINREP:n puolesta upotetaan (RAG-vektorin hakubitti):
FINREP:n puolesta sukupolvi (todelliset "AI"-vastaukset):
FINREP:n puolesta koodaustehtävät:
Paikallista pyörittäminen ei ole niin vaikeaa kuin luulisi. Ollama, laama.cpp, vLLM, tai Teksti-sukupolven-päätelmä Tee se suoraviivaiseksi. Olen rakentanut useita sovelluksia (ks. artikkelin alaosa), jotka osoittavat, että tämä toimii kuluttajien laitteistoilla.
Järkevä arkkitehtuuri käyttää:
Paikalliset mallit suuriin, pienempiin ja monimutkaisiin tehtäviin
Pilvirajapinnat monimutkaisiin perusteluihin tarvittaessa
Tämä hybridilähestymistapa tuo kustannushyötyjä paikalliselle päättelylle pilvimallien kyvykkyydestä, kun sitä aidosti tarvitaan.
flowchart LR
subgraph Waterfall["❌ The Waterfall AI Project"]
W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform]
W2 --> W3[Month 7-9: Integration]
W3 --> W4[Month 10: Demo - Looks Great!]
W4 --> W5[Month 11: Real Users Break It]
W5 --> W6[Month 12: Project Shelved]
end
subgraph Incremental["✅ The Incremental Approach"]
I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure]
I2 --> I3[Week 5-6: Add Capability]
I3 --> I4[Week 7-8: Refine + Measure]
I4 --> I5[Repeat...]
I5 --> I6[Continuous Value Delivery]
end
style W5 stroke:#ff0000,stroke-width:3px
style W6 stroke:#ff0000,stroke-width:3px
style I6 stroke:#00aa00,stroke-width:3px
Jokainen askel asteikolla tuottaa mitattavissa olevaa arvoa. Jokainen askel opettaa sinulle jotain. Jos jokin epäonnistuu, olet menettänyt viikkoja, et kuukausia.
Muistatko sen punaisen laatikon kaaviossa?
Sijoita laatuun yli määrän. On parempi, että on 1000 täydellisesti käsiteltyä asiakirjaa kuin 100 000 huonosti käsiteltyä asiakirjaa. Aloita tärkeimmistä asiakirjoista ja hoida ne oikein.
Käytä tekoälyä auttaaksesi nielemisessä. Modernit visionkieliset mallit (GPT-4V, Claude, LLaVA paikallisesti) voivat itse asiassa lukea monimutkaisia dokumentteja - taulukoita, kaavioita, käsin kirjoitettuja muistiinpanoja - tavoilla, joita perinteinen OCR ei pysty käyttämään.
Rakenna palautesilmukoita. Kun haku epäonnistuu, kirjaa se. Kun käyttäjät sanovat "ei niin kuin dokumentissa sanotaan", ota se talteen. Käytä tätä palautetta parantaaksesi nielemisputkeasi.
Hyväksy, että jotkin asiakirjat eivät toimi. Jokainen ikivanha skannattu PDF ei ole taistelun arvoinen. Joskus vastaus on "käsittelemme tämän tyypin käsin" sen sijaan, että käyttäisimme kuukausia teräviin juttuihin.
Toimiva tekoälyratkaisu edellyttää:
Komponentti Mitä suurin osa projekteista tekee, mitä itse asiassa toimii? |-----------|----------------------|---------------------| Datan nieleminen Jälkimmäinen ajatus Ensisijainen painopiste Tietojen laatu "AI selvittää sen" "Omistettu puhdistusputki" Perusvektorihaku Hybridihaku + uudelleenasettaminen Generation Raw LLM -tuotos Strukturoitu tuotos, jossa validointi Integroitu työnkulkuun Palautetta Ei jatkuvaa parannussilmukkaa "Se toimii", "Yksityiskohtaiset mittarit" ja "varoituksena" Ylläpito "Versio 1 ikuisesti" Säännöllisiä päivityksiä ja uudelleenkoulutusta
Tekoälymalli on ehkä 20 prosenttia toimivasta järjestelmästä. Muut 80 prosenttia ovat tylsiä asioita, jotka saavat sen toimimaan tuotannossa.
Et voi parantaa sitä, mitä et pysty mittaamaan. Jokaisen tekoälyjärjestelmän pitäisi seurata:
Tämä data kertoo, mihin panostaa. Ehkä hakusi on suuri, mutta sukupolvi on hallusinaatioita. Ehkä tietyt dokumenttityypit aina epäonnistuvat. Et voi korjata sitä, mitä et näe.
Tässä on tärkein vuoro tällä hetkellä: "Heitä kaikki GPT-4:ssä ja toivo parasta" -aikakausi on päättymässä.
Vuosien 2023-2024 lähestymistapa oli yksinkertainen: hanki suurin malli, johon sinulla on varaa, täytä kontekstiikkunasi täyteen kaikkea ja rukoile. Se toimi tavallaan demoille, prototyypeille, investointien saamiselle.
Mutta se ei skaalaudu, se on kallista, hidasta, ja yhä useammin se on älykkäämmän arkkitehtuurin yläpuolella.
Tulevaisuus ei ole mikään jättimalli, joka tekee kaiken. useita erikoistuneita malleja, jotka toimivat yhdessäJokainen tekee sitä, missä on hyvä.
flowchart TD
subgraph OldWay["The 2023 Approach"]
A1[Everything] --> B1[GPT-4]
B1 --> C1[Hope It Works]
B1 --> D1[£££££]
end
subgraph NewWay["The 2025+ Approach"]
A2[Input] --> B2[Router Model - Small/Fast]
B2 --> C2[Specialist Model A - Extraction]
B2 --> D2[Specialist Model B - Reasoning]
B2 --> E2[Specialist Model C - Generation]
C2 --> F2[Orchestrator]
D2 --> F2
E2 --> F2
F2 --> G2[Output]
end
Olen tutkinut tätä. DiSE (Directed Synthetic Evolution) työ – ajatus siitä, että rakenne lyö loistonHuolellisesti organisoitu pienempien, keskittyneiden mallien putki päihittää yhden massiivisen mallin, joka yrittää tehdä kaiken.
Samaa mieltä on Synteettinen päätösmoottori Konsepti: käyttämällä useita LLM-taustaosia järjestyksessä, jossa jokainen malli tuo erilaisia vahvuuksia. Nopeat mallit triagelle, tarkat mallit validoinnille, luovat mallit sukupolvelle. Jokainen tekee, mitä parhaiten tekee.
Jos et ole jo nähnyt, katso minun RAG-sarjat Perusasiat ovat syvällä, mutta tässä on avainymmärrys: RAG itse on tämän orkestroidun lähestymistavan muoto. Käytät upotuksia (yksi malli) löytääksesi sisältöä, sitten LLM (toinen malli) syntetisoidaksesi vastauksen.
Seuraava kehityskulku vie asiaa eteenpäin:
Jokainen malli on pienempi, nopeampi ja halvempi kuin GPT-4:n käyttö kaikkeen, mutta yhdessä ne päihittävät monoliittisen lähestymistavan.
Termi "agentti" on lainattu psykologiasta – alkuperäiseltä alaltani ennen kuin putosin ohjelmistoon. Psykologiassa virasto viittaa kykyyn toimia itsenäisesti, tehdä valintoja ja toteuttaa niitä maailmassa. Agenttihenkilö ei reagoi vain ärsykkeisiin, vaan hän käynnistää toimia, pyrkii tavoitteisiin ja mukauttaa käyttäytymistään tulosten perusteella.
Agenttinen tekoäly Tätä konseptia sovelletaan kielimalleihin. Perinteisen kuvion sijaan malli tuottaa tekstiä – agenttijärjestelmä voi itse asiassa tee asioita. Se voi käyttää työkaluja, suorittaa koodin, tiedustelutietokantoja, soittaa API-puhelimiin, kirjoittaa tiedostoja ja orkestroida monivaiheisia työvirtoja. Ero on siinä, että joku kysyy ohjeita ja palkkaa jonkun viemään sinut sinne.
Tämä on Antropicin tuoreimmat mallit (mm. Claude Opus 4,5 Se, että käytän tätä kirjaimellisesti Claude Code -koodin kautta, osoittaa niin tehokkaasti.
Tämä asia saa hienosäätöyleisön epämukavaksi: Jos kuvaat työkaluja riittävän hyvin, niiden käyttöön ei tarvita kallista hienosäätöä. Modernit perusmallit ovat huomattavan hyviä työkalun käytössä laatikosta - kontekstissa tarvitaan vain selkeitä toimintamalleja ja hyvää dokumentointia.
Tämä on valtava muutos Toolformer-lähestymistavasta (hieno malli, jolla opitaan käyttämään työkaluja mittaamalla tuloksia). Se on kallista, vaatii erikoiskoulutustietoa ja lukitsee sinut erityisiin työkaluihin. Vaihtoehto? Kuvaile työkalusi selkeästi, anna mallille hyvä konteksti ja anna sen selvittää, milloin niitä tulee käyttää.
Tulokset ovat usein parempia, koska:
flowchart TD
subgraph RAG["Traditional RAG Chatbot"]
R1[User Question] --> R2[Search Documents]
R2 --> R3[Construct Prompt]
R3 --> R4[LLM Generates Answer]
R4 --> R5[Return to User]
end
subgraph Agentic["Agentic AI Pattern"]
A1[User Task] --> A2[LLM Understands Task]
A2 --> A3[Break Into Steps]
A3 --> A4{Select Tool}
A4 --> A5[Execute Tool]
A5 --> A6{Evaluate Results}
A6 -->|Need More| A4
A6 -->|Done| A7[Return to User]
end
style A6 stroke:#00aa00,stroke-width:3px
Tämä agenttikuvio poikkeaa olennaisesti RAG-chattiboteista, ja siinä on todellinen arvo.
LangChainin, LlamaIndexin ja Semantic Kernelin kaltaiset puitteet mahdollistavat tämän tänään. Voit rakentaa järjestelmiä, joissa:
Yritykset, jotka selvittävät tämän, rakentavat tekoälyjärjestelmiä, jotka todella toimivat. Ne, jotka yhä yrittävät hienosäätää tiensä menestykseen tai rakentaa taas uuden RAG-chatbotin, pettyvät jatkossakin.
Olen kirjoittanut näistä kuvioista laajasti:
Aihe Artikkeli Mitä opit |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | Arkkitehtuuri | DiSE vs Voyager Miksi strukturoitu orkestrointi voittaa monoliittiset mallit? | Monimalliset mallit | Synteettiset päätösmoottorit Erikoistuneiden mallien putkistojen rakentaminen | RAG:n perusteet | RAG-sarja Uppoutumisesta tuotantojärjestelmiin | Paikalliset upotukset | Semanttinen haku ONNX:llä CPU-ystävällinen paikallinen vektorihaku | Paikalliset LLM-keskukset | DiSE Selkf evolvign -työnkulkujärjestelmä, jossa käytetään yhdessä kytkettyjä paikallisia malleja | API-simulaatio | LLMApi Paikallisten LLM:ien käyttö API:iden simulointiin | Käytännöllinen alue | Asianajajan rakentaminen GPT Koko aluetukialueen toteutuskävely läpikotaisin
Tekniikka on olemassa, kuviot nousevat esiin. Kysymys kuuluu, rakentaako organisaatiosi jotain järkevää vai toista tyhmää tekoälyprojektia.
Nykyinen kaupallinen tekoälymaisema tuo mieleen alkuaikojen verkkoajan. Kaikki tarvitsivat "web-strategian". Yritykset rakensivat verkkosivuja, koska niiden oli pakko, ei siksi, että ne tiesivät, mitä tehdä niille. Suurin osa sivustoista oli hyödyttömiä.
Lopulta yritykset, jotka onnistuivat, selvittivät, mihin verkko on oikeasti hyvä, ja rakensivat sen. Sama tapahtuu tekoälyn kohdalla.
Tällä hetkellä olemme "rakentamassa sitä, koska meidän täytyy" -vaiheessa. Useimmat projektit ovat typeriä, useimmat epäonnistuvat tai alisuorittavat. Se on normaalia uudelle teknologialle.
Mutta jos haluat olla yksi niistä, jotka onnistuvat, lopeta mallin seuraaminen. Aloita todellisista ongelmista. Sijoita tylsiin kappaleisiin. Ja jos haluat olla yksi niistä, jotka onnistuvat, korjaa asiakirjasi nielemisputki ennen kuin syytät LLM:ää.
Ongelmana ei ole tekoäly, vaan tietosi, prosessisi ja epärealistiset odotuksesi.
Korjaa ne ensin. Ehkä tekoälyprojektisi ei ole tyhmä.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.