Mbali na Prototype: Mafunzo ya 15 ya Kufanikiwa kwa Wafanyabiashara wa AI

Mwongozo kwa wahandisi na watengenezaji wa AI Kwa kawaida huanza na mistari kadhaa ya Python na kifungo cha API cha ChatGPT. Unaongeza mistari kadhaa ya mazingira, hit run, na kushangaa kwamba inajibu kabisa. Kisha, unataka kufanya kitu muhimu. Kisha, kwa uaminifu. Kisha, bila wewe. Hiyo ni wakati unajua kwamba wewe si tena tu kuita LLM. Wewe ni kujenga mfanyakazi. Nimekuwa nikitumia mwaka uliopita kuunganisha script na vifungo, kuchanganya mstari wa LangChain ambao ulihisi zaidi kama nyumba ya kadi kuliko mifumo, na daima kujiuliza, " ” Kwa kweli, watu wanatumia vitu hivi kwa namna gani? Nilifuata mifano ambayo ilionekana kifahari katika nadharia lakini ilipoteza wakati watumiaji halisi walionekana.Niliunda wafanyabiashara ambao walifanya kazi kikamilifu katika notebook na kushindwa kwa mafanikio katika uzalishaji.Niliendelea kufikiri repo ijayo, chombo ijayo, mfumo ujao utayarisha kila kitu. Haikuwa hivyo. Niliwasaidia kupunguza kasi, kuondoa mambo nyuma, na kuzingatia kile kilichofanya kazi chini ya mzigo, sio kile kilichokuwa na akili kwenye LinkedIn. Ikiwa umewahi kupitia changamoto sawa, imeandikwa kwako. Mwongozo huu ni destillation ya uwazi huu uliopatikana kwa uangalifu Fikiria kama mwongozo wa kimapenzi wa kuhamia kutoka kwa vifungo vya API na mizinga kwa mifumo ya imara, ya kudhibiti, ya AI. Sehemu ya 1 - Kupata msingi wa haki Prototypes ya mapema ya mfanyabiashara mara nyingi huja pamoja haraka: kazi chache, maombi kadhaa, na hapa, inafanya kazi. Unaweza kuuliza, "Ikiwa inafanya kazi, kwa nini kufanya mambo kuwa magumu?" Mwanzoni, kila kitu kinahisi imara: mfanyabiashara anajibu, kuendesha msimbo, na kuendesha kama ilivyotarajiwa. Lakini mara moja unabadilisha mfano, kurejesha mfumo, au kuongeza interface mpya, mambo hutoweka. : usimamizi mbaya wa kumbukumbu, thamani za hardcoded, hakuna ufuatiliaji wa mstari, au kiwango cha kuingia cha rigid. Kwa kawaida, tatizo sio mantiki au mapendekezo; ni ya kina zaidi Sehemu hii inajumuisha kanuni nne muhimu ili kukusaidia kujenga msingi mkali, msingi ambapo mfanyabiashara wako anaweza kuongezeka na kupanua kwa uaminifu. 1 - Uhamiaji wa nchi : The Problem Huwezi kuendelea ikiwa mfanyabiashara anapojeruhiwa, kushuka, wakati wa kuondoka, kitu chochote. Utambulisho: Unataka kucheza tena kile kilichotokea kwa ajili ya majaribio na udhibiti. Changamoto ya ziada: mapema au baadaye, utahitaji kuendesha sehemu za mfanyabiashara kwa pamoja, kama vile kulinganisha chaguzi katikati ya mazungumzo au mantiki ya ufundi (Utawala wa kumbukumbu ni mada tofauti tutakachunguza hivi karibuni.) Weka hali zote nje ya agensi, kwenye database, cache, kiwango cha kuhifadhi, au hata faili rahisi ya JSON. The Solution : Your Checklist Agent huanza kutoka hatua yoyote kwa kutumia tu session_id na hali ya nje (kwa mfano, imehifadhiwa katika DB au JSON). Unaweza kuacha na reboot Agent wakati wowote (hata baada ya mabadiliko ya msimbo) bila kupoteza maendeleo au kuharibu tabia. Hali ni kikamilifu serializable bila kupoteza utendaji. Hali moja inaweza kuhifadhiwa kwa matukio kadhaa ya mfanyabiashara yanayotendeka parallel wakati wa mazungumzo. 2 - Utoaji wa Maarifa LLMs kwa kweli hawawezi kukumbuka. Hata katika kikao kimoja, wanaweza kusahau kile ulichosema, kuchanganya hatua za mazungumzo, kupoteza thread, au kuanza "kujaza" maelezo ambayo hayakuwa huko. The Problem Mfano unazingatia mwanzo na mwisho, kupoteza maelezo muhimu ya katikati. Zaidi ya tokens gharama pesa zaidi. Hatua bado inapatikana: transformers kazi kwa makini kwa ugumu wa O(n2), hivyo mazingira isiyo na mwisho ni haiwezekani. Hii inaweza kuwa ngumu zaidi wakati: Mazungumzo ya muda mrefu Nyaraka ni kubwa sana Maelekezo ni ngumu : Kuacha "ukumbusho wa kazi" kutoka "ukumbusho", kama katika kompyuta za jadi. mfanyabiashara wako anapaswa kushughulikia kumbukumbu ya nje: kuhifadhi, kutafuta, kuunganisha, na kuboresha maarifa nje ya mfano mwenyewe. The Solution : Common approaches Buffer ya kumbukumbu: kuhifadhi ujumbe wa mwisho wa k. Haraka ya prototyping, lakini hupoteza habari ya zamani na haina kupanua. Ufafanuzi wa kumbukumbu: hupunguza historia ili kuingia zaidi katika mazingira. Hifadhi tokens lakini hatari ya uharibifu na kupoteza nuance. RAG (Retrieval-Augmented Generation): inachukua ujuzi kutoka kwenye database ya nje. Inapatikana, nyepesi, na inaweza kuthibitishwa, lakini ni ngumu zaidi na inahusiana na latency. Graphs ya ujuzi: uhusiano uliojengwa kati ya ukweli na viumbe. Elegance na kuelezea, lakini ngumu na vikwazo vya juu vya kuingia. : Your Checklist Historia yote ya mazungumzo ni kuhifadhiwa nje ya mwongozo na inapatikana. Vyanzo vya ujuzi ni kurekodiwa na kutumika tena. Historia inaweza kukua kwa muda usiojulikana bila kupiga mipaka ya dirisha la mazingira. 3 - Kufanya Mfumo wa Swappable : LLMs kuendeleza haraka: OpenAI, Google, Anthropic, na wengine daima update mifano yao. Kama wahandisi, tunataka kutumia katika maboresho haya haraka. mfanyabiashara wako inapaswa kubadilisha kati ya mifano kwa urahisi, kama kwa utendaji bora au gharama ya chini. Problem : Solution Tumia kiwango cha model_id katika configs au variables ya mazingira ili kufafanua mifano ambayo inaweza kutumika. Kujenga interfaces abstract au darasa la wrapper ambayo inazungumza na mifano kupitia API ya pamoja. Kwa chaguo, kutumia ngazi za middleware kwa makini (frameworks zinakuja na udanganyifu). : Checklist Kubadilisha mfano haina kuvunja msimbo wako au kuathiri vipengele vingine kama kumbukumbu, orchestration, au zana. Kuongeza mfano mpya inamaanisha tu update config na, kama inahitajika, kuongeza kiwango rahisi cha adapter. Mabadiliko ya mifano ni ya haraka na ya haraka - bora kwa msaada wa mifano yoyote, au angalau kubadilisha kwa urahisi ndani ya familia ya mifano. 4 - Agent moja, vituo vingi : Hata kama mfanyabiashara wako huanza na interface moja (tazama, UI), watumiaji watahitaji njia zaidi ya kuingiliana: Slack, WhatsApp, SMS, labda hata CLI kwa ajili ya udanganyifu. Problem Tengeneza mkataba wa kuingia wa kipekee, API, au interface ya jumla ambayo vituo vyote vinahifadhi. Solution : Checklist Agent inafanya kazi kupitia CLI, API, UI, au interface nyingine yoyote Kila input funnel kupitia hatua moja ya mwisho, parser, au schema Kila interface inatumia muundo wa kuingia sawa Hakuna mantiki ya biashara inayoishi ndani ya adapter yoyote ya channel Kuongezea njia mpya inamaanisha tu kuandika adapter - hakuna mabadiliko ya msimbo wa msingi Sehemu ya 2 - Mbali na Chatbot Mode Ingawa kuna kazi moja tu, kila kitu ni rahisi, kama katika machapisho ya watu wenye ushawishi wa AI. Lakini mara tu unapoongeza zana, mantiki ya uamuzi, na hatua nyingi, mfanyabiashara huwa katika msiba. Inapoteza kufuatilia, haijui nini cha kufanya na makosa, inasahau kuita chombo sahihi, na wewe unaachwa peke yako tena na kumbukumbu, ambapo "ndio, kila kitu inaonekana kuandikwa huko." Ili kuepuka hili, mfanyabiashara anahitaji mfano wazi wa tabia: kile anachofanya, zana gani ina, nani hufanya maamuzi, jinsi wanadamu wanaingilia kati, na nini cha kufanya wakati kitu kinatokea vibaya. Sehemu hii inashughulikia kanuni tano muhimu ili kukusaidia kuhamisha mfanyakazi wako zaidi ya chatbot rahisi, kujenga mfano wa tabia unaounganishwa ambao unaweza kutumia zana kwa uaminifu, kusimamia makosa, na kutekeleza kazi ngumu. 5 — Design for Tool Use : Inaweza kuonekana wazi, lakini wafanyabiashara wengi bado wanategemea "Plain Prompting + Raw LLM output parsing." Ni kama kujaribu kurekebisha injini ya gari kwa kurekebisha boulders. Problem Ugumu: Mabadiliko madogo katika maneno au utaratibu wa maneno yanaweza kuharibu uchambuzi wako, kuunda mapigano ya silaha ya daima kati ya msimbo wako na kutokuwa na utabiri wa mfano. Msimamizi Mjerumani akamwauliza kijana mwenyeji je jina la mahali ni nini? Uhifadhi wa ugumu: Parsing code inapigwa na vigumu kurekebisha. Kila mfanyabiashara mpya "juzi" inamaanisha kuandika sheria zaidi ya parsing. Uwezo mdogo: Ni vigumu kuita zana nyingi kwa uaminifu au kupitisha miundo ya data ngumu kupitia maandishi ya kawaida. Acha mfano kurudi JSON (au muundo mwingine wa muundo wa muundo), na acha mfumo wako kukabiliana na utekelezaji. Hii inamaanisha LLMs kutafsiri nia ya mtumiaji na kuamua kufanya, na kanuni yako inachukua huduma ya hufanyika, kutekeleza kazi sahihi kupitia interface iliyoelezwa vizuri. Solution nini jinsi ya Wengi wa watoa huduma (OpenAI, Google, Anthropic, nk) sasa kuunga mkono au : function calling structured output Unafafanua zana zako kama Mipango ya JSON na jina, maelezo, na vigezo. Maelezo ni muhimu kwa sababu mfano unategemea. Kila mara unapoita mfano, unatoa mipangilio haya ya zana pamoja na mwongozo. Mfano hutoa JSON inayofafanua: (1) kazi ya kuita, (2) Parameters kulingana na mpango Msimbo wako unathibitisha JSON na huita kazi sahihi na vigezo hivi. Kwa chaguo, matokeo ya kazi inaweza kupelekwa nyuma kwenye mfano kwa kuzalisha majibu ya mwisho. Maelezo ya chombo ni sehemu ya mwongozo. Ikiwa hayajulikani, mfano unaweza kuchagua chombo sahihi. Nini ikiwa mfano wako haukubali wito wa kazi, au unataka kuepuka? Important Kuuliza mfano wa kuzalisha matokeo ya JSON kupitia uhandisi wa haraka na kuthibitisha kwa maktaba kama Pydantic. Hii inafanya kazi vizuri lakini inahitaji ufafanuzi wa makini na usindikaji wa makosa. : Checklist Majibu ni iliyoundwa kwa usahihi (kwa mfano, JSON) Interfaces za zana zinafafanuliwa na mipangilio (JSON Schema au Pydantic) Matokeo yanatambuliwa kabla ya utekelezaji Makosa katika muundo haina kushindwa mfumo (kusimamia makosa ya ajabu) LLM huamua ni kazi gani ya kuita, msimbo hufanya utekelezaji 6 - Weka mantiki ya udhibiti katika msimbo Wengi wa wawakilishi wa leo wanaofanya kama chatbots: mtumiaji anasema kitu, wawakilishi anajibu. Problem: Kwa usanidi huu, mfanyabiashara wako hawezi: Kufanya kazi mwenyewe bila ya user prompt Kuendesha kazi kwa njia ya parallel Mpango na mfululizo wa hatua nyingi Retry kushindwa hatua kwa busara Kazi katika background Inakuwa reactant badala ya proactive. Mtu ambaye anazingatia kazi inayofuata, anajua nini cha kufanya baadaye, na huendesha mbele bila kusubiri kukatwa. What you really want is an agent that thinks like a scheduler Hii inamaanisha kwamba mfanyakazi wako anapaswa kuwa na uwezo wa: Tumia mwanzo wa Chain ya hatua nyingi pamoja Kurejesha kutoka kwa kushindwa Mabadiliko kati ya kazi Endelea kufanya kazi, hata wakati hakuna mtu anayeangalia Modeli bado inaweza kusaidia (kwa mfano, kuamua ni hatua gani inayofuata), lakini sequencing halisi, retries, na mantiki ya utekelezaji inapaswa kuishi katika msimbo. Solution: Hii inafuta kazi yako kutoka ya Mfano unakuwa kipande kimoja cha usanifu zaidi, sio bibi wa doll. prompt engineering Mfumo wa kubuni Let’s break down three ways teams are approaching this shift. 1. Finite State Machine (FSM) Break the task into discrete states with defined transitions. What it is: Acts within a state or helps pick the next one. LLM role: Ni bora kwa: mtiririko wa linear, utabiri. Simple, stable, easy to debug. Pros: Zana: StateFlow, YAML configs, mifano ya kawaida ya hali katika nambari. 2. Directed Acyclic Graph (DAG) Represent tasks as a graph — nodes are actions, edges are dependencies. What it is: Acts as a node or helps generate the graph. LLM role: Branching flows, parallel steps. Best for: Faida: Flexible, Visual, nzuri kwa rekodi ya sehemu. Zana: LangGraph, Trellis, LLMCompiler, au DIY na graph lib. 3. Planner + Executor One agent (or model) builds the plan; others execute it step by step. What it is: Jukumu la LLM: mipango ya mifano kubwa, ndogo (au msimbo) kutekeleza. Modular systems, long chains of reasoning. Best for: Faida: Usambazaji wa wasiwasi, kupanua, gharama nafuu. LangChain’s Plan-and-Execute, or your own planner/executor architecture. Tools: Why This Matters Unapata udhibiti juu ya tabia ya mfanyakazi Unaweza kurekebisha, kurekebisha, na kujaribu hatua binafsi Unaweza kupanua sehemu kwa kujitegemea au kubadilisha mifano You make things visible and traceable instead of opaque and magical Checklist Agent follows the FSM, DAG, or planner structure LLM inapendekeza vitendo lakini haitoi mtiririko You can visualize task progression Utaratibu wa makosa unachukuliwa katika logic ya mtiririko 7 — Keep a Human in the Loop Even with tools, control flow, and structured outputs, full autonomy is still a myth. LLMs don’t Hawawezi kuwajibika.Na katika ulimwengu halisi, watatoa wito usio sahihi (kabla au baadaye). Problem: understand When agents act alone, you risk: deleting records, messaging the wrong person, sending money to a dead wallet. Irreversible mistakes: Matatizo ya ufuatiliaji: ukiukwaji wa sera, sheria, au kanuni za msingi za kijamii. Tabia ya ajabu: kuepuka hatua, kufanya vitendo vya hallucinating, au tu kufanya kitu ambacho hakuna binadamu angeweza kufanya. : users won’t rely on something that seems out of control. Broken trust Hakuna uwajibikaji: wakati unaanguka, haijulikani ni nini kilichotokea au nani anamiliki msiba. Solution: Bring Humans Into the Loop (HITL) Fanya mwanadamu kama co-pilot, si kukimbia nyuma. ya au ya decisions to a person when needed. Not everything should be fully automatic. Sometimes, “Are you sure?” is the most valuable feature you can build. Maisha ya Maswali ya route Ways to Include Humans Njia muhimu au isiyo ya kurudi (kwa mfano, kutuma, kufuta, kuchapisha) inahitaji uthibitisho wa wazi wa binadamu. When the model’s confidence is low or the situation is ambiguous, route to a human for review. Escalation paths: Utaratibu wa Interactive: Uwezesha watumiaji kuchunguza na kuhariri majibu ya mfano kabla ya kutumwa. Mzunguko wa maoni: Kurekebisha maoni ya binadamu ili kuboresha tabia ya mfanyabiashara na kufundisha mifano kwa muda (Ufundishaji wa Kuimarisha kutoka kwa Maoni ya Binadamu). Enable humans to interrupt, override, or re-route the agent’s workflow. Override options: Checklist Vitendo vya kibinafsi vinathibitishwa na mwanadamu kabla ya utekelezaji There’s a clear path to escalate complex or risky decisions Watumiaji wanaweza kuhariri au kukataa matokeo ya agensi kabla ya kuwa mwisho Logs and decisions are reviewable for audit and debugging The agent explains it made a decision (to the extent possible) why 8 — Feed Errors Back into Context Most systems crash or stop when an error happens. For an autonomous agent, that’s a dead end. But blindly ignoring errors or hallucinating around them is just as bad. Problem: What can go wrong: Ugumu: Kila kushindwa, iwe ni makosa ya chombo cha nje au output ya LLM isiyotarajiwa, inaweza kuharibu mchakato mzima. Frequent restarts and manual fixes waste time and resources. Inefficiency: Without awareness of its own errors, the agent can’t improve or adapt. No Learning: Errors unaddressed can lead to misleading or fabricated responses. Hallucinations: Treat errors as part of the agent’s context. Include them in prompts or memory so the agent can try self-correction and adapt its behavior. Solution: How it works: Capture error messages or failure reasons clearly. Understand the error: Usimamizi wa kujitegemea: Mwakilishi anazingatia makosa na anajaribu kurekebisha kwa: (1) kugundua na kutambua tatizo, (2) kurekebisha vigezo, kurekebisha maombi, au kubadilisha zana, (3) kurekebisha hatua na mabadiliko. Maelezo ya kina ya makosa (kama vile maelekezo au maelezo) husaidia mfanyabiashara kurekebisha mwenyewe bora. Mafunzo ya kurekebisha mwenyewe: Kuingiza mifano ya kurekebisha makosa katika mafunzo ya mfano ili kuboresha uvumilivu. If self-correction repeatedly fails, escalate to a human (see Principle 7). Human escalation: Checklist: Makosa kutoka hatua zilizopita ni kuhifadhiwa na kuhifadhiwa katika mazingira Retry logic is implemented with adaptive changes Repeated failures trigger a fallback to human review or intervention 9 — Split Work into Micro-Agents Kazi kubwa na mbaya zaidi, lango la muda mrefu, na uwezekano mkubwa wa LLM ni kupoteza mandhari. kazi ngumu na maelfu ya hatua kuwashawishi mfano kwa njia ya kipande chake cha mchanga, kusababisha mchanganyiko, tokens kupoteza, na usahihi mdogo. Problem: Divide and conquer. Use Kila mmoja anawajibika kwa kazi moja iliyoelezewa wazi.Mshambuliaji wa ngazi ya juu huwapa pamoja. Solution: small, purpose-built agents Why small, focused agents work : shorter windows keep the model sharp. Manageable context Usajili wa wazi: mfanyabiashara mmoja, kazi moja, ukosefu wa uwazi. simpler flows mean fewer places to get lost. Higher reliability: you can unit-test each agent in isolation. Easier testing: when something breaks, you know exactly where to look. Faster debugging: Hakuna formula ya kichawi kwa wakati wa kugawana mantiki; ni sehemu ya sanaa, sehemu ya uzoefu, na mipaka itaendelea kubadilika kama mifano inazidi kuboresha. Checklist Mzunguko wa kazi wa jumla ni mfululizo wa wito wa micro-agent. Kila mfanyabiashara anaweza kurejeshwa na kujaribu mwenyewe. Unaweza kuelezea ufafanuzi wa mfanyabiashara katika maneno 1-2. Sehemu ya 3 - Kuimarisha tabia Wengi wa makosa ya mfanyabiashara si kuonekana kama makosa ya rangi; wao kuonekana kama matokeo ya ajabu. maelekezo iliyopoteza. muundo wa nusu-fuata. kitu ambacho karibu kazi ... mpaka haina. That’s because LLMs don’t read minds. They read tokens. The way you frame requests, what you pass into context, and how you write prompts, all of it directly shapes the outcome. And any mistake in that setup becomes an invisible bug waiting to surface later. This is what makes agent engineering feel unstable: . Ikiwa huna tahadhari, kila mwingiliano hupoteza mwelekeo Sehemu hii ni juu ya kuimarisha loop hiyo ya maoni. Prompts si viwambo vya kutupa, ni msimbo. Mtazamo sio uchawi, ni hali ambayo unaweza kusimamia wazi. Na uwazi sio chaguo, ni tofauti kati ya tabia ya kurudia na nonsense ya ubunifu. 10 — Treat Prompts as Code Miradi nyingi zinachukuliwa kama maneno ya moja kwa moja: yameandikwa ngumu katika faili za Python, yameenea katika msingi wa msimbo, au yamechukuliwa kwa usahihi katika Notion. Problem: Ni vigumu kupata, kuboresha, au hata kuelewa kile kila mwongozo hufanya Hakuna udhibiti wa toleo - hakuna njia ya kufuatilia kile kilichobadilika, wakati, au kwa nini Optimization inakuwa ghadhabu: hakuna vipengele vya maoni, hakuna majaribio ya A / B Na kurekebisha tatizo linalohusiana na prompt inaonekana kama kujaribu kurekebisha bug katika maoni Msimamizi Mjerumani akamwauliza kijana mwenyeji je jina la mahali ni nini? Solution: Utaratibu wa Weka tofauti kutoka kwa mantiki yako: kuhifadhi katika txt, .md, .yaml, .json au kutumia injini za template kama Jinja2 au BAML with your repo (just like functions) Version them : (1) Unit-test responses for format, keywords, JSON validity, (2) Run evals over prompt variations, (3) Use LLM-as-a-judge or heuristic scoring to measure performance Test them Fanya mapitio ya haraka kama mapitio ya msimbo. Ikiwa mabadiliko yanaweza kuathiri tabia ya output, inastahili mkusanyiko wa pili wa macho. Bonus: Checklist: Prompts live outside your code (and are clearly named) They’re versioned and diffable Wao ni kujaribiwa au tathmini Wao huchukua uchunguzi wakati ni muhimu 11 - Mhandisi wa Context Stack Sisi tayari kushughulikia LLM kusahau kwa kupunguza kumbukumbu na kugawana wafanyakazi kwa kazi. lakini bado kuna changamoto kubwa: Tunaandaa na kuwasilisha taarifa kwa mfano. Problem: jinsi ya Wengi wa mipangilio tu kutupa mfululizo wa majukumu: ujumbe wa maudhui kwenye prompt na wito kwa siku. ambayo inafanya kazi ... mpaka haina. Burn tokens juu ya redundant metadata Mapambano ya kuwakilisha mstari wa zana, hali, au aina nyingi za maarifa Fail to guide the model properly in complex flows Hata hivyo, bado tunatarajia mfano wa "kujua tu." Hiyo sio uhandisi. Solution: Engineer the context. Fanya mchakato wa mfuko wote wa kuingia kama interface iliyoundwa kwa makini, kwa sababu hiyo ndiyo. : Here’s how Wamiliki stack kamili: kudhibiti kile kinaingia, jinsi inachaguliwa, na wapi inaonyeshwa. kila kitu kutoka maagizo ya mfumo hadi dosari zilizopatikana hadi machapisho ya kumbukumbu inapaswa kuwa na nia. Nenda zaidi ya muundo wa mazungumzo: Kujenga miundo yenye utajiri zaidi, nyembamba zaidi. vichaka vya mtindo wa XML, mipangilio ya mfupa, traces za zana zilizopunguzwa, hata sehemu za Markdown kwa uwazi. Fikiria kikamilifu: Mtazamo = kila kitu mfano anaona: mwongozo, hali ya kazi, maamuzi ya awali, logs ya zana, maagizo, hata matokeo ya awali. This becomes especially important if you’re optimizing for: Density ya habari: kuunganisha maana zaidi katika tokens chache Ufanisi wa gharama: utendaji mkubwa kwa ukubwa mdogo wa mazingira Usalama: kudhibiti na kuagiza kile mfano unachokiona Unyevu wa makosa: ishara ya wazi ya kesi za mwisho, matatizo yaliyojulikana, au maelekezo ya kurudi nyuma Kuondoka ni nusu ya vita. Na ikiwa huna kufanya hivyo bado, utakuwa mara baada ya mfanyakazi wako kukua. Bottom line: Uhandisi wa mazingira 12 - Kuongeza vichaka vya usalama Even with solid prompts, memory, and control flow, an agent can still go off the rails. Think of this principle as an insurance policy against the worst-case scenarios: users (or other systems) slip in instructions that hijack the agent. Prompt injection: the model blurts out PII or corporate secrets. Sensitive-data leaks: Maudhui ya sumu au ya uharibifu: maneno yasiyo ya chuki, spam, au maudhui yasiyo ya kuruhusiwa. Halucinations: majibu ya uhakika lakini ya uongo. Hatua za nje ya kiwango: mfanyabiashara "anapata ubunifu" na anafanya kitu ambacho haipaswi kufanya. No single fix covers all of that. You need • Ulinzi wa kutosha unaoathiri matatizo katika kila hatua ya mzunguko wa maombi / majibu. defense-in-depth Quick Checklist Uhakiki wa kuingia kwa mtumiaji umefanyika (jailbreak maneno, kuangalia nia). Kwa kazi za ukweli, majibu yanapaswa kutaja mazingira ya RAG. Utaratibu unaonyesha wazi kwamba mfano unapaswa kushikamana na ukweli uliopatikana. blocks PII or disallowed content. Output filter Majibu yanajumuisha quote / kiungo kwa chanzo. Msaidizi na zana zinafuatilia heshima ndogo zaidi. Hatua muhimu zinapita kupitia idhini ya HITL au ufuatiliaji. Fanya ngazi hizi kama DevOps ya kawaida: kumbuka, kujaribu, na kushindwa salama. Hivi ndivyo unavyoweza kuzuia mfanyabiashara "mstaafu" kuwa na wajibu usio na udhibiti. Sehemu ya 4 - Kuweka kazi chini ya mzigo Katika uzalishaji, kushindwa mara chache hutokea mara moja, na mara nyingi huwezi kugundua mara moja, wakati mwingine sio kabisa. Sehemu hii inazingatia kujenga kiufundi cha uhandisi wa kufuatilia mfanyabiashara wako mara kwa mara, kuhakikisha kila kitu kinakwenda vizuri. . Kutoka kumbukumbu na kufuatilia kwa majaribio ya moja kwa moja, mazoea haya hufanya tabia ya mfanyabiashara wako wazi na ya kuaminika, kama wewe ni kuangalia kikamilifu au kuzingatia kujenga ufumbuzi ujao 13 - Ufuatilia njia ya utekelezaji kamili : Wafanyabiashara bila shaka watakuwa na tabia mbaya wakati wa maendeleo, updates, au hata utendaji wa kawaida. Debugging matatizo haya inaweza kuchukua masaa mengi kujaribu kurejesha makosa na kutambua makosa. Ikiwa tayari umeweka kanuni muhimu kama kuweka hali nje na kushinikiza makosa katika mazingira, wewe ni mbele. Lakini bila kujali, kupanga kwa debugging yenye ufanisi kutoka mwanzo unakuokoa maumivu makubwa baadaye. Problem Kumbuka safari nzima kutoka kwa ombi la mtumiaji kupitia kila hatua ya uamuzi na mchakato wa hatua wa mfanyabiashara. kumbukumbu za sehemu za kibinafsi sio za kutosha; unahitaji ufuatiliaji wa mwisho kwa mwisho unaohusisha kila maelezo. Solution : Why this matters Debugging: Haraka kutambua wapi na kwa nini mambo yalikuwa mabaya. Uchambuzi: Utafuta vikwazo na fursa za kuboresha. Tathmini ya ubora: Tathmini jinsi mabadiliko yanaathiri tabia. Utambulisho: Unaweza kurejesha wakati wowote kwa usahihi. : Maintain a full record of agent decisions and actions. Auditing Minimum data to capture : User request and parameters from prior steps. Input Hali ya Agent: Mabadiliko muhimu kabla ya kila hatua. Utaratibu: Utaratibu kamili uliotumwa kwa LLM (maelekezo ya mfumo, historia, mazingira). Matokeo ya LLM: Jibu la Raw kabla ya usindikaji. : Tool name and parameters invoked. Tool call Matokeo ya chombo: Matokeo ya chombo au makosa. Uamuzi wa mfanyabiashara: Hatua inayofuata au majibu yaliochaguliwa. Metadata: wakati, maelezo ya mfano, gharama, msimbo, na matoleo ya haraka. Tumia zana za ufuatiliaji zilizopo ambapo inawezekana: LangSmith, Arize, Weights & Biases, OpenTelemetry, nk Lakini kwanza, hakikisha una msingi unaohusishwa (tazama Kanuni ya 15). : Checklist All steps logged with full detail. Logs zinazohusiana na session_id na step_id. Utaratibu wa kuangalia chuo kikuu cha wito. Uwezo wa kurejesha kikamilifu prompt yoyote wakati wowote. 14 - Jaribu kila mabadiliko : Kwa sasa, mfanyabiashara wako anaweza kujisikia tayari kuanza: inafanya kazi, labda hata hasa kama ulivyotaka. Lakini jinsi unaweza kuwa na uhakika kwamba itaendelea kufanya kazi baada ya updates? Mabadiliko ya msimbo, datasets, mifano ya msingi, au maombi inaweza kimya kuharibu mantiki iliyopo au kuharibu utendaji. mbinu za majaribio ya jadi hazijumuishi mambo yote ya LLMs: Problem Modeli drift: utendaji kupungua kwa muda bila mabadiliko ya msimbo kutokana na mabadiliko ya mfano au data Upungufu wa haraka: mabadiliko madogo ya haraka yanaweza kusababisha mabadiliko makubwa ya output Non-determinism: LLMs mara nyingi kutoa majibu tofauti kwa ufumbuzi huo, kuathiri mtihani sahihi-match Makosa ambayo ni vigumu kurejesha: hata na input imara, bugs inaweza kuwa vigumu kufuatilia Athari ya butterfly: mabadiliko cascade unpredictably kati ya mifumo Hallucinations na hatari nyingine zinazohusiana na LLM Kuchukua mkakati wa majaribio ya kina, ya ngazi nyingi unaounganisha majaribio ya programu ya kawaida na udhibiti wa ubora wa LLM: Solution Utafiti wa viwango vingi: mtihani wa kipekee wa kazi / prompts, majaribio ya ushirikiano, na matukio kamili ya mwisho Mtazamo juu ya ubora wa output ya LLM: umuhimu, uwiano, usahihi, mtindo, na usalama Tumia datasets ya dhahabu na outputs inatarajiwa au kiwango cha matokeo cha kukubalika kwa udhibiti wa regression Automatize majaribio na kuingiza katika vifaa vya CI / CD Kuingilia watu kwa tathmini muhimu au ngumu (mtu-in-the-loop) Iteratively kujaribu na kuimarisha prompts kabla ya kupelekwa Mtihani katika ngazi tofauti: vipengele, prompts, minyororo / wafanyakazi, na mtiririko kamili wa kazi : Checklist Logic ni modular na kujaribiwa kikamilifu peke yake na katika mchanganyiko Ubora wa output unatathminiwa kulingana na data ya benchmark Majaribio hufunika matukio ya kawaida, matukio ya mwisho, kushindwa, na kuingia kwa uharibifu Unyevu dhidi ya ufumbuzi wa sauti au upinzani unapatikana Mabadiliko yote yanapita majaribio ya automatiska na yanafuatiliwa katika uzalishaji ili kugundua regressions zisizojulikana 15 - Own The Whole Stack Kanuni hii inahusisha kila kitu pamoja, ni kanuni ya meta ambayo inakwenda kupitia kila kitu kingine. Leo, kuna zana nyingi na miundombinu za kukabiliana na kazi yoyote, ambayo ni nzuri kwa kasi na urahisi wa prototyping - lakini pia ni mashaka. Hii ni muhimu hasa katika maendeleo ya wafanyabiashara, ambapo unahitaji kusimamia: Kutokuwa na uhakika wa LLMs Logic ngumu karibu na mabadiliko na kurekebisha mwenyewe Mahitaji ya mfumo wako wa kubadilika na kuendeleza bila kuandika tena kazi za msingi Hii inaweza kuharakisha prototyping lakini hufanya maendeleo ya muda mrefu kuwa vigumu kusimamia na customize. Frameworks often invert control Kanuni nyingi ambazo umeona zinaweza kutekelezwa na zana za nje ya shamba. Lakini wakati mwingine, kujenga mantiki ya msingi inachukua juhudi sawa na inakupa uwazi bora, udhibiti, na ufanisi. Kwa upande mwingine, kwenda kikamilifu na kuandika upya kila kitu kutoka mwanzo ni over-engineering, na hatari sawa. Jambo la msingi ni Kama mhandisi, unaamua kwa ufahamu wakati wa kutegemea mifumo na wakati wa kuchukua udhibiti kamili, kuelewa kikamilifu mabadiliko yanayohusiana. usawa wa : mazingira ya vifaa vya AI bado yanabadilika kwa haraka. Vifaa vingi vya sasa viliundwa kabla ya viwango vya kudumisha. Wanaweza kuwa wazima kesho - lakini uchaguzi wa usanifu unaofanya sasa utaendelea zaidi. Remember Mwisho wa Kujenga mfanyabiashara wa LLM sio tu juu ya kuita API tena. Ni juu ya kubuni mfumo ambao unaweza kushughulikia utumwa wa ulimwengu halisi: makosa, hali, mipaka ya mazingira, kuingia zisizotarajiwa, na mahitaji yanayoendelea. Kanuni 15 tulizozungumzia sio nadharia, ni masomo yaliyojaribiwa na vita kutoka kwa trenches. Watakusaidia kurekebisha script nyeti katika wafanyabiashara wa imara, wa kupanua, na wa kudumisha ambao hawaharibu wakati watumiaji halisi wanapoonekana. Kila kanuni inastahili kuzingatia ili kuona kama inafanana na mradi wako. Hatimaye, ni mradi wako, malengo yako, na uumbaji wako. Lakini kumbuka: LLM ni nguvu, lakini ni sehemu moja tu ya mfumo mgumu. Kazi yako kama mhandisi ni kuwa na mchakato, kusimamia utata, na kudumisha mambo yote kuendesha kwa urahisi. Ikiwa unachukua kitu kimoja, hebu iwe hii: Kwa sababu hiyo ndiyo njia pekee ya kwenda kutoka “wow, ilikuwa imejibu!” hadi “yaah, inaendelea kufanya kazi.” slow down, build solid foundations, and plan for the long hau Endelea iterating, kujaribu, na kujifunza. Na usisahau, binadamu katika mzunguko sio nyuma, wanahifadhi mfanyabiashara wako msingi na ufanisi. Hii sio mwisho. Ni mwanzo tu wa wafanyabiashara wa ujenzi ambao kwa kweli hutoa. Struggling to grow your audience as a Tech Professional? The Tech Audience Accelerator is the go-to newsletter for tech creators serious about growing their audience. You’ll get the proven frameworks, templates, and tactics behind my 30M+ impressions (and counting). https://techaudienceaccelerator.substack.com/embed?source=post_page-----e58139d80299---------------------------------------&embedable=true