Päättelymallien valinta ja kehottaminen
Keskitaso10 min lukemistaKehotteiden laatiminen

Päättelymallien valinta ja kehottaminen

Päättelyasetukset vaikuttavat laatuun, viiveeseen, kustannuksiin ja joskus myös kehotteiden toimintaan. Käytännön opas niiden valintaan arviointitulosten eikä uskomusten perusteella.

Mitä sinun pitäisi osata

Aloita selkeästä ongelmasta, todellisista rajoitteista ja vaaditusta näytöstä. Vertaa päättelykokoonpanoja kelvolliseen vertailutasoon edustavilla tapauksilla ja ota huomioon laatu, viive ja kustannus.

Tallennettu vain tällä selaimella.
Tässä artikkelissa

Palveluntarjoajat toteuttavat päättelyä eri tavoin. OpenAI käyttää tuetuissa malleissa päättelypanosta ja -tiloja, Anthropic dokumentoi mukautuvan ja laajennetun päättelyn, ja Google dokumentoi tuettujen Gemini-mallien päättelytasot tai -budjetit. Tuotenimet ja parametrit muuttuvat, joten valitse ratkaisu ajantasaisen palveluntarjoajadokumentaation ja tehtävässä mitatun suoriutumisen, älä kiinteän malliluettelon perusteella.

Jotkin päättelymallit hyötyvät erilaisesta kehotetyylistä kuin asetukset, joissa päättelyä käytetään vähemmän. OpenAI:n päättelymallien ajantasainen ohje on aloittaa suoraviivaisista kehotteista eikä pyytää mallilta päättelyketjua. Käsittele laajempia väitteitä vaiheistuksesta, rooleista ja itsekritiikistä hypoteeseina, joita testaat omalla mallillasi ja työkuormallasi, älä eri palveluntarjoajille automaattisesti siirtyvinä sääntöinä.

Tässä artikkelissa käsitellään, mitä päättelymallit ovat, milloin niitä kannattaa käyttää, miten niille laaditaan hyviä kehotteita ja mitkä sudenkuopat yllättävät kokeneetkin tekoälyn käyttäjät.

Mitä päättelyasetukset muuttavat

Palveluntarjoajat käyttävät nimikkeitä kuten päättely, ajattelu, panos ja budjetti asetuksille, jotka voivat muuttaa tokenien käyttöä, viivettä ja tuloksen laatua. Palveluntarjoajasta ja kokoonpanosta riippuen päättelysisältö voidaan piilottaa, tiivistää, jättää pois tai palauttaa erillisinä lohkoina. Älä päättele palveluntarjoajan piilotettua prosessia nimikkeestä tai lopullisen vastauksen tyylistä.

Päättely voi parantaa joidenkin vaikeiden, monivaiheisten tehtävien tuloksia, mutta hyöty riippuu mallista, päättelypanoksesta, kehotteesta ja arvioinnista. Se voi myös lisätä viivettä ja laskutettavia päättelytokeneita. Pienemmän viiveen ja suuremman päättelypanoksen välinen valinta on siksi vertailtava arkkitehtuuripäätös, ei yleispätevä parannus.

Esimerkkejä päättelyä tarjoavista tuoteryhmistä vuonna 2026:

  • OpenAI:n päättelytilat. OpenAI on julkaissut o-sarjan malleja ja GPT-päättelytiloja. Saatavuus- ja poistumispäivät vaihtelevat tuotteen ja tilauksen mukaan, joten tarkista nykyinen malliohje ennen yhden vaihtoehdon vakiinnuttamista.
  • Claude-mallit, joissa on päättely. Anthropicin nykyisen dokumentaation mukaan päättelyä tuetaan nykyisissä Claude-malleissa, mutta asetustapa vaihtelee. Osa käyttää mukautuvaa päättelyä, kun taas manuaalista budget_tokens-asetusta ei tueta tai se on vanhentumassa joissakin malleissa. Seuraa mallikohtaista taulukkoa yleisen parametriohjeen sijaan.
  • DeepSeek R1. R1-tutkimusartikkeli kuvaa malliperheen ja koulutustavan. Tarkista tuetut mallit ja käyttötavat DeepSeekin nykyisestä virallisesta dokumentaatiosta.
  • Gemini-päättelytilat. Tuetut Gemini API -mallit tarjoavat palveluntarjoajakohtaisia päättelyasetuksia, jotka kuvataan Geminin päättelyoppaassa.
  • Muiden palveluntarjoajien ratkaisut. Käsittele tuotenimiä, käyttöoikeuksia ja asetuksia aikariippuvaisina. Tarkista ne palveluntarjoajan nykyisestä virallisesta dokumentaatiosta ennen käyttöönottoa tai suosittelua.

Tuotteet eroavat mallien käyttäytymisessä, tuetuissa asetuksissa, kustannuksissa, viiveessä ja päättelytuloksen näkyvyydessä. Älä oleta parametrin tai kehotesäännön siirtyvän sellaisenaan palveluntarjoajalta toiselle.

Milloin laajempaa päättelyä kannattaa testata

Päättelymalli tai suuremman päättelypanoksen asetus voi olla olennainen vertailuvaihtoehto. Käytä seuraavia tehtäväsignaaleja ja rajoja kokeen määrittelyssä:

  • Ongelma koostuu useista toistensa varaan rakentuvista vaiheista. Matematiikka, logiikka, monivaiheinen suunnittelu ja koodi, jonka ymmärtäminen vaatii tilan seuraamista.
  • Pienemmän päättelypanoksen asetus epäonnistuu samoissa arviointitapauksissa. Päättelymalli tai suurempi päättelypanos on silloin perusteltu koe. Vertaa asetuksia samoilla tapauksilla.
  • Tehtävä vaatii huolellista vertailua tai kompromissien analyysia. Monikriteeriset päätökset, arkkitehtuurivalinnat ja toimittajien arviointi.
  • Arviointisi sisältää poikkeustapauksia, jotka pienemmän päättelypanoksen asetus ohittaa. Mittaa nämä tapaukset suoraan sen sijaan, että päättelisit päättelyn laadun sujuvasta tekstistä.
  • Tehtävä on seurauksiltaan merkittävä. Älä valitse laajempaa päättelyä vain korkeiden panosten vuoksi. Käytä rahoituksen, lain, lääketieteen, turvallisuuden tai tuotantotoimintojen yhteydessä ensisijaisia lähteitä, pätevää tarkistusta, validoituja hallintakeinoja ja dokumentoitua päätösrajaa. Testaa sitten, parantaako päättelykokoonpano olennaisia tapauksia.

Tapauksia, joissa pienemmän päättelypanoksen vertailutaso voi olla kilpailukykyinen:

  • Viiveherkkä keskustelukäyttö. Käytä suurempaa päättelypanosta vain, jos mitattu laatuetu perustelee hitaamman vuorovaikutuksen.
  • Sisällön tuottaminen ja luonnostelu, jos arviointi ei osoita hyötyä. Pienemmän viiveen asetus voi sopia luovaan iterointiin paremmin. Vertaa tuotosten laatua sen sijaan, että olettaisit suuremman päättelypanoksen auttavan tai haittaavan.
  • Yksinkertainen tiedonhaku. Lähteeseen sidottu haku tai pienemmän päättelypanoksen kokoonpano voi täyttää laatutavoitteen pienemmällä viiveellä ja kustannuksella. Varmista lähde kummassakin tapauksessa.
  • Nopea iteratiivinen viimeistely. Pienempi viive voi parantaa vuorovaikutusta, mutta vertaa tehtävän lopullista onnistumista pelkän viestimäärän sijaan.
  • Tehtävät, joissa tarvitset tarkastettavaa välivaiheiden näyttöä. Pyydä laskelmia, lähteitä, testituloksia tai muita todennettavia artefakteja. Näkyvä päättelyketju ei todista johtopäätöstä oikeaksi.

Hyödyllinen päätössääntö on lisätä päättelypanosta vain, kun odotettu laatuetu on kyseisessä työnkulussa mitatun viiveen ja kustannuksen arvoinen.

Vertailtavat kehotemallit

Aloita suorasta, tulokseen keskittyvästä kehotteesta ja vertaa sitten seuraavia malleja, kun ne voivat muuttaa tulosta olennaisesti:

1. Käytä suoraa kehotetta OpenAI-vertailutasona

OpenAI:n päättelymalleja koskevien OpenAI:n parhaiden käytäntöjen mukaan ”ajattele vaihe vaiheelta” -tyyppiset kehotteet ovat tarpeettomia ja voivat joskus haitata suoriutumista. Muilla palveluntarjoajilla on erilaisia asetuksia, joten testaa suoraa kehotetta harkitsemaasi jäsennellympään versioon.

Huono: Ajattele vaihe vaiheelta. Ratkaise tämä huolellisesti. Näytä työsi. [ongelma]

Hyvä: [ongelma]

Esitä ongelma selkeästi ja tarkista johtopäätös. Noudata muiden palveluntarjoajien ajantasaista dokumentaatiota ja testaa tuettua kehotetta tai asetusta.

2. Vertaa suoria kehotteita menettelyvaiheistukseen

Raskas vaiheistus voi toistaa työtä, jonka päättelymalli jo tekee. Aloita tavoitteesta, olennaisesta kontekstista, ehdottomista rajoitteista, vaaditusta näytöstä ja tulostusmuodosta. Poista menettelyvaiheita vain, kun arviointi osoittaa yksinkertaisemman kehotteen säilyttävän tarvitsemasi toiminnan.

Menettelyä noudattava ehdokas: Luettele ensin keskeiset rajoitteet. Luettele sitten vaihtoehdot. Arvioi jokainen vaihtoehto kunkin rajoitteen perusteella. Tee sitten valinta. Perustele lopuksi. Tulostusmuoto: …

Suora ehdokas: Auta minua valitsemaan vaihtoehdon A ja vaihtoehdon B välillä. Tausta: […]

Yksinkertaisempi kehote antaa mallille tilaa valita lähestymistapa mutta säilyttää olennaiset rajoitteet ja tulostussopimuksen.

3. Testaa tekniikoiden pinoamista sen hyödyllisyyden olettamisen sijaan

Päättelyketju-, itsekritiikki- ja puuhakukehotteet lisäävät ohjeita ja tokeneita. Älä oleta niiden pinoamisen parantavan arvioitua vastausta.

Jos kehotteesi sisältää ohjeen ”ajattele vaihe vaiheelta, arvioi sitten oma vastauksesi ja korjaa se”, vertaa sitä yksinkertaisempaan versioon. Säilytä versio, joka toimii edustavissa tapauksissa paremmin.

4. Käytä rooleja vain, kun ne välittävät tehtävätietoa

Yksityiskohtaiset persoonakuvaukset lisäävät usein tietoa, jota ei voi todentaa, muuttamatta itse tehtävää. Käytä roolia, kun se määrittää rajauksen, yleisön, käytännön tai terminologian. Muulloin kuvaa työ suoraan. Jos rooli näyttää parantavan tuloksia, vahvista hyöty samoilla arviointitapauksilla sen sijaan, että päättelisit sen persoonasta.

Lyhyt rooli voi auttaa määrittämään sävyn ja rekisterin. Vertaa sitä vastaaviin konkreettisiin ohjeisiin, kun johdonmukaisuus on tärkeää.

Huono: Olet maailmanluokan vanhempi taustajärjestelmäkehittäjä, jolla on 20+ vuoden kokemus…

Hyvä: Auta minua päättelemään tämä hajautettuihin järjestelmiin liittyvä ongelma. [ongelma]

5. Pyydä näyttöä, älä piilotettua ajattelua

Jotkin tuotteet piilottavat tai tiivistävät sisäisen päättelyn. Pyyntö ”näytä päättelysi” pyytää tuotettua selitystä, ei välttämättä mallin yksityistä päättelyjälkeä tai todistetta oikeellisuudesta.

Jos tarvitset tarkastettavuutta, pyydä tiivis perustelu ja todennettava näyttö. Anthropicin nykyinen API voi palauttaa mallista ja asetuksista riippuen tiivistettyä päättelyä tai jättää sen näyttämättä. Kumpikaan ei korvaa tuloksen tarkistamista.

Mitä kehotteeseen kannattaa sisällyttää

Hyödyllinen lähtötaso sisältää seuraavat asiat:

Täsmälliset tiedot. Anna tehtävän ratkaisemiseen ja vastauksen tarkistamiseen tarvittavat luvut, päivämäärät, tarkat rajoitteet, tiedostot ja muut syötteet.

Avoin kehystys, kun tulostussopimus sallii sen. ”Tässä on tilanne. Tämän haluan selvittää. Mitä ajattelet?” voi olla hyödyllinen ehdokas jäykempää mallipohjaa vasten testattavaksi.

Rehellinen epävarmuus. Kerro, mitä et tiedä. ”En tiedä, onko kyse X:stä vai Y:stä. Auta tunnistamaan, millainen näyttö erottaisi ne toisistaan” on hyödyllisempi kuin epävarmuuden piilottaminen.

Lupa olla eri mieltä. Ohje ”vastusta näkemystäni, jos kehystykseni on väärä” tai ”kerro, mitä en ole ottanut huomioon” voi tuoda esiin vaihtoehtoja, jotka vahvistusta hakeva kehote ohittaa.

Konkreettinen aineisto. Laskentataulukot, koodi ja asiakirjat antavat mallille todellista tarkasteltavaa aineistoa. Jaa ne vain, kun työkalu on hyväksytty kyseisille tiedoille, ja poista tehtävän kannalta tarpeettomat tiedot.

Käytännön esimerkit

Esimerkki 1: Virheenkorjaustehtävä

Oletetaan, että koodissa on hankala virhe.

Menettelyllisesti vaiheistettu kehote:

Olet TypeScriptiin erikoistunut vanhempi ohjelmistokehittäjä. Ajattele tätä virhettä vaihe vaiheelta.

Tunnista ensin olennaiset koodin osat. Seuraa toiseksi datan kulkua. Tunnista kolmanneksi todennäköiset syyt. Suosittele neljänneksi korjausta.

Virheen kuvaus: [kuvaus] Koodi: [koodi]

Suora kehote:

Auta minua löytämään tämä virhe.

Oireet: [kuvaus] Olennainen koodi: [koodi] Mitä olen jo kokeillut: [luettelo]

Vertaa suoraa kehotetta vaiheistettuun versioon edustavilla virheillä ja mittaa oikeellisuus, vaadittu näyttö, viive ja kustannus. Älä päättele tämän esimerkin perusteella, että suora versio on parempi.

Esimerkki 2: Strateginen päätös

Jäsennelty kehote:

Olet kokenut strategiakonsultti. Yritän päättää, pitäisikö tuote X julkaista. Sovella [viitekehyksen nimi] -viitekehystä. Aloita… [pitkä jäsennelty kehote]

Suora kehote:

Yritän päättää, pitäisikö tuote X julkaista. Tausta:

  • Olemme 50 henkilön yritys, jonka ARR on $5M.
  • Tuotteen rakentaminen veisi 2 vuosineljännestä.
  • Se liittyy päätuotteeseemme, mutta ei kilpaile suoraan sen kanssa.
  • Kaksi 10 suurimmasta asiakkaastamme on pyytänyt sitä.
  • Tiimimme kapasiteetti on jo tiukilla.

Auta minua pohtimaan asiaa. Vastusta heikkoa päättelyä. Kerro, mitä en ole ottanut huomioon.

Suora kehote antaa mallille tilaa valita analyysirakenteen. Vertaa sitä jäsenneltyyn versioon samoilla päätöskriteereillä ennen kuin otat kummankaan mallipohjaksi.

Esimerkki 3: Vaativa koodianalyysi

Menettelyllisesti vaiheistettu kehote:

Analysoi tämän koodin suorituskykyongelmat. Ajattele vaihe vaiheelta. Tunnista ensin tietorakenteet, seuraa sitten algoritmin aikavaativuutta ja osoita lopuksi tarkat pullonkaulat. [koodi]

Suora kehote:

Mikä tässä koodissa on hidasta? Se kestää tavallisella syötteellä tällä hetkellä ~3 sekuntia. Haluan keston alle 500ms.

[koodi]

Testaa, tunnistaako suora kehote olennaisen pullonkaulan ja tuottaako se toimivan korjauksen. Varmista jokainen ehdotus profilointitiedoilla, testeillä ja suorituskykymittauksilla.

Päättelymallien erityiset sudenkuopat

Seuraavat asiat yllättävät kokeneetkin käyttäjät:

Viive. Suurempi päättelypanos voi pidentää vastausaikaa, joskus huomattavasti. Mittaa oman mallisi ja työkuormasi todellinen jakauma aikakatkaisut mukaan lukien sen sijaan, että suunnittelisit yleisen arvion perusteella.

Kustannus. Palveluntarjoajat laskevat päättelyn käyttöä eri tavoin, ja mallien hinnat muuttuvat. Mittaa edustavien pyyntöjen laskutettavat syöte-, tuloste- ja päättelytokenit ja vertaa tehtävän kokonaiskustannusta kiinteän kertoimen olettamisen sijaan.

Vastaus saavuttaa generointirajansa. Päättely- ja vastaustokenit jakavat rajat eri tavoin palveluntarjoajasta riippuen. Jos vastaus katkeaa, tarkista palveluntarjoajan lopetussyy ja tokenlaskenta. Rajaa sitten tehtävää tai muuta vain tuettuja mallikohtaisia asetuksia. Älä oleta jokaisen API:n hyväksyvän yleistä päättelybudjettia.

Pitkät, pysähtyneet tai tuloksettomat vastaukset. Voit havaita poikkeuksellisen pitkän viiveen, aikakatkaisun, toistoa tai lopullisen vastauksen, joka ei täytä tehtävää. Kirjaa havaittava virhe ja kokoonpano. Yritä sitten uudelleen käytäntösi rajoissa, rajaa tehtävää tai vertaa toista tuettua asetusta. Älä väitä tietäväsi piilotettua syytä pelkän tuloksen perusteella.

Sujuvat mutta perusteettomat johtopäätökset. Suurempi päättelypanos ei todista oikeellisuutta. Vaadi kriittisissä tuotoksissa lähteet, laskelmat, testit sekä oletukset tai uusi näyttö, jotka muuttaisivat johtopäätöstä. Mallin ilmoittama varmuus ei ole kalibroitu takuu.

Pyyntöjen vaihteleva kustannus. Päättelytokenien käyttö voi vaihdella tehtävän ja asetusten mukaan. Seuraa todellista käyttöä sen sijaan, että olettaisit jokaisen pyynnön maksavan saman verran tai kustannuksen kasvavan ennustettavasti subjektiivisen vaikeuden mukana.

Testattava reititetty työnkulku

Yksi ehdokas on vaiheittainen reitti:

  1. Pienemmän viiveen kokoonpano tehtävän rajaamiseen ja osakysymysten tunnistamiseen.
  2. Laajemman päättelyn kokoonpano arvioiduille osakysymyksille, joissa vertailutaso ei täytä vaatimuksia.
  3. Hyväksytty tuotantokokoonpano varmistetun tuloksen muotoilemiseen kohdejärjestelmää varten.

Vertaa reittiä yhden kokoonpanon vertailutasoon. Mittaa tehtävien läpäisyaste, näytön kattavuus, siirtovirheet, palvelutason täyttyminen, kokonaisviive ja kokonaiskustannus. Lisävaiheet ovat hyödyllisiä vain, jos lopullinen työnkulku toimii riittävästi paremmin oikeuttaakseen operatiivisen monimutkaisuuden.

Käytännön esimerkki markkina-analyysista:

  • Rajausvaihe: ”Haluan ymmärtää X:n markkinaa. Auta rajaamaan analyysi: mitä minun pitäisi tarkastella, mitä dataa tarvitsen ja mitkä kysymykset ovat tärkeitä?”
  • Analyysivaihe: ”Mitä keräämäni varmistettu data kertoo [tarkasta strategisesta kysymyksestä]? Tunnista oletukset ja näyttöaukot.”
  • Muotoiluvaihe: ”Muuta varmistetut havainnot yhden sivun tiivistelmäksi johtoryhmällemme. Säilytä lähteet ja epävarmuus.”

Tämä jako on testattava työnkulku, ei taattu optimi. Vertaa sitä yhden mallin lähtötasoon laadun, viiveen ja kustannuksen perusteella.

Muutama käytännöllinen tapa

Määritä kelvollinen vertailutaso. Vertailutason on täytettävä samat data-, turvallisuus-, työkalu- ja tulosvaatimukset kuin päättelyehdokkaan.

Määritä päätössääntö etukäteen. Valitse laatumittari, palvelutasotavoite, kustannusraja ja vähimmäisparannus ennen tulosten näkemistä.

Seuraa päättelymallien kustannuksia. Seuraa kuukausittaista päättelymallilaskua joko tilaustason käyttömittarista tai API-laskutuksesta. Säädä käyttöä sen perusteella.

Huomaa pienemmän viiveen lähtötason toistuvat virheet. Ne ovat hyödyllinen merkki siitä, että samoilla tapauksilla kannattaa testata suurempaa päättelypanosta.

Vertaa yhtä kehotemuutosta kerrallaan. Kun vastaus on heikko, testaa lyhyempi kehote, lisäkonteksti tai toinen tuettu päättelyasetus erikseen, jotta tulosta voidaan tulkita.

Valitse näytön perusteella

Päättelyasetukset eivät ole automaattisesti parempia tai huonompia. Aloita selkeästä ja suorasta kehotteesta, säilytä todelliset rajoitteet ja näyttövaatimukset ja lisää rakenteisuutta tai päättelypanosta vain, kun edustavat arvioinnit perustelevat sen.

Käytä päättelyä harkiten ja aloita yksinkertaisesta kehotteesta. Pienemmän viiveen malli ideointiin ja suurempi päättelypanos arvioinnissa havaittuihin pullonkauloihin on yksi malli, jota kannattaa verrata yhden mallin työnkulkuun.

Lue seuraava

Jatka samaa oppimisreittiä seuraavilla käytännön artikkeleilla.

Syvennä osaamistasi

Valikoituja ulkoisia kursseja, jotka käsittelevät aiheita tarkemmin.

Näytä kaikki kurssit aiheesta Kehotteiden laatiminen