Harness inženierija: kas tā ir un kā tā darbojas

Ko nozīmē harness inženierija

Harness inženierija ir darbs, kurā tiek veidots MI rīka harness, proti, visas rīka daļas, izņemot pašu MI modeli.

Modelis ir MI sistēma, kas apmācīta ar lieliem teksta apjomiem, lai tā prastu lasīt un rakstīt tekstu. MI modeļu piemēri ir OpenAI GPT, Anthropic Claude vai Google Gemini.

Pats par sevi modelis spēj tikai saņemt tekstu (un dažkārt attēlus vai audio) un atbildēt ar tekstu. Tas nespēj atcerēties iepriekšējās sarunas, meklēt aktuālu informāciju vai palaist kodu. Tāpēc tam ir nepieciešams harness, kas pārvalda, kādu informāciju modelis saņem, kuras lietotnes tas var izmantot, ko tam ir atļauts darīt un kā tiek pārbaudīts tā darbs.

Pat vienkāršam tērzēšanas asistentam ir nepieciešams harness. Modelis aizmirst katru apmaiņu, tiklīdz ir atbildējis, tāpēc harness saglabā sarunas vēsturi. Ja kāds jautā par Parīzi un pēc tam uzdod papildjautājumu: „Cik tajā ir iedzīvotāju?”, harness nosūta modelim abus jautājumus kopā. Tieši tā modelis zina, ka ar „tajā” domāta Parīze.

Harness inženierija ir viens no iemesliem, kāpēc divi rīki, kas balstīti uz viena un tā paša modeļa, var darboties tik atšķirīgi. Piemēram, kādā neatkarīgā testā pētnieki saglabāja to pašu modeli (GPT5) un mainīja tikai harness, un modeļa rezultāts programmēšanas testā mainījās pat par 11 %.

MI modeļu izstrādātāji, tādi kā Anthropic un OpenAI, veido harness saviem MI produktiem, piemēram, Claude Code un Codex. Savukārt uzņēmumi, kas veido MI produktus, izstrādā harness izvēlētajiem pamatmodeļiem. Arī MI rīku lietotāji veido daļu no harness. Daudzi rīki ļauj pievienot pastāvīgās instrukcijas, savienot lietotnes un izvēlēties, kurām darbībām nepieciešams viņu apstiprinājums, pirms rīks turpina darbu.

Harness inženierija MI aģentiem

Katram MI rīkam ir harness, taču harness inženierija kļūst īpaši svarīga, strādājot ar MI aģentiem. Aģenti patstāvīgi veic vairāku soļu uzdevumus, piemēram, izpēta konkurentus un apkopo atklājumus izklājlapā, un harness izpilda katru soli. Tāpēc, ja harness pieļauj kļūdu, piemēram, izgūst pagājušā gada cenas, tas ietekmēs arī visus turpmākos soļus.

Lielākajai daļai aģentu harness risinājumu ir sešas galvenās daļas:

1. Aģenta cikls

Izvērst

Aģenta cikls ir harness kods, kas soli pa solim virza uzdevumu uz priekšu.

MI modelis izlemj, kāds ir nākamais solis uzdevuma izpildei, un uzraksta rīka izsaukumu — īsu pieprasījumu, kurā norādīts harness rīks, piemēram, tīmekļa meklēšana, un tas, kas šim rīkam jādara.

Harness pamana pieprasījumu, palaiž meklēšanu un pievieno rezultātus tam, ko modelis var redzēt. Modelis tos izlasa un izlemj, ko darīt tālāk.

2. Konteksta pārvaldība

Modelis apgūst vispārīgas zināšanas apmācības laikā, taču šīs zināšanas aprobežojas ar datumu, kad apmācība beidzās. Tajās nav nekā tāda, kas attiektos tieši uz konkrēto uzdevumu, piemēram, uzņēmuma failu, šodienas ziņu vai sarunā iepriekš teiktā.

To visu modelim nodrošina konteksta logs — teksts, ko harness tam nodod pirms katras atbildes, piemēram, instrukcijas, vaicājums, līdzšinējā saruna un meklēšanas rezultāti.

Logā ietilpst tikai noteikts teksta apjoms. Turklāt pat pirms logs ir pilns, modeļi dažkārt palaiž garām informāciju, kas paslēpta garas ievades vidū.

Tāpēc harness pārvalda kontekstu un atlasa tikai to informāciju, kas nepieciešama katram solim. Piemēram, ja uzdevums ir salīdzināt piecu konkurentu cenas, harness var iekļaut katra uzņēmuma cenu lapu, nevis visu tā tīmekļa vietni. Ilgos uzdevumos harness var arī aizstāt detalizēto iepriekšējo soļu pierakstu ar īsu kopsavilkumu, lai modelis sekotu līdzi paveiktajam, bet šī vēsture neaizpildītu logu.

3. Rīki

Rīki ir kods, kas izpilda modeļa pieprasītās darbības. Katrs rīks veic viena veida darbību, piemēram, meklē tīmeklī, atver un lasa tīmekļa lapu, palaiž kodu vai rediģē failu. Kad modelis uzraksta rīka izsaukumu, harness to nodod pareizajam rīkam un atgriež rezultātu.

Daudzos harness risinājumos ir arī savienotāji — rīki, kas, izmantojot cilvēka piešķirtu piekļuvi, savieno aģentu ar konkrētu lietotni, piemēram, e-pastu, kalendāru vai koplietojamo disku. Piemēram, ar kalendāra savienotāju aģents var pārbaudīt, vai kāds ir pieejams, pirms ieteikt tikšanās laiku.

4. Atmiņa

Atmiņa ir saglabāta informācija, kas tiek pārnesta no vienas sesijas uz nākamo. Sesijas laikā harness saglabā īsas piezīmes, piemēram, par cilvēka vēlmēm vai projekta gaitu. Nākamās sesijas sākumā harness pievieno šīs piezīmes konteksta logam, lai modelis tās izlasītu pirms jaunā vaicājuma. Tādējādi aģents, piemēram, var turpināt darbu pie iknedēļas pārskata no vietas, kur to pārtrauca, nevis sākt visu no jauna.

5. Atļaujas

Atļaujas ir noteikumi par to, kam aģents var piekļūt un ko tas drīkst darīt. Piekļuves noteikumi nosaka, kurus failus, lietotnes vai tīmekļa vietnes tas var atvērt. Apstiprināšanas noteikumi nosaka, kurām darbībām jāgaida cilvēka apstiprinājums, piemēram, ziņojuma nosūtīšanai vai pirkuma veikšanai.

Uzņēmums, kas izstrādā aģentu, daļu šo noteikumu iestata harness kodā. Pēc tam organizācijas administratori var pievienot savus noteikumus, un atsevišķi lietotāji var izvēlēties, piemēram, kurus kontus pievienot.

6. Verifikācija

Verifikācija ir kods, kas pārbauda aģenta darbu, pirms tas nonāk pie cilvēka. Tā izmanto divu veidu pārbaudes:

• Fiksēti noteikumi — konkrēti testi, kuru iznākums katru reizi ir vienāds, piemēram, pārbaude, vai katrs pārskatā minētais skaitlis ir atrodams dokumentā, ko aģents patiešām izlasīja.
• Cita MI modeļa veikta pārbaude: šis modelis izlasa darbu un to izvērtē. Tā var atklāt problēmas, kuras grūti formulēt kā noteikumu, piemēram, kopsavilkumu, kurā izlaists svarīgs punkts.

Neviena atsevišķa pārbaude neatklāj visu, tāpēc harness risinājumi parasti apvieno abus veidus. Kad pārbaude atklāj problēmu, harness pievieno tās aprakstu modeļa konteksta logam un nosūta uzdevumu atpakaļ aģenta ciklā. Modelis novērš problēmu un mēģina vēlreiz, tāpēc daudzas kļūdas tiek izlabotas, pirms lietotājs redz rezultātu.

Harness inženierijas piemēri

Gatavošanās tikšanās reizei ar klientu

Uzdevums: Klientu vadītājs lūdz aģentu sagatavot apkopojumu rītdienas tikšanās reizei ar klientu, iekļaujot neatrisinātos jautājumus un darba kārtības projektu.

Ko dara harness:

• Izmantojot e-pasta savienotāju, aģents meklē vadītāja iesūtnē saraksti ar klientu.
• Atļaujas ļauj tam lasīt e-pastus, bet ne sūtīt tos.
• Konteksta pārvaldība nodod modelim tikai pēdējo trīs mēnešu saraksti ar šo klientu, nevis visu iesūtni.
• Aģenta cikls veic vairākas meklēšanas un lasīšanas kārtas, un modelis atrasto sagrupē pa neatrisinātajiem jautājumiem.
• Pēc tam verifikācija pārbauda, vai katram apkopojumā minētajam jautājumam ir atsauce uz reālu e-pasta ziņojumu.

Iespējamais rezultāts: Vadītājs saņem vienas lappuses apkopojumu, kurā katru punktu var izsekot līdz e-pasta ziņojumam, no kura tas iegūts.

Ikmēneša pārdošanas pārskata atjaunināšana

Uzdevums: Operāciju vadītājs lūdz aģentu atjaunināt ikmēneša pārdošanas pārskatu ar šī mēneša skaitļiem.

Ko dara harness:

• Atmiņa ielādē piezīmes no iepriekšējā mēneša sesijas, tostarp pārskata formātu un vadītāja lūgumu noapaļot skaitļus līdz tuvākajam tūkstotim.
• Failu rīks atver pārdošanas izklājlapu komandas koplietojamajā diskā.
• Atļaujas ļauj aģentam rediģēt pārskata melnrakstu, bet ne avota izklājlapu, tāpēc sākotnējos skaitļus nevar nejauši mainīt.
• Verifikācija pārbauda, vai kopsummas pārskatā atbilst izklājlapai.

Iespējamais rezultāts: Pārskats tiek sagatavots tādā pašā formātā kā iepriekšējā mēnesī, un lietotājam tas nav jāskaidro vēlreiz.

Koplietojamās iesūtnes kārtošana

Uzdevums: Atbalsta komanda lūdz aģentu sakārtot rītā saņemtos pieprasījumus pēc tēmām un sagatavot atbilžu melnrakstus biežākajiem no tiem.

Ko dara harness:

• Aģenta cikls apstrādā iesūtni pa vienam ziņojumam.
• Katram ziņojumam modelis izvēlas tēmas iezīmi, un harness to piešķir, izmantojot e-pasta savienotāju.
• Uzdevuma sākumā harness pievieno konteksta logam komandas apstiprinātās atbilžu veidnes kā paraugus, lai modelis katru melnrakstu veidotu, balstoties uz kādu no tām.
• Apstiprināšanas noteikums saglabā katru atbildi kā melnrakstu, līdz kāds no komandas to pārskata un nosūta.

Iespējamais rezultāts: Komanda sāk dienu ar sakārtotiem pieprasījumiem un atbildēm, kas gaida pārskatīšanu.

Kļūdas labošana tīmekļa vietnē

Uzdevums: Izstrādātājs lūdz programmēšanas aģentu izlabot kļūdu, kuras dēļ nedarbojas pirkuma noformēšanas poga.

Ko dara harness:

• Aģents strādā smilšu kastē — izolētā koda kopijā, kurā tā veiktās izmaiņas nevar ietekmēt publicēto tīmekļa vietni.
• Koda rīks ļauj modelim lasīt un rediģēt failus.
• Pēc katrām izmaiņām verifikācija palaiž projekta automatizētos testus.
• Visas kļūmes tiek nodotas atpakaļ modelim kā jauna informācija.

Iespējamais rezultāts: Aģents turpina pielāgot labojumu, līdz testi tiek izturēti. Pēc tam izstrādātājs pārskata izmaiņas, pirms tās tiek publicētas.

Harness inženierija, uzvedņu inženierija un konteksta inženierija: atšķirības

Uzvedņu inženierija ir viena vaicājuma izveide un optimizēšana. Konteksta inženierija ir visa tā pārvaldība, ko modelis redz. Harness inženierija ir visas tās sistēmas izstrāde un pilnveidošana, kurā darbojas modelis.

Kā lietotāji var ietekmēt MI harness

Lielāko daļu aģenta harness veido uzņēmums, kas izstrādā aģentu, taču daudzi MI produkti ļauj lietotājiem pielāgot tā daļu, izmantojot tādus iestatījumus kā pielāgotas instrukcijas, pievienotās lietotnes un apstiprinājumus.

Lietotāji var ietekmēt aģenta harness un uzlabot aģenta rezultātus četros veidos:

1. Pastāvīgās instrukcijas

Pastāvīgās instrukcijas ir piezīmes, ko cilvēks uzraksta vienreiz, lai harness tās varētu pievienot konteksta logam katra uzdevuma sākumā. Tās ir vērts iestatīt visam, ko cilvēkam citādi nāktos atkārtot vaicājumu pēc vaicājuma: kas viņš ir un ar ko nodarbojas, kādā stilā viņš vēlas, lai darbs tiktu uzrakstīts, vai kādi noteikumi attiecas uz regulāru darbu, piemēram, klienta ikmēneša pārskatu.

Daudzi MI produkti piedāvā pastāvīgās instrukcijas divos līmeņos. Visa konta instrukcijas ir piemērotas tam, kas attiecas uz visu darbu, piemēram, pareizrakstības preferencēm. Projekta instrukcijas ir piemērotas vienam klientam vai darbplūsmai, lai norādījumi vienam neattiektos uz citu.

Pastāvīgās instrukcijas tērzēšanas asistentos un aģentos darbojas vienādi, taču aģenti no tām ir atkarīgi vairāk. Tērzēšanā cilvēks var izlabot MI pēc katras atbildes. Aģents var veikt daudzus soļus, pirms kāds ierauga tā darbu, tāpēc iepriekš sniegtas instrukcijas ir viens no retajiem veidiem, kā to vadīt darba gaitā.

Kā rakstīt efektīvas pastāvīgās instrukcijas

• Sāciet ar īsu instrukciju, piemēram: „Esmu mārketinga vadītājs programmatūras uzņēmumā. Raksti vienkāršā angļu valodā, kopsavilkumos nepārsniedz 200 vārdus un izmanto ASV pareizrakstību.”
• Papildiniet tās, kad MI pieļauj kļūdu. Ja MI turpina noapaļot skaitļus, kas komandai vajadzīgi precīzi, pievienojiet rindiņu, kurā tas norādīts.
• Formulējiet instrukcijas konkrēti: „Norādi precīzus skaitļus, nekad tos nenoapaļo” ir labāk nekā „Esi precīzs”.
• Saglabājiet sarakstu īsu un dzēsiet rindiņas, tiklīdz tās vairs nav noderīgas, jo katra rindiņa aizņem vietu konteksta logā.

2. Pievienotās lietotnes

Pievienotās lietotnes savieno MI produktu ar rīkiem, ko cilvēks jau izmanto, piemēram, e-pastu, kalendāru vai koplietojamo disku. Kad lietotne ir pievienota, MI var strādāt ar paša cilvēka informāciju, nevis tikai ar to, kas ielīmēts tērzēšanā.

Savienojumus ir vērts iestatīt, ja uzdevums ir atkarīgs no informācijas, kas glabājas šajās lietotnēs, piemēram, ja jāsagatavo tikšanās apkopojums no e-pasta sarakstes vai jāapkopo dokumenti koplietojamajā diskā.

Kā droši pievienot lietotnes

• Pievienojiet tikai uzdevumam nepieciešamās lietotnes, jo katrs savienojums rada vēl vienu kļūdu iespēju.
• Ja iespējams, izvēlieties tikai lasīšanas piekļuvi. Piemēram, aģentam, kas gatavo tikšanās apkopojumus, e-pasts ir jālasa, nevis jāsūta.
• Ja produkts to atļauj, iestatiet savienojumus katram projektam atsevišķi. Piemēram, Perplexity lietotāji var izvēlēties, kurus savienotājus izmanto katrs projekts.
• Neaizmirstiet atvienot lietotnes, kuras vairs neizmantojat.

3. Apstiprināšanas iestatījumi

Apstiprināšanas iestatījumi nosaka, kurām darbībām jāgaida cilvēka apstiprinājums, pirms MI turpina darbu. Daži apstiprinājumi ir iebūvēti produktā, un dažos produktos lietotāji var izvēlēties, kurām vēl darbībām apstiprinājums ir nepieciešams.

Kā iestatīt apstiprināšanas noteikumus

• Pieprasiet apstiprinājumu darbībām, kuras nevar atsaukt, piemēram, ziņojuma nosūtīšanai, pirkuma veikšanai vai faila dzēšanai.
• Apstiprināmo darbību sarakstam jābūt īsam. Ja aģents lūdz apstiprinājumu katram sīkam solim, cilvēki sāk apstiprināt, pat neizlasot.

4. Standarti un pārbaudes

Lielākajai daļai MI produktu jau ir iebūvēti noteikti standarti. Piemēram, Perplexity savām atbildēm pievieno atsauces uz avotiem, lai katru apgalvojumu varētu pārbaudīt. Lietotāja noteiktie standarti papildina produktu ar to, ko tas pats nevar zināt, piemēram, komandas vēlamo pārskatu formātu.

Kā noteikt standartus MI darbam

• Sagatavojiet veidni atkārtotiem darbiem, lai MI būtu noteikta struktūra, ko aizpildīt.
• Kopīgojiet kādu iepriekšēja darba piemēru, kas komandai patika, lai MI varētu pielāgoties tā tonim un detalizācijas līmenim.
• Lūdziet blakus katram skaitlim norādīt saiti uz avotu.
• Rūpīgi pārskatiet pirmos rezultātus un, ja kāds trūkums atkārtojas, pārvērtiet to jaunā pastāvīgā norādījumā.

Perplexity pieeja aģentu harness izstrādei

Perplexity Computer darbojas ar no modeļiem neatkarīgu harness, kas apvieno vairāk nekā 20 progresīvus modeļus vienā sistēmā. Tas sadala katru uzdevumu apakšuzdevumos, nodod tos apakšaģentiem (atsevišķiem aģentiem, no kuriem katrs veic vienu daļu) un katru darba daļu novirza tam piemērotam modelim.

Uzziniet Perplexity projektu ceļvedī, kā iestatīt norādījumus, failus un savienotājus.

Bieži uzdotie jautājumi

Kas ir harness inženieris?

Harness inženieris izstrādā un uztur sistēmu, kas ļauj MI modelim uzticami veikt darbu. Tas var nozīmēt jauna rīka pievienošanu aģenta lietošanai, noskaidrošanu, kāpēc aģents atkārtoti pieļauj vienu un to pašu kļūdu, vai to pārbaužu pastiprināšanu, ko tas veic pirms uzdevuma pabeigšanas. Tas nav vispāratzīts amata nosaukums, lai gan tas varētu mainīties. Šo darbu parasti veic programmatūras inženieri MI uzņēmumos vai komandās, kas izstrādā aģentus. Ražošanā ar to pašu nosaukumu apzīmē speciālistu, kurš projektē vadu kūļus (angļu val. wire harnesses) — automašīnās un iekārtās izmantotos kabeļu saišķus.

Kas ir aģenta harness?

Ar aģenta harness parasti saprot visu MI aģentā, izņemot pašu modeli. Tas ietver kodu, kas izpilda aģenta ciklu, pārvalda kontekstu, veic rīku izsaukumus, glabā atmiņu, nodrošina atļauju ievērošanu un pārbauda aģenta darbu, pirms tas nonāk pie cilvēka.

Vai katram MI rīkam ir harness?

Jā. Pat vienkāršs tērzēšanas asistents paļaujas uz harness, lai sekotu sarunas gaitai, jo modelis pats neatceras iepriekšējos ziņojumus.

Izstrādātāji var arī sūtīt pieprasījumus modelim no savas programmatūras, izmantojot API (savienojumu, kas ļauj vienai programmai sūtīt pieprasījumus citai). Šādā gadījumā harness funkciju veic paša izstrādātāja kods.

Vai labāki modeļi padarīs harness nevajadzīgus?

Labākiem modeļiem varētu būt nepieciešams mazāk norādījumu soli pa solim, tāpēc daļa no tā, ko harness dara šodien, varētu sarukt. Taču modelis pats par sevi tikai pārvērš tekstu tekstā. Tam nav ne interneta savienojuma, ne piekļuves citām lietotnēm. Piekļuve failiem, darbību veikšana un apstiprināšanas noteikumu piemērošana notiek programmatūrā, kas darbojas ap modeli, tāpēc šis darbs, visticamāk, paliks harness ziņā neatkarīgi no tā, cik spējīgi kļūs modeļi.