Miután májusban bevezettük a Firefox Shake to Summarize funkcióját Androidon, közelebbről is meg akartuk vizsgálni, milyen modellezési munka áll a funkció mögött. Egy korábbi blogbejegyzésben már bemutattuk, hogyan választottunk modellt. Most, hogy a Shake to Summarize már néhány hónapja elérhető iOS-en és Android-on is, tovább léptünk, és összefoglaljuk, hogyan közelítettük meg a promptok kidolgozását.
Ebben a cikkben egy olyan Shake to Summarize felhasználási esetről lesz szó, ahol külön prompt finomhangolásra volt szükség: az online receptekről.
A probléma keretezése
Hasznos promptot csak akkor lehet készíteni, ha pontosan megfogalmazzuk, mit várunk az LLM-től. Az LLM-ek akkor működnek a legjobban, ha konkrét utasításokat kapnak, ezért minél élesebben körülhatároljuk a feladatot, annál jobb eredményre számíthatunk.
Kisebb LLM-eknél (mint amilyet itt is használunk) ez különösen fontos, mert ezek a modellek kevésbé tudnak a sorok között olvasni, és nem érzik rá olyan jól a kimondatlan szándékokra, mint a nagyobb társaik.
Ebben az alkalmazásban összefoglalókat akartunk készíteni. Első ránézésre ez elég egyszerűnek tűnik. Ahogy azonban egymás után próbáltuk a különböző promptokat, gyorsan kiderült, hogy az, mit tekintünk „jó” összefoglalónak, nagyrészt attól függ, mit is foglalunk össze.
Egy regény hasznos összefoglalója például adjon gyors áttekintést a cselekményről, de ne menjen bele túl sok részletbe; nem várjuk el, hogy szó szerint idézzen a szövegből.
Egy receptoldal összefoglalójánál viszont lényegében a receptet magát kell visszaadni. Ha a receptben az szerepel, hogy „szeretettel főzd”, abból lehet „főzd”, de ha 4 csésze zöldségalaplevet, 1 evőkanál oregánót és 1 teáskanál kakukkfüvet ír, akkor ezeket az adatokat pontosan így szeretnénk viszontlátni. Az olyan összefoglaló, hogy „a recepthez alaplé és fűszerek kellenek”, nem elég.
A prompt kialakítása
Innen már látszott, hogy nem elég egyetlen „foglalj össze” utasítás. Külön utasításkészletre van szükség – minden olyan weboldal-kategóriához, amit össze akarunk foglalni. A termékcsapattal közösen listát állítottunk össze azokról a cikk- és oldal-típusokról, amelyeket célba vettünk ezzel a funkcióval. Minden típushoz röviden leírtuk, milyen egy jó összefoglaló:
Recept – Az összetevők pontosan úgy, ahogy szerepelnek, a legfontosabb lépések, a szükséges idő, valamint a szerző vagy a kommentelők által adott tippek
Hír – Csak a fontos részletek: mi történt, mikor, és milyen következményei lehetnek az olvasóra nézve
Útmutató – Először sorold fel a szükséges anyagokat, ismereteket, eszközöket stb., majd a fő lépéseket és a szerző által kiemelt fontos figyelmeztetéseket.
Értékelés – Emeld ki az összesített értékelést. Ha termékteszt, szerepeljenek az előnyök és hátrányok, az ár, és az is, kiknek szánják a terméket.
Kutatás – A legfontosabb eredmények, a kutatók által jelzett bizonyossági szint, valamint a várható gyakorlati hatás.
Vélemény – A fő állítás, valamint a mellette felsorakoztatott legfontosabb érvek.
Ezt a listát általános utasításokkal egészítettük ki, hogy a modellt jobban ráhangoljuk a feladatra, és így született meg a kezdeti promptunk (olvashatóság kedvéért formázva) [forrás]:
Te egy Tartalom-összefoglaló vagy. Mobilra optimalizált összefoglalókat készítesz azzal, hogy először megérted, mire van valójában szüksége a felhasználóknak az egyes tartalomtípusokból.
Folyamat:
1. lépés: Azonosítsd és igazítsd.
2. lépés: A tartalomtípus alapján ezeket részesítsd előnyben:
Recept – Adagok száma, teljes idő, hozzávalók listája, fő lépések, tippek.
Hír – Mi történt, mikor, hol.
Útmutató – Teljes idő, anyagok, fő lépések, figyelmeztetések.
Értékelés – Összesített értékelés, ár.
Vélemény – Fő érvek, legfontosabb bizonyítékok.
Személyes blog – Szerző, fő mondanivaló.
Fikció – Szerző, a cselekmény összefoglalása.
Minden egyéb tartalomtípus – Rövid összefoglaló, legfeljebb 6 mondatban.
3. lépés: Formázd mobilra tömör megfogalmazással és legfeljebb 3 mondatos bekezdésekkel.
A kritikus részleteket (számok, figyelmeztetések, kulcsfogalmak) szedd félkövérrel.
A fenti promptot Foxfooding keretében teszteltük, és többnyire jól működött. A modell tömör, pontos és informatív összefoglalókat készített.
Kivéve a recepteknél.
Recepteknél azt tapasztaltuk, hogy a fenti prompttal a modell túlságosan is összefoglal. Gyakran kihagy fontos hozzávalókat, sőt néha magát a receptet is.
Például amikor egy lencseleves recept összefoglalását kértük, a modell ezt adta vissza:
Az oldal egy részletes receptet ad egy vegán lencseleveshez, amelyről a szerző azt állítja, hogy ez a legjobb, amit valaha készített. A leves kamrában is megtalálható alapanyagokból készül, például lencséből, darabolt paradicsomból, zöldségalapléből és fűszerekből (római kömény, curry por, kakukkfű), valamint friss zöldségekből (hagyma, répa, fokhagyma) és zöld levelesekből (kelkáposzta vagy leveleskel). Egy fontos lépés, hogy a leves egy részét leturmixoljuk, így tejtermék nélkül is krémes állagot kapunk.
A fenti összefoglaló pontos ugyan, de nem igazán hasznos. Ha az a cél, hogy az összefoglalóval gyorsan elérjük magát a receptet, anélkül hogy végig kellene olvasni a hosszú bevezetőt, ez így kevés.
A prompt finomhangolása
Ahhoz, hogy megoldjuk ezt a problémát, sokkal egyértelműbben kellett megfogalmaznunk az utasításokat, amelyeket a modellnek adunk a receptek összefoglalásakor: meg kellett mondanunk, milyen információkra vagyunk kíváncsiak, és mit hagyhat figyelmen kívül.
Beírhattuk volna ezeket az extra iránymutatásokat közvetlenül a fenti promptba is, de így fennállt a veszélye, hogy a modell túlságosan a receptformátumra áll rá, és figyelmen kívül hagyja a többi cikktípust. Inkább egy külön promptot készítettünk, amely csak a receptekre vonatkozó utasításokat tartalmazza, és a recept-összefoglalási kéréseket ehhez irányítottuk a korábbi általános prompt helyett [forrás].
A megfelelő útvonalválasztáshoz az egyes weboldalakba ágyazott strukturált adatot használtuk. Ezt a kategorizálást akár egy újabb modell-futtatással is megoldhattuk volna, de a weboldal saját metaadatai lehetővé tették, hogy gyorsan és determinisztikusan azonosítsuk az oldal típusát, további következtetési költség nélkül. Azokra az esetekre, amikor ez az adat hiányzik vagy pontatlan, az általános promptban is megtartottunk némi, receptekre vonatkozó könnyű iránymutatást.
E változtatás után a modell által adott összefoglaló az adott recepthez sokkal használhatóbb lett (rövidítve):
Adagok: 6
Teljes idő: 50 perc
Előkészítés: 10 perc
Főzési idő: 40 perc
Hozzávalók
- ¼ csésze extra szűz olívaolaj
- 1 közepes sárga vagy fehér hagyma, felaprítva
- 2 sárgarépa, meghámozva és felaprítva
- …
Elkészítés
- Melegítsd fel az olívaolajat egy nagy, vastag falú lábasban vagy fazékban közepes lángon.
- Add hozzá a felaprított hagymát és répát, és főzd, amíg a hagyma megpuhul és üveges lesz, körülbelül 5 percig.
- …
⭐️ Tippek
- Használj botmixert, így nem kell átszedni a levest turmixgépbe a krémesítéshez.
- …
Tápérték
- Kalória: 320
- …
Ezzel a módosítással egy gondosan összeválogatott receptoldal-készleten futtattunk egy gyors tesztet, és azt találtuk, hogy az új rendszer több mint kétszer akkora eséllyel ad teljes és pontos összefoglalót, mint a korábbi. Siker!
A rendszer most már úgy működött, ahogy szerettük volna: az összefoglalók hasznosak lettek, a receptek pedig teljesek maradtak.
Visszatekintés
Ebből a tapasztalatból azt tanultuk, hogy a modell akkor adja a legjobb eredményt, ha nagyon egyértelműen megmondjuk neki, mit várunk tőle. Ha az utasítás homályos, vagy túl sok mindent a modellre bízunk, a teljesítmény romlik.
Arra jutottunk, hogy ha az egészet útválasztási problémaként fogjuk fel – vagyis a különböző cikkfajtákat különböző promptokra irányítjuk –, az jól működik. Mivel az összefoglalás feladata nem egységes, az összefoglaló pipeline se legyen az.
Bár a jelenlegi megközelítésünkben csak egyetlen, kategóriaspecifikus promptot használunk, feltételezzük, hogy a rendszer tovább javulna, ha más oldaltípusokhoz is külön promptokat készítenénk.
Tágabb értelemben ez a tapasztalat egy fontos tanulságot erősített meg számunkra: az MI-rendszerek fejlesztése nem csak arról szól, hogy egyre nagyobb vagy egyre erősebb modelleket építünk. A legnagyobb előrelépések egy része abból származik, hogy csökkentjük a bizonytalanságot, szűkebbre vesszük a feladatot, és olyan rendszereket tervezünk, amelyek segítik a modellt a sikerben. Ha a keretrendszer jól van kialakítva, a kisebb, nyílt forráskódú modellek is komoly értéket tudnak adni.
Miközben a fejlettebb modellek építése továbbra is előreviszi a területet, a mi tapasztalatunk azt mutatja, hogy az átgondolt rendszertervezés és a jó mérnöki munka továbbra is számít.

