Kā padarīt ChatGPT darbu ātrāk - 2026. gada februāris

IT profesionāļiem “ātrāks” reti nozīmē vienu. Dažreiz jūs vēlaties zemāku latentumu uz pieprasījumu incidenta laikā. Dažreiz jūs vēlaties lielāku caurlaidspēju atkārtotiem darbiem, piemēram, runbook izstrāde, apkopojot biļetes, radot testa gadījumus, vai rakstot fragmentus. Dažreiz jūs vēlaties ātrāku “no laika līdz izlietojamai izvades”, kas nozīmē mazāk atpakaļ un uz vietas pagriezienu un mazāk tīrīšanas. Labā ziņa ir tā, ka lielākā daļa uztver lēnumu nāk no nedaudzām kontrolējamām vājajām vietām: konteksta uzpūsties, modeļu izvēle, tīkla ceļš, klienta puses pieskaitāmās izmaksas, un neefektīvas darbplūsmas.

Šis ceļvedis koncentrējas uz praktiskiem veidiem, kā samazināt reakcijas laiku un palielināt caurlaidspēju, nezaudējot precizitāti. Tas ir rakstīts cilvēkiem, kuri jau domā par latentumu, SLOs, caching, derīgo kravu sizing, un darbības higiēnu. Ieteikumi attiecas uz to, vai izmantojat ChatGPT pārlūkā, darbvirsmas klientam vai caur API integrāciju iekšējos rīkos.

Definēt “ātrāks” tāpat kā jūs būtu jebkurai sistēmai

Pirms kaut ko mainīt, izlemt, ko jūs optimizēt: zemāka pirmā token latentums, kopējais pabeigšanas laiks, mazāk pagriezieni, vai augstāka paralēlā caurlaidspēja. Praksē tās visas var uzlabot, bet taktika atšķiras.

• Pirmā reize ļoti atkarīgs no modeļa izvēli, servera slodze, un tīkla apaļā-trip-time.
• Kopējais pabeigšanas laiks bieži dominē izejas garums un spriešanas dziļums.
• Mazāk pagriezienu nāk no tūlītēja struktūra, labāki ierobežojumi, un atkārtoti izmantojams veidnes.
• Caurlaides spēja uzlabo ar partiju, caching, un paralēli (īpaši caur API darbplūsmas).

Jūsu mijiedarbība, piemēram, pieprasījumi pakalpojuma tīkla: izmērīt, mainīt vienu mainīgo, un saglabāt piezīmes par to, kas faktiski palīdz. „Spalvas ātrāk” ir noderīgas, bet parasti var korelēt uzlabojumu ar mazākiem žetoniem, mazāku konteksta logu, tuvāku tīkla maršrutu vai vieglāku modeli.

Izvēlieties pareizo modeli darbam

Modeļa izvēle ir lielākā svira. Lielāki, dziļākas argumentācijas modeļi parasti nodrošina augstākas kvalitātes rezultātus, bet tie bieži vien aizņem ilgāku laiku, jo īpaši uz sarežģītiem uzvedumiem vai tad, kad jūs lūdzat daudzpakāpju argumentāciju. Ikdienas operāciju darbam pietiek ar vieglāku/ātrāku modeli, un jūs varat „eskalēt” tikai tad, kad nepieciešams.

Noderīgs darbības modelis ir “ātri pirmais, dziļi pēc pieprasījuma”: sākt ar ātru modeli un ierobežotu pieprasījumu, tad atkārtoti palaist tikai cietās daļas uz spēcīgāku modeli. Tas atspoguļo to, kā jūs maršrutu satiksmes: noklusējuma zemu izmaksu līmeni, vēlreiz mēģināt uz premium līmeni, kad atbildes kvalitāte neatbilst SLO.

• Lietot a ātrs modelis par: kopsavilkumi, pārrakstīšanas, formatēšana uz veidnēm, ātri problēmu risināšanas kontrolsaraksti, log modelis triage, vai izstrādājot iekšējo comms.
• Lietot a dziļš modelis par: dizaina lēmumiem, vairāku sistēmu pamatcēloņu analīzi, drošības pārskatiem, garas formas arhitektūras docs, vai jebko, kas prasa rūpīgu kompromisu pamatojumu.

Ja jūs izmantojat ChatGPT interaktīvi, turiet acu uz slēpto “kompleksa reizinātāji”: lūdzot pilnīgu aptvērumu, “iekļaujiet katru malu gadījumu,” “paskaidrot soli pa solim,” vai “salīdzināt desmit iespējas” var dramatiski palielināt laiku līdz pabeigšanai.

Samazināt konteksta izmēru, nezaudējot būtisko

Tērzēšanas modeļi ir jutīgi pret derīgās kravas lielumu. Lieli apstākļi palielina apstrādes laiku un var palēnināt gan reakcijas sākumu, gan vispārējo pabeigšanu. IT pros bieži ielīmē masīvus žurnālus, konfigurācijas failus, ugunsmūra noteikumus, steka pēdas un garus pavedienus. Triks ir saglabāt signālu, vienlaikus samazinot troksni.

Domājiet par savu tūlītēju kā incidentu ziņojumu: ietver tikai to, kas maina lēmumu. Ja jūs nevarētu ievietot detalizētu pēcnāves laika līniju, tas, iespējams, neietilpst sākotnējā pieprasījumā.

• Trimbaļķi pie attiecīgā loga: pirmā kļūda, pirmā kaskāde un īsa aste pēc neveiksmes. Dodiet priekšroku reprezentatīviem fragmentiem pār pilnām izgāztuvēm.
• Izņemt atkārtojumus: Daudzi žurnāli ir atkārtoti brīdinājumi vai identiskas steka pēdas. Saglabājiet vienu piemēru un skaitu.
• Sakļaut katlu plati: aizstāt garas sadaļas ar vietturi, piemēram, “(50 līnijas līdzīgu produkciju izlaista)”.
• Apkopot iepriekšējos pagriezienus: ja saruna ieguva ilgi, lūgt kompaktu valsts kopsavilkumu un turpināt no tā.

Uzticama pieeja ir skaidri definēt darba programmu: ” Izmantojiet tikai to informāciju, kas atrodama Simptomi kā arī Ierobežojumi iedaļas.” Tas palīdz fokusēt modeli un samazina iespēju, ka tas mēģina iekļaut neatbilstošu fonu.

Rakstīt uzvednes, piemēram, jūs rakstīt biļetes: strukturēts, tvērums, pārbaudāms

Prompt struktūra ir divu ātrumu priekšrocības: tas samazina modeļa neskaidrību (mazāk sekot-ups), un tas samazina summu, kas nepieciešama, lai izlemtu, ko vēlaties. Ātrākās atbildes notiek, kad modelis var nekavējoties kartēt savu pieprasījumu uz zināmu izejas formu.

Izmantojiet saskaņotu veidni, kuru jūs un jūsu komanda varat izmantot atkārtoti. Lūk, IT draudzīgu modelis:

Goal:
Context:
Constraints:
Inputs:
What I tried:
What I want back (format + length):
Success criteria:

Maziem ierobežojumiem var būt liela latentuma ietekme. Ja jūs zināt, ka vēlaties saņemt īsu atbildi, sakiet tā. Ja jūs vēlaties izpildāmu kontrolsarakstu, sakiet tā. Ja vēlaties optimizētu fragmentu, norādiet mērķa OS/versija/vide.

• Ierobežot izejas garumu: “Atbilde zem 200 vārdiem” vai “Iedod man īsu kontrolsarakstu.”
• Izvēlieties formātu: “Return YAML” / “Return JSON” / “Return a 3 soļu plānu.”
• Pin pieņēmumi: “Assume Ubuntu 24.04 un sistematizēts.” / “Assume Cloudflare proxy ir iespējota.”

Ja jūs bieži lūgt tāda paša veida artifact-incident veidnes, runbook soļi, mainīt plānu ziņojumus, drošības kontroles- saglabāt bibliotēku ātri makros. Tas ir ekvivalents ar Terraform moduļiem, nevis atjaunot infra ar roku katru reizi.

Beigt izdarīt modeļa minējumu: nodrošināt ierobežojumus priekšā

Modeļi palēnina, kad tiem ir nepieciešams izpētīt vairākas interpretācijas. Ātrākais ceļš ir viena interpretācija, viena izvades forma, viena mērķauditorija. Kad jūs neprecizējat, modelis dzīvžogi, paplašina, un piebilst atrunas, kas maksā laiku un žetonus.

Piemēri ierobežojumiem, kas paātrina lietas:

• “Focus par Windows 11 uzņēmuma galapunktiem, nevis mājas lietotājiem.”
• „Uzņem, ka dīkstāve nav atļauta; nodrošina nepārtrauktu izmaiņu pieeju.”
• “Mēs nevaram instalēt jaunus aģentus; ieteikt config-tikai mazināšanu.”
• „Tas ir par izmaiņu pieprasījumu; saglabā to formālu un kodolīgu.”

Ir arī vērts skaidri pateikt, ko nav darīt: “Neskaidrojiet pamati,” “Neietver fona,” vai “Skip definīcijas.” Jūs bieži redzēt tūlītēju samazinājumus produkcijas garumu un pabeigšanas laiku.

Izmantot divvadu darbplūsmu gariem vai sarežģītiem uzdevumiem

Kad jūs lūgt ilgu, detalizētu piegādi vienā piegājienā, jūs maksājat par ilgu paaudzes laiku un risku rework. Ātrāka darbplūsma ir sadalīt to “shape first, aizpildīt otrais.”

• Caurlaide A: pieprasīt īsu aprakstu, virsrakstus un nepieciešamo datu sarakstu. Tas ir ātri un ļauj jums labot virzienu nekavējoties.
• Pass B: pieprasīt pilnu saturu, izmantojot apstiprināto izklāstu un ierobežojumus. Tas samazina churn un uztur izejas vērsta.

IT ziņā jūs atšķirat saskarnes definīciju no ieviešanas. Tas samazina nelietderīgi aprēķināt, kas savukārt samazina jūsu gaidīšanas laiku.

Saglabāt sarunas īsu ar “snapshotting” valsts

Gari tērzēšanas pavedieni ir ērti, bet tie palielina konteksta izmēru un laika gaitā var palēnināt atbildes. Labs paņēmiens ir periodiski izveidot valsts momentuzņēmumu, ka jūs varat ielīmēt svaigu tērzēšanu.

Jautāt par kompaktu “nodošanas bloku”, kas ietver tikai to, kas ir svarīgi, piemēram: pašreizējais mērķis, vide, zināmi ierobežojumi, kas ir izmēģināts, un neatrisināti jautājumi. Tad turpiniet ar jaunu pavedienu, izmantojot tikai šo bloku.

Tas ir čats ekvivalents tīras istabas reprodukcijas gadījumā kļūdu ziņojumos. Jūs samazināt troksni, palielināt determinismu, un uzlabot ātrumu.

Optimizēt savu klientu: pārlūkprogramma, paplašinājumi, atmiņa, un cilnes

Ne visi “ChatGPT ir lēns” jautājumi ir servera pusē. Pārlūka veiktspēja var kļūt par ierobežojošu faktoru, jo īpaši ar smagiem paplašinājumiem, agresīviem privātuma rīkiem, reklāmas blokatoriem, kas traucē skriptiem, vai desmitiem tabs patērē RAM.

• Mēģināt citu pārlūka profilu bez paplašinājumiem. Tas ātri izolē klientu puses problēmas.
• Atslēgt smagsvara paplašinājumus uz laiku, īpaši tiem, kas injicē skriptus katrā lapā.
• Pārbaudīt aparatūras paātrinājumu iestatījumi, ja redzat UI aizkavēšanos vai aizkavētu mašīnrakstīšanu/izgudrošanu.
• Aizvērt resurssmagās cilnes un fona lietotnes garo sesiju laikā.

Ja jūsu organizācija izmanto SSL pārbaudi, DLP pilnvaras vai agresīvu filtrēšanu, jūsu TLS rokasspiediens un maršrutēšanas ceļš var pievienot latentumu. No IT viedokļa ir vērts pārbaudīt no tīra tīkla ceļa (kur politika ļauj) salīdzināt RTT un caurlaidspēju.

Pret tīklu kā atkarību no darbības rezultātiem

Tērzēšanas mijiedarbība ir jutīga pret latentumu. Daži simti milisekundes papildu RTT var padarīt pieredzi justies gausa, it īpaši, ja reizina vairākos pagriezienos. Ja jūs esat uz Wi-Fi ar traucējumiem vai buferbloat, problēma var izskatīties kā “AR ir lēns,” kad tas ir patiešām tīkls.

• Preferenciāli vadi vai spēcīgs Wi-Fi pārklājums garām sesijām un lielām derīgām slodzēm.
• Pārbaudīt DNS latentumu un vispārējo pakešu zudumu, ja atbildes jūtas nekonsekventa.
• VPN pieskaitāmo izmaksu novērošana; Daži VPN maršruti pievienot ievērojamu attālumu un džitter.
• Pārbaudīt MTU problēmas, kad jūs redzat stendi uz lielākiem pieprasījumiem, jo īpaši caur tuneļiem.

No problēmu risināšanas viedokļa, ātri sajukuma pārbaude ir salīdzināt uzvedību visos tīklos: korporatīvā LAN vs mobilo karsto punktu vs mājas ISP (kā atļauts ar politiku). Lielas atšķirības parasti nozīmē maršrutēšanu vai drošības starpprogrammatūra ietekmē veiktspēju.

Jautāt par straumēšanas stila izvadi, lai samazinātu uztverto latentumu

Svarīgs ir ātrums. Pat ja kopējais pabeigšanas laiks ir līdzīgs, tas jūtas ātrāk, ja noderīgs saturs parādās ātri. Ja iespējams, lūdziet “atbildi vispirms, sīkāku informāciju otrais”, lai jūs varētu sākt rīkoties nekavējoties.

Piemērs frāzes: “Iedod man visticamāk galveno cēloni un pirmās trīs pārbaudes, tad ietver izvēles dziļas piezīmes.” Tas rada priekšpielādētu reakciju, kas ir funkcionāli noderīga.

Izvairieties no “”token sprādzieni”” problēmu novēršanas pieprasījumiem

Daži ātri stili mudināt modeli, lai radītu milzīgus rezultātus: izsmeļošas matricas, ilgi salīdzinājumi, katra iespējamā komanda, vai multi-platformu rokasgrāmatas. Tas var būt noderīgi, bet tas ir lēni.

Ātrāka traucēšana uzvednes izskatās: fokusēta hipotēze + minimāli pārbaudes soļi + lēmumu pieņemšanas koks. Jūs vienmēr varat pieprasīt paplašināšanos filiālē, kas atbilst jūsu videi.

• “”Dodiet man top trīs iespējamos cēloņus un kā apstiprināt katru ātri.””
• „Nodrošināt minimālu lēmumu koku, kas der uz viena ekrāna.”
• „Uzskatām, ka mums ir tikai lasīšanas pieeja; ieteikt pārbaudes atbilstīgi.”

Izmantot kešošanu un atkārtotu izmantošanu atkārtotam darbam

Daudzas komandas izmanto ChatGPT atkārtojamiem uzdevumiem: iknedēļas statusa kopsavilkumi, biļešu šķirošana, izlaiduma piezīmes, politikas projekti, standarta darbības procedūras, un klientiem draudzīgi paskaidrojumi. Ja jūsu darbs atkārtojas, ātrumu rada tas, ka katru reizi netiek mainīti tie paši spriedumi.

• Saglabāt sagataves par parastiem artefaktiem un tos atkārtoti izmantot.
• Uzturēt kopīgotu “house stila” bloku tonis, formatēšana, un nepieciešamo sadaļu.
• Kanonisko fragmentu saglabāšana regulāriem paskaidrojumiem (MFA nogurums, pikšķerēšanas reakcija, lodziņi).
• Keša starprezultāti piemēram, apstiprinātās kontūras, produktu apraksti vai darbgrāmatu sadaļas.

Ja jūs būvējat iekšējo rīku, tā pati ideja attiecas uz: glabāt iepriekšējas atbildes taustiņu normalizētas ieejas, un zvanīt modeli tikai tad, kad kaut kas būtiski mainās. Caching joprojām ir viena no augstākajām ROI darbības stratēģijām 2026. gadā, pat attiecībā uz MI atbalstītām darbplūsmām.

Ja jūs izmantojat API, optimizēt kā reālu pakalpojumu

Komandas, kas integrē ChatGPT stila modeļus cauruļvados, latentums un caurlaidspēja kļūst par inženiertehniskām problēmām. Labākā prakse ir pazīstama ikvienam, kurš ir regulējis tīmekļa pakalpojumus: uzturēt savienojumus siltu, samazināt derīgās slodzes lielumu, plūsmu atbildes, kad vien iespējams, un īstenot backoff.

• Atkārtoti izmantot savienojumus un neradiet jaunu TLS sesiju katrā pieprasījumā, ja jūsu klients atbalsta apvienošanu.
• Masveida nelieli uzdevumi vajadzības gadījumā, nevis nosūta daudzus sīkus pieprasījumus.
• Iestatīt cietos ierobežojumus par maksimālo izvades garumu, lai novērstu izvairīšanās atbildes.
• Lietot retumus ar džiteru īslaicīgām neveiksmēm, nevis vairākkārtēju tūlītēju atkārtotu iesniegšanu.
• Log marķierierīces izmantošana un latentums pēc pieprasījuma, lai jūs varētu redzēt, kas faktiski vada izmaksas un ātrumu.

Ja jūs veidojat iekšējo asistentu jūsu org, apsveriet requireal slāni: tā vietā, lai sūtītu milzīgus docs katru reizi, noņemiet tikai atbilstošos gabalus (policijas, runbooks, KB raksti), tad nosūtiet šo mazo komplektu uz modeli. Izpildes ieguvumi parasti ir tūlītēji, un rezultāti kļūst konsekventāki.

Tune “kvalitāte pret ātrumu” pogas jūsu pieprasījumos

Pat nepieskaroties API parametriem, jūs varat kontrolēt kvalitātes pret-ātrumu ar to, kā jūs jautājat. Ja jūs vēlaties ātrāk atbildēt, samazināt darbības jomu un samazināt pieprasījumu pēc izsmeļošu pamatojumu. Ja vēlaties maksimālu kvalitāti, pieņemiet, ka tas var aizņemt ilgāku laiku.

Pieprasījuma piemēri par ātruma samazināšanu:

• “Iedod man ātru ieteikumu ar galveno kompromisu.”
• „Attiecībā uz uzņēmumu vidi aptver tikai visticamāko scenāriju.”
• „Atkārtot īsu kontrolsarakstu, nav paskaidrojumu.”

Kvalitatīvu risinājumu piemēri:

• “Iekļaujiet malu gadījumus un kļūmes režīmus.”
• „Salīdziniet pieejas un pamatojiet ieteikumu.”
• „Iesniegt riska novērtēšanas un mazināšanas plānu.”

Svarīgajai daļai ir jābūt skaidrai. Ambiguitāte bieži izraisa lēnāku, garāku, piesardzīgāku reakciju.

Izmantot “atbildes ierobežojumus”, lai novērstu nevajadzīgu paplašināšanos

IT speciālistiem bieži ir nepieciešami izvadi, kas iederas esošajās sistēmās: biļešu komentāri, izmaiņu pieprasījumi, KB ieraksti, Jira apraksti vai Markdown nolaižamās grāmatiņas. Ja modelis nezina mērķa konteineru, tas mēdz pārspīlēt.

Pievienot šādus ierobežojumus:

• “Norādiet to kā izmaiņu pieprasījuma kopsavilkumu zem 1200 zīmēm.”
• „Izlaidei jābūt derīgai JSON ar šīm atslēgām.”
• “Format kā Slack ziņu ar īsu virsrakstu un trīs lodes.”
• “Atgriezt tikai komandas, bez komentāriem.”

Jūs samazināt gan pabeigšanas laiku un pēcredit laiku, kas bieži vien ir lielāka produktivitāte uzvarēt.

Apstrādāt lielus dokumentus ar gabalu un vadības plakni

Lieli dokumenti var palēnināt visu uz leju, ja jūs ielīmēt tos neapstrādātu. Ātrāka metode ir uzskatīt modeli par darba ņēmēju un jūs kā kontroles plakne: pabarot to gabalus ar skaidriem norādījumiem, pēc tam apvienot izejas.

Praktiska darbplūsma ilgiem politikas dokumentiem vai pārdevēja līgumiem:

• Sūtīt vienu sadaļu vienlaicīgi un lūgt strukturētu kopsavilkumu konsekventā shēmā.
• Saglabājiet darbojas “fakti iegūti līdz šim” bloku, ka jūs saglabāt ārēji.
• Beigās lūdziet sintēzi, izmantojot tikai iegūto faktu bloku, nevis visu sākotnējo tekstu.

Tas uzlabo ātrumu, samazina konteksta izmēru un atvieglo korektuma apstiprināšanu. Tas atspoguļo arī to, kā jūs apstrādātu datus sadalītās sistēmās: karti, tad samazināt.

Saglabājiet “zināms-labs” ātra komplekta jūsu komandai

Komandas zaudē laiku, kad visi no jauna izgudro uzvedas. Izveidot nelielu iekšējo bibliotēku “zināms-labi” veidnes jūsu visbiežāk uzdevumi: incidentu comms, post mortems, iknedēļas kopsavilkumi, riska novērtējumi, sacietēšanas kontrolsaraksti, un pārdevējs salīdzinājumiem.

Labs tūlītējs komplekts ietver:

• Nepieciešams ievads (ko ielīmēt un ko izlaist).
• Mērķa formāts (kurām iedaļām jābūt klāt).
• Standarta ierobežojumi (garums, tonis, auditorija).
• Validācijas noteikumi (kas ir taisnība rezultātu).

Tas samazina kognitīvās pieskaitāmās izmaksas un paātrina rezultātus, jo uzvedumi kļūst paredzami. Prognozējamie resursi nodrošina prognozējamus rezultātus, un paredzamiem rezultātiem ir vajadzīgs mazāks atkārtojumu skaits.

Kad tas ir patiesi lēni, traucējums atvašu metodiski

Ja sniegums pēkšņi degradējas, tuvojas tam tāpat kā jebkurš cits pakalpojumu regresiju. Mērķis ir nošķirt, vai palēninājums ir lokāls (klients), tīkls, konts/sesija vai platforma.

• Iztīrīt pārlūka profilu ar izslēgtu paplašinājumu.
• Pārslēgt tīklus īsi salīdzināt sākotnējo RTT un stabilitāti.
• Mēģināt mazāku uzvedni lai redzētu, vai derīgās kravas lielums ir trigeris.
• Sākt jaunu čatu samazināt konteksta loga slodzi.
• Salīdzināt modeļa iespējas pārbaudīt, vai jūs netīši izmantojat smagāku modeli vienkāršam darbam.

Uzņēmumu vidē, arī apsvērt drošības kontroles, kas var pievienot latentumu: SSL pārbaude, starpniekservera ķēdes, vai saturs skenēšana. Ja politika atļauj, apstiprināt ar tīkla komandu un vākt laika datus (DNS lookup, TCP connect, TLS handhake, first-bayte time). Attieksme it kā jūs būtu SaaS veiktspējas jautājumu.

Praktisks “ātrā režīma” kontrolsaraksts IT profesionāļiem

Kad jums ir nepieciešams ātrums tieši tagad, izmantojiet standartizētu "ātrā režīmā" pieeju:

• Sākt jaunu pavedienu un ielīmēt tikai minimālo kontekstu.
• Vispirms pajautājiet īsu atbildi, pēc tam pēc izvēles paplašiniet.
• Izmantojiet ātrāku modeli pirmajai caurlaidei un saasināt tikai nepieciešamības gadījumā.
• Ierobežot izvades garumu un norādīt precīzu formātu jums ir nepieciešams.
• Trim žurnālus un konfigurācijas uz attiecīgajām līnijām; noņemt atkārto.
• Atslēgt smago svaru pārlūka paplašinājumus, ja UI atpaliek.
• Pārbaudiet tīkla stabilitāti, VPN maršrutēšanu un proxy gaisvadu.

Lielākā daļa komandu konstatē, ka šie soļi ievērojami samazina reakcijas laiku un, kas ir vēl svarīgāk, samazina laiku, kas pavadīts atkārtojoties. Ātrākā darbplūsma ir tā, kas sasniedz pareizu, izmantojamu produkciju mazāk pagriezienos.

Aizverošas domas

Padarot ChatGPT “darbs ātrāk” galvenokārt ir par klasiskās inženierijas instinktu piemērošanu: samazināt derīgo slodzi, noņemt neskaidrību, izvēlēties pareizo līmeni darbam, un optimizēt savu klientu un tīkla ceļu. Apvienojot šos ar atkārtoti izmantojamām veidnēm un divvirzienu darbplūsmu, jūs iegūstat saliktu produktivitātes efektu.

Galvenais domāšanas veida maiņa IT profesionāļiem ir uzskatīt MI mijiedarbību kā sistēmu: ieejas, ierobežojumi, rezultāti, un izmērāmu sniegumu. Kad jūs to darāt, ātruma uzlabojumi kļūst paredzami un atkārtojami – tieši tā, kā jūs vēlētos tos ražošanas vidē.