Kun rakennat tekoälyagentteja, älä käsittele kehotuksia konfiguraatiomerkkijonoina. Käsittele niitä kuin suoritettavaa liiketoimintalogiikkaa. Koska sellaisia he oikeasti ovat. @arshdilbagi:n blogi ja tämä Stanfordin CS 224G -luento esittelevät yhden selkeimmistä mielikuvista, joita olen nähnyt LLM-arvioinnissa. Lopeta arviointien käsittely yksikkökokeina. Se toimii deterministisille ohjelmistoille. LLM-tuotteiden kohdalla se luo väärää luottamusta, koska todellinen käyttö muuttuu ajan myötä. Esimerkki: vakuutuspyyntö läpäisi 20 arviointitapausta. Tiimi lähti liikkeelle. Tuotannossa ilmestyi uusi pyyntöluokka, joka epäonnistui hiljaisesti. Ei kaatumista, ei hälytystä, vain vääriä vastauksia laajassa mittakaavassa. Korjaus ei ole "kirjoita lisää arviointitapauksia", kuten monet tiimit tekevät. Se rakentaa arvioita elävänä palautesilmukkaana. Aloita pienestä setistä, lähetä, katso mitä tuotannossa menee rikki, lisää ne viat takaisin ja ajaa uudelleen jokaisesta kehotteesta tai mallin muutoksesta. Mikä arviointivirhe yllätti tiimisi? Blogi: Stanford CS 224G -luento: