Automatic Prompt Engineer (APE) inaruhusu modeli ya lugha kuandika, kujaribu, na kuchagua prompt bora kwa kazi fulani, ikibadilisha kile ambacho hapo awali kilikuwa sanaa ya majaribio na makosa (trial-and-error) kuwa utafutaji unaorudiwa unaoendeshwa na data.

Kwa nini uandishi wa prompt umekuwa kikwazo

Prompt engineering—kuunda maneno sahihi yanayoiambia modeli nini cha kufanya—imekuwa kwa muda mrefu mchanganyiko wa hisia na bahati. Wataalamu hubadilisha neno hapa, kubadilisha kirai pale, kuendesha modeli, na kuacha pale matokeo yanapoonekana "kuwa sahihi." Mbinu hii inachukua muda mrefu, inategemea mawazo ya mhandisi, na inazuia ufanisi. Katika uzalishaji (production), hii inamaanisha mizunguko mirefu, matokeo yasiyoaminika, na gharama zilizojificha ambazo hujitokeza baada tu ya uzinduzi.

Mtiririko wa kazi wa hatua tatu wa APE

APE inachukulia uundaji wa prompt kama tatizo la utafutaji. Mtumiaji hutoa seti ndogo ya mifano ya ingizo-matokeo (input-output). Kisha mfumo unatekeleza hatua tatu zilizojitokeza:

  1. Propose (Pendekeza) – Modeli hukagua mifano na kutoa seti ya maelekezo ya majaribio, kama vile “toa kinyume chake” au “andika kinyume cha neno.”
  2. Score (Pa Alama) – Mfumo huendesha kila pendekezo kwenye seti tofauti ya mifano ambayo haijaonekana na kuhesabu ni majibu mangapi yanaendana na matokeo yanayotarajiwa, na kutoa namba ghafi ya usahihi. Hakuna uamuzi wa binadamu unaogusa hatua hii.
  3. Select (Chagua) – Maelekezo yenye usahihi wa juu zaidi yanakuwa prompt ya mwisho.

Mzunguko huu unaweza kujirudia. Prompt iliyoshinda inakuwa mbegu mpya, na modeli inapendekeza mabadiliko. Katika majaribio yaliyoripotiwa, maelekezo ya jumla yaliyopata alama ya 83% yaliboreshwa kuwa toleo lililofikia 100% kwenye seti ya majaribio.

Ni nini kinachofanya mbinu hii kuwa bora zaidi kuliko mkono wa binadamu

  • Coverage (Ufikiaji) – LLM hutengeneza mamilioni ya mbadala wa maneno kwa sekunde chache, mengi zaidi kuliko mtu anavyoweza kujaribu.
  • Objectivity (Uwazi) – Uchaguzi unategemea usahihi unaopimika, si jinsi maneno yanavyosikika kuwa yamepangiliwa vizuri. Maelekezo ya mtindo wa kitabu yanaweza kushindwa dhidi ya toleo fupi na lenye sauti ya ajabu ambalo modeli inaelewa vizuri zaidi.

Kwa sababu kipimo cha alama kinatoka kwa mtumiaji—kawaida ni ukaguzi wa ulinganishaji kamili au unit test—mfumo unaweza kurekebishwa kulingana na hitaji lolote la baadaye, kuanzia uundaji wa kodi hadi uchambuzi wa hisia (sentiment analysis).

Gharama ya uotomatishaji

Mabadiliko ya kutoa kitu kingine (trade-off) ni nguvu ya kompyuta (compute). Kupa alama kila pendekezo kunasababisha mialiko mingi ya modeli, hivyo hatua ya maendeleo hutumia kiasi kikubwa cha matumizi ya API. APE inachukulia gharama hiyo kama uwekezaji wa mara moja: mara tu prompt bora inapobainishwa, unaweza kuitumia tena milele bila gharama za ziada.

Masharti mawili pia yanazuia utumiaji:

  • Labeled examples (Mifano iliyowekwa lebo) – Mfumo unahitaji seti inayowakilisha ingizo na matokeo sahihi.
  • Scoring function (Kazi ya kutoa alama) – Watumiaji lazima wafafanue maana ya "sahihi" kwa kazi yao, iwe ni ulinganishaji kamili wa herufi, uvumilivu wa namba (numeric tolerance), au validator maalum.

Sehemu ambapo wazo hili linaweza kukwama

Ikiwa seti ya awali ya mifano ni ndogo sana au haiwakilishi hali halisi, prompt iliyochaguliwa inaweza kuwa na "overfit" na kushindwa katika matumizi ya ulimwengu halisi.

Nini cha kufuatilia baadaye

Chombo hiki kinatoa mbadala: toa mifano michache, acha modeli irudie mchakato, na upate prompt ambayo mfumo unaipa kipaumbele zaidi kati ya majaribio yake. Onyesho (demo) lipo kwenye kiungo katika tangazo la awali, na jamii ya kujifunza inakusanyika kwenye Telegram.

Muhtasari: Kuotomatisha prompt engineering kunabadilisha kukisia kwa ajili ya utendaji unaopimika, lakini kunahitaji data ya awali, nguvu ya kompyuta, na ufafanuzi wa wazi wa mafanikio.