Miksi DSPY yleensä tuhlaa aikaasi (ja milloin ei) Kysymys: "Pitäisikö minun käyttää DSPY:tä nopeaan optimointiin? Se näyttää täydelliseltä työkalulta rättijärjestelmäni parantamiseen." Vastaus: DSPY sopii erinomaisesti hyvin tarkkoihin, hyvin määriteltyihin tehtäviin. Mutta useimmille rättijärjestelmille se häiritsee sitä, mikä todella liikuttaa neulaa. Tässä on todellisuus: DSPY toimii parhaiten, kun sinulla on selkeä luokittelutehtävä mitattavissa olevalla tarkkuudella. Ajattele 35-luokan luokittelua, jossa voit kiivetä mäkeä yhdellä mittarilla. Mutta useimmat rättiongelmat eivät ole sellaisia. Kun rakennan järjestelmää myyntitietojen poimimiseksi transkriptioista, minulla ei ole tietojoukkoa "tässä ovat kaikki myyntitiedot". Todellinen työ on kaiken poimiminen, joidenkin esimerkkien käsin merkitseminen ja intuition rakentaminen siitä, mitä käyttäjät todella tarvitsevat. Tuotteesi ei ole vain kehote – se sisältää sen, miten keräät palautetta, asetat odotuksia käyttöliittymään, käsittelet tietojen poimintaa ja edustat paloja kontekstissa. Jos käytät aikaa siihen, miten malli tekee virheitä ja mitä käyttäjät pyytävät, edistyt paljon enemmän tuotteen parantamisessa kokonaisuutena. Yksi paikka, jossa DSPY loistaa: LLM-tuomarina -skenaariot. Jos sinulla on tonaalisuuden tai tosiasiallisuuden arviointi, josta todella välität, on järkevää merkitä 100 esimerkkiä itse ja käyttää sitten nopean optimoinnin työkaluja luodaksesi oman arvosanojesi mukaisen tuomarin. Mutta useimmille rättijärjestelmille? Sinun on parempi säätää kehotteita manuaalisesti samalla kun rakennat intuitiota tietystä käyttötapauksestasi. Tämä intuitio ohjaa parempia päätöksiä koko järjestelmäarkkitehtuurissasi.