Hónapokig finomítottam a promptjaimat. Rendszerpromptok, few-shot példák, chain-of-thought láncolás — minden trükköt bevetettem. Aztán rájöttem, hogy a rossz kimenetek nem a prompt miatt voltak rosszak.
Hanem mert a modell nem azt az információt kapta, amire szüksége volt.
Prompt engineering halott — na jó, majdnem
A prompt engineering nem lett értéktelen. De a súlypontja eltolódott. Egy jól megírt prompt a context window talán 10-15%-át teszi ki. A maradék 85%? Lekért dokumentumok, korábbi beszélgetés, tool-kimenetek, felhasználói állapot.
Ha a lekért dokumentumok irrelevánsak, vagy a beszélgetés-előzmény rossz helyen van levágva, vagy a tool-eredmények hiányosak — a legtökéletesebb prompt sem ment meg.
A Phora fejlesztésekor ezt tapasztaltam nap mint nap. Nem az volt a kérdés, hogyan kérjem az AI-t. Hanem az, hogy milyen kontextust kapjon a kéréshez.
Context engineering: amit tényleg tudni kell
A context engineering annak a tudatos tervezése, hogy a modell mit lát egy-egy hívás során. Nem a prompt szövegét csiszolod — az egész input teret tervezed:
- Milyen dokumentumokat kérj le, és mennyit
- Hogyan tömörítsd a korábbi beszélgetést
- Milyen tool-kimeneteket adj vissza
- Hogyan tartsd meg a releváns memóriát hívások között
Minden token, ami bekerül a context window-ba, döntés. A context engineering az a diszciplína, ahol ezeket a döntéseket tudatosan hozod meg.
Miért számít ez egy termékfejlesztőnek
Mert a felhasználó nem a promptot látja — az eredményt látja. És az eredmény minősége a kontextus minőségétől függ.
Amikor a Phora-ban egy AI funkció rosszul teljesített, az esetek többségében nem a promptot kellett átírnom. A kontextust kellett átszerveznem: mit kap a modell, milyen sorrendben, milyen mennyiségben.
A prompt engineering arra jó, hogy elmondja a modellnek, hogyan beszéljen. A context engineering arra, hogy meghatározza, miről beszéljen.
Az első egy skill. A második egy architektúra.
Mindig van következő szint.
Ha tetszik, amit látsz — akár terméket, akár csapatot raksz össze — szívesen beszélek róla.