HarnessDev: LLMs Zikijenga Miundombinu Zao Wenyewe

ByteDance na kikundi cha vyuo vikuu vimezindua HarnessDev, mfumo (framework) unaoruhusu mifumo mikubwa ya lugha (LLMs) kuandika "mifumo ya uendeshaji ya wakala" (agent operating systems) yao wenyewe, inayojulikana kama Agent Harnesses. Timu hiyo humpa LLM seti ndogo ya kuanzia na kumuacha aijenge iliyobaki, ikionyesha jinsi AI inavyoweza kujenga tabaka la udhibiti linaloendesha mizunguko yake ya matumizi ya zana, hatua za uhakiki na ushughulikiaji wa makosa—bila binadamu kuandika kila mstari.

Kwa nini harness inayojengwa yenyewe ni muhimu

Wakala wa AI (AI agents) wamebadilika kutoka kuwa wasaidizi wa amri moja (single-prompt) hadi kuwa wafanyakazi wa hatua nyingi wanaotumia API, kuulizia kanzidata (databases) na kuunganisha matokeo. Mpaka sasa, watengenezaji walikuwa wakitengeneza kwa mkono kodi ya uratibu (orchestration code) inayoiambia modeli lini itumie zana ya utafutaji, jinsi ya kuhifadhi hali ya kati (intermediate state), na jinsi ya kuhakiki jibu la mwisho. HarnessDev inabadilisha mfumo huo: seed harness hutoa muundo wa msingi tu—kazi za kimsingi za kuzunguka (looping), kuchagua zana, na kufuatilia hali—na LLM huipanua kuwa mfumo kamili wa utendaji (runtime).

Katika kipimo (benchmark) cha karatasi hiyo, modeli ilitengeneza harness 18 tofauti, ikiongeza zaidi ya mistari 17,000 ya kodi kwenye kile kilichokuwa msingi. Kila harness ilisimamia mzunguko mzima wa kazi: kutekeleza mizunguko, kuchagua zana sahihi, kudumisha muktadha (context), kufuatilia hali, kuhakiki matokeo, na kurekebisha makosa.

Gharama zilizofichika ambazo utafiti umezigundua

Takwimu zinaonekana za kuvutia, lakini waandishi wanaonya kuwa utekelezaji wa kawaida haumaanishi matumizi ya vitendo.

  • Vipengele visivyotumika – Sehemu kubwa ya kodi iliyotengenezwa haikufanya kazi wakati wa utekelezaji halisi wa kazi. LLM iliandika kazi (functions) ambazo wakala hakuwahi kuzitumia, hivyo kuongeza ukubwa wa kodi bila kutoa thamani.
  • Utegemezi wa modeli (Model lock-in) – Harness zilikuwa zimepangiliwa kulingana na LLM maalum iliyozitengeneza. Wakati harness hiyo hiyo ilipopewa modeli nyingine, ufanisi ulipungua kwa kiasi kikubwa, ikionyesha kuwa mantiki ya udhibiti iliyotengenezwa kiotomatiki ina sifa za kipekee za modeli husika.
  • Mapungufu ya uhakiki – Harness moja ya majaribio iliripoti kiwango cha mafanikio cha 99% (99 kati ya marudio 100) lakini ilikuwa sahihi kwa 48% tu ya muda. Bila uhakiki thabiti, wakala anaweza kuwasilisha majibu yasiyo sahihi kwa ujasiri.
  • Gharama kubwa za token – Matumizi ya token—kiashiria cha gharama ya kompyuta—yalitofautiana sana. Harness moja ilihitaji token saba zaidi kuliko nyingine ili kupata matokeo yaleyale, jambo linalozua wasiwasi kuhusu uwezo wa kutanuka (scalability) katika mazingira ya uzalishaji.

Matokeo haya yanasisitiza hitaji la usanifu wenye nidhamu, hata wakati kodi inatoka kwenye LLM.

Mambo ambayo watengenezaji wanapaswa kuzingatia

  1. Chukulia usanifu wa harness kama usanifu wa mfumo (architecture) – Usitegemee modeli "kufanya kazi tu." Bainisha moduli zilizo wazi kwa ajili ya udhibiti wa mizunguko, uteuzi wa zana, ushughulikiaji wa hali, na uhakiki kabla ya kuruhusu LLM kuzijaza.
  2. Jenga uhakiki thabiti – Weka ukaguzi wa wazi unaolinganisha dai la wakala na ukweli (ground truth) au modeli ya pili. Usahihi wa 48% wa utafiti huu licha ya kiwango cha mafanikio cha kujiripoti cha 99% unaonyesha kuwa uhakiki hauwezi kuwa jambo la baadae.
  3. Zingatia bajeti ya token – Harness zilizo tata zaidi zinaweza kuongeza idadi ya token kwa kasi. Chunguza matoleo tofauti ya harness mapema ili kuepuka ongezeko la ghafla la gharama zilizofichika.
  4. Jaribu kwenye modeli mbalimbali – Endesha harness hiyo hiyo kwa kutumia mifumo mbalimbali ya LLM (back-ends). Ikiwa ufanisi utashuka sana, unaweza kuhitaji usanifu usioegemea modeli fulani (model-agnostic) au harness tofauti kwa kila modeli.

Hitimisho: HarnessDev inathibitisha kuwa LLMs zinaweza kuandika kodi yao ya udhibiti inayofanana na mifumo ya uendeshaji (operating systems).