End-to-End Production: Pag-verify, Pagsubaybay at Etika

Mga nadagdag:

• Maaaring magdisenyo ng end-to-end na arkitektura na kumukuha ng feature na LLM mula sa ideya hanggang sa produksyon
• Nagtatatag ng mga layer ng pagpapatupad ng pag-verify, pag-apruba ng tao, at pagsubaybay (pag-log/mga sukatan)
• Isinasalin ng mga hangganan ang mga prinsipyo ng etika at privacy sa mga desisyon sa produksyon

Sa nakaraang sampung unit, natutunan namin ang mga bahagi nang paisa-isa: istraktura ng kahilingan, ekonomiya ng token, daloy, prompt ng system, pagpili ng modelo, cache, batch, pamamahala ng error, secure na key at automation. Sa huling yunit na ito, pinagsasama namin ang mga bahagi at itinatag ang holistic na arkitektura na nagdadala ng tampok na LLM mula sa ideya hanggang sa produksyon. Ang produksyon ay iba sa isang "nagtatrabahong demo": ang pag-verify ay sapilitan, ang output ay dapat na subaybayan, ang mga hangganan at etikal na mga prinsipyo ay dapat na naka-embed sa mga desisyon. Ang yunit na ito ay ang carrier column ng module; Lahat ng mga nauna ay nagsasama-sama dito.

Mga Layer ng Arkitektura ng Produksyon

Ang matatag na kwalipikasyon ng LLM ay binubuo ng humigit-kumulang limang layer:

1. Input layer: Kolektahin ang data, linisin ito, i-mask ang mga sensitibong lugar, ipadala lamang kung ano ang kinakailangan.
2. Layer ng modelo: Piliin ang tamang modelo (unit 5), itakda ang prompt ng system at mga parameter (unit 4), cache (unit 6).
3. Layer ng pagpapatunay: Suriin ang output ayon sa schema/panuntunan, pinagmulan, at pag-apruba ng tao kung kinakailangan.
4. Layer ng pagkilos: Magsagawa ng pagkilos na may napatunayang output; Kumuha ng mga aksyon na may mataas na epekto.
5. Layer ng pagsubaybay: Itala at sukatin ang bawat tawag, gastos, error at kalidad.

Ang mga layer na ito ay isang pipeline; sinusuri ng bawat isa ang output ng nauna.

Bakit Kinakailangan ang Pagpapatunay?

Ang mga LLM ay maaaring makagawa ng matatas ngunit minsan ay hindi tumpak na output. Ito ay tinatawag na hallucination: ang modelo ay maaaring gumawa ng impormasyon na mukhang totoo ngunit hindi. Sa isang chat game ito ay matitiis; hindi maaaring tiisin sa isang sistema ng produksyon (invoice, kalusugan, legal, pananalapi). Kaya ito ay naging, walang taros na hindi mapagkakatiwalaan; ay nakumpirma.

Mga layer ng pag-verify (tumataas ayon sa epekto):

• Format/schema validation: Ang output ba ay umaayon sa inaasahang JSON schema? (Ang structured na output ay higit na ginagarantiyahan ito.)
• Pagpapatunay ng panuntunan/lohika: Makatwiran ba ang mga halaga? (Negatibo ba ang halaga, ang petsa ba sa hinaharap, wasto ba ang kategorya?)
• Pag-verify ng pinagmulan: Nakabatay ba ang claim sa ibinigay na dokumentasyon? Does the model say something that isn't in the document?
• Pag-apruba ng tao: Sinusuri ng isang eksperto ang mataas na epekto o hindi malinaw na mga desisyon.

Babala: "Napakaganda ng modelo, hindi na kailangan ng karagdagang pag-verify" ang pinaka-mapanganib na kamalian sa produksyon. Gaano man kahusay ang modelo, ang layer ng pag-verify ay isang safety net sa mga desisyong may mataas na epekto. Kahit na ang isang maling awtomatikong desisyon ay maaaring mag-alis sa lahat ng oras na nai-save.

Human-in-the-Loop

Hindi lahat ng desisyon ay kailangang ganap na awtomatiko. Sa human-in-the-loop approach, pinapabilis ng modelo ang trabaho at inaprubahan ito ng tao. Ang tamang balanse ay nakasalalay sa epekto ng desisyon at sa pagiging maaasahan ng modelo sa gawaing iyon.

Epekto ng desisyon

Diskarte

Mababa (mungkahi sa label, draft)

Buong automation; ang error ay mura at nababaligtad

Katamtaman (routing, prioritization)

Automation + sampling control

Mataas (pera, kontrata, kalusugan, pagtanggal)

Ang pahintulot ng tao ay sapilitan; nagmumungkahi lamang ang modelo

Pagsubaybay: Hindi Mo Mapapamahalaan ang Hindi Mo Nakikita

Sa produksyon, dapat mong subaybayan ang bawat tawag. Kung walang pagsubaybay, hindi mo mapapahusay ang gastos, kalidad, o mahuli ang isang problema nang maaga. Mga pangunahing sukatan na itatala:

• Paggamit/gastos: Bawat kahilingan at kabuuang mga token, pamamahagi ng modelo, pang-araw-araw na paggastos.
• Latency: Average at worst-case na oras ng pagtugon.
• Rate ng error: 429/500 na rate, muling pagsubok, pag-abandona.
• Kalidad: Tinanggihang rate ng output sa layer ng pag-verify, rate ng pagwawasto sa pag-apruba ng tao, feedback ng user.

Tip: Huwag magsulat ng sensitibong data (personal na impormasyon, mga susi) sa mga log ng pagsubaybay. Isaalang-alang ang mga log sa loob ng saklaw ng pagiging kumpidensyal; record sa pamamagitan ng masking kung kinakailangan (unit 9).

Etika at Hangganan

Ang etikal na pananagutan ay isang bahagi ng desisyon ng produksyon gaya ng teknikal na katumpakan:

• Transparency: Dapat malaman ng user kung artificial intelligence o tao ang kausap nila.
• Pagkamakatarungan at pagkiling: Ang modelo ay maaaring magdala ng pagkiling mula sa data kung saan ito sinanay; Subaybayan ang mga kahihinatnan ng diskriminasyon sa mga desisyong may mataas na epekto (pag-hire, kredito).
• Pananagutan: Kung ang isang awtomatikong desisyon ay nagdudulot ng pinsala, ikaw ang may pananagutan; "Ang sabi ng modelo" ay hindi isang pagtatanggol.
• Pagtanggap ng mga limitasyon: Ang modelo ay hindi maaaring gumanap ng ilang mga gawain nang mapagkakatiwalaan; ang hindi pag-automate sa mga ito ay isa ring desisyon sa disenyo.

Mga Kopyadong Template

# Checklist ng pagpapatunay (pagkatapos ng pagbuo ng output)1) Wasto ba ang schema? (structured output validation)2) May katuturan ba ang mga halaga? (rule check: range, date, enum)3) Nakabatay ba ang claim sa pinagmulan? (tanggihan kung wala sa dokumento)4) Mataas ba ang epekto? → ipadala para sa pag-apruba ng tao5) Kung pumasa ang lahat → payagan ang pagkilos, i-save

# System prompt na pinipilit na umasa sa sourceAsa lamang sa impormasyon sa ibinigay na dokumento. Huwag magdagdag ng anumang bagay na wala sa dokumento. Kung ang isang impormasyon ay wala sa dokumento, isulat ang "Not found in the document". Huwag manghula o gumawa ng mga bagay.

# Human approval threshold (decision rule)IF decision_type in [pera, kontrata, tanggalin, kalusugan] → human approval mandatoryIF model_trust < threshold O validation "uncertain" → submit to human approvalOTHER → auto apply + sampling control

# Trace log template (writing sensitive data){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd" at key are NEVER nakasulat na personal na data:... } //

Mahinang prompt / Malakas na prompt (kaasahan ng produksyon)

# WEAK (walang pag-verify, walang source, awtomatikong nalalapat) Suriin ang kahilingang ito, gumawa ng desisyon sa refund at mag-apply.

# STRONG (source-based, bumubuo ng rekomendasyon, umalis sa pag-apruba ng tao) Suriin ang kahilingan sa pagbabalik na ito batay sa dokumento ng patakaran sa pagbabalik lamang. Magrekomenda ng desisyon nang may katwiran ngunit huwag ipatupad ang: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}.Kung walang malinaw na batayan sa dokumento ng patakaran, magbigay ng "unclear". Aaprubahan ng isang kinatawan ang pinal na desisyon.

Napakahusay na bersyon; Iniuugnay nito ang desisyon sa pinagmulan, ipinoposisyon ang modelo bilang isang "nagmumungkahi" sa halip na isang "tagagawa," at inilalagay ang mataas na epekto na hakbang sa likod ng pag-apruba ng tao. Ito ang kakanyahan ng pagiging maaasahan ng produksyon.

Tatlong Mini Case

Case 1 — Ang araw na na-save ang verification layer. Ang isang fintech ay nagkakaroon ng modelong pag-uri-uriin ang mga paglalarawan ng transaksyon at lumikha ng mga awtomatikong talaan ng accounting. Nagdagdag sila ng pagpapatunay ng panuntunan: kapag mali ang nai-output ng modelo ang halaga (12,500 sa halip na 1,250 sa dokumento), tinanggihan ng panuntunang "hindi tumutugma sa dokumento" ang output at nahulog ang record sa tao. Kung walang pag-verify, ang maling tala ay tahimik na papasok sa system.

Kaso 2 — Takas na nahuli sa pamamagitan ng pagbabantay. Isang koponan ng SaaS ang nag-set up ng monitoring panel; Isang umaga, triple ang gastos sa araw-araw. Nakita mula sa mga log na ang isang kliyente ay pumasok sa isang loop at nagpadala ng parehong kahilingan nang libu-libong beses. Nagdagdag sila ng quota at deduplication; Nalutas ang problema sa loob ng ilang oras. Kung walang pagsubaybay, ang bill ay magiging isang sorpresa sa katapusan ng buwan.

Kaso 3 — Pagtanggap sa limitasyon. Nagpaplano ang isang startup ng pangangalagang pangkalusugan na awtomatikong gumawa ng rekomendasyon sa diagnosis at ipakita ito sa pasyente. Sa isang pagsusuri sa etika at pananagutan, napagpasyahan nilang hindi ito limitado: nagbibigay lamang ang modelo ng buod at posibleng mga punto sa isang manggagamot, ang doktor ang gumagawa ng diagnosis. Ang hindi pag-automate ng trabaho ay isa ring mature na desisyon sa disenyo.

Mga karaniwang pagkakamali

• Nilaktawan ang pagpapatunay: Blindly applying the output, saying "the model is good".
• Pag-automate ng high-impact na desisyon: Ang pag-apruba ng tao ay mahalaga sa pera/kalusugan/batas.
• Hindi pagsubaybay: Ang mga problema sa gastos at kalidad ay huli na natuklasan.
• Pagsusulat ng sensitibong data sa mga log: Paglabag sa privacy; I-save ito sa pamamagitan ng masking ito.
• Hindi sinusubukang umasa sa pinagmulan: Maaaring binubuo ng modelo ang wala sa dokumento.
• Pagbabalewala sa mga limitasyon: Ang hindi pag-automate ng ilang gawain ay ang tamang desisyon; Ang transparency at responsibilidad ay sa iyo.

Mas Malalim: Pamamahala sa Paglabas, Rollback, at Incremental Deployment

Ang pagkuha ng feature ng LLM sa produksyon ay hindi tungkol sa pag-set up nito at paglimot dito; ay upang ligtas na baguhin ang isang live na sistema sa paglipas ng panahon. Mayroon itong tatlong haligi.

Pag-bersyon. Ang iyong prompt ng system, pagpili ng modelo, at mga panuntunan sa pag-verify ay nagbabago sa paglipas ng panahon. Bersyon bawat makabuluhang pagbabago at itala kung aling bersyon ang live. Kung isang araw bumaba ang kalidad, "ano ang binago natin?" Dapat mong masagot ang tanong sa loob ng ilang minuto. Sa isang system na walang bersyon, ang paghahanap ng ugat ng isang regression ay tumatagal ng mga araw.

Rollback. Kung ang isang bagong prompt o modelo ay kumikilos nang mas masama kaysa sa inaasahan sa live, dapat mong mabilis na makabalik sa dati, kilalang bersyon. Ang isang pagbabago na walang rollback na plano ay bulag na pagtanggap ng isang live na panganib. "May binago ako, naging masama, hindi na ako makakabalik" ang pinakamahal na production scenario.

Unti-unting paglulunsad. Sa halip na maglapat ng pagbabago sa lahat ng trapiko nang sabay-sabay, ilalabas mo muna ito sa maliit na porsyento (hal. 5%) at subaybayan ang mga sukatan (kalidad, gastos, mga error). Kung ito ay mabuti, dagdagan mo ang porsyento; Kung ito ay masama, babalikan mo ito na may maliit na bahagi lamang na apektado. Lubos nitong nililimitahan ang panganib.

Pinagsasama ng tatlong kasanayang ito ang mga diskarte mula sa lahat ng nakaraang unit: ang eval (unit 5) ay sumusukat sa pagbabago nang maaga, ang pagsubaybay (ang unit na ito) ay nagbibigay ng maagang babala sa panahon ng pagpapalaganap, ang layer ng pag-verify ay nakakakuha ng mga maling output bago ang mga ito ay naaaksyunan. Ang produksyon ay hindi isang solong tamang setup; Ito ay isang tuluy-tuloy na disiplina na sumusukat, sumusubaybay at maaaring magbago nang may kumpiyansa. Ang buong modyul ay para sa iyo na itatag ang disiplinang ito.

Sa buod

Ang produksyon ay higit pa sa isang gumaganang demo: ito ay isang pipeline ng input, modelo, pag-verify, pagkilos at mga layer ng pagsubaybay. Ang output ay hindi maaasahan nang walang pag-verify; ang mga desisyon na may mataas na epekto ay nakatali sa pag-apruba ng tao; Ang bawat tawag ay sinusubaybayan para sa gastos, mga error at kalidad. Ang etika, transparency, bias control, pananagutan at pagtanggap ng mga limitasyon ay mahalaga sa mga teknikal na desisyon. Ang bawat piraso na natutunan sa modyul na ito ay magkakasama sa holistic na disenyong ito.

Gawain ng aplikasyon

Magdisenyo ng tampok na LLM na end-to-end. (1) Punan ang limang layer (input, modelo, pag-verify, aksyon, pagsubaybay) para sa iyong partikular na gawain. (2) Markahan ayon sa epekto kung aling mga desisyon ang mangangailangan ng pag-apruba ng tao. (3) Sumulat ng hindi bababa sa tatlong pagsusuri sa pagpapatunay (schema, panuntunan, pinagmulan). (4) Tukuyin ang mga pangunahing sukatan na iyong susubaybayan at kung ano ang hindi mo itatala. (5) Sumulat ng limitasyon at prinsipyong etikal na tinatanggap mo sa tampok na ito.

checklist

• [ ] Maaari akong magdisenyo ng limang layer ng pipeline ng produksyon.
• [ ] Maaari kong patunayan ang output laban sa schema, panuntunan at pinagmulan.
• [ ] Maaari akong magtakda ng threshold ng pag-apruba ng tao batay sa epekto ng desisyon.
• [ ] Sinusubaybayan ko ang gastos, error at kalidad at nagsasanay na hindi sumulat ng sensitibong data sa mga log.
• [ ] Maaari kong gawing mga desisyon sa produksyon ang etika, responsibilidad at mga hangganan.

Pagsusulit sa Module

1. Ano ang ginagawa ng papel na 'system' sa isang LLM chat API?

• A) Nagbibigay sa modelo ng mga permanenteng tagubilin at mga tuntunin ng pag-uugali na nalalapat sa buong pag-uusap ✔
• B) Pinapanatili ang huling tanong na isinulat ng gumagamit
• C) Iniimbak ang tugon na ginawa ng modelo
• D) Ini-encrypt ang API key

Paglalarawan: Ang papel na ginagampanan ng system ay nagbibigay sa modelo ng patuloy na mga tagubilin, personalidad, at mga panuntunang nalalapat sa buong pag-uusap; Ito ay isang mataas na antas na pag-redirect, na hiwalay sa mga mensahe ng user.

2. Bakit ipinapadala muli ang kasaysayan ng pag-uusap (mga naunang mensahe) sa bawat pagkakataon sa isang kahilingan sa API?

• A) Kinakailangang mag-backup habang tinatanggal ng server ang kasaysayan
• B) Ang mga tawag sa API ay walang estado; ✔ Ang konteksto ay hinanakit sa bawat kahilingan dahil hindi naaalala ng modelo ang kasaysayan
• C) Kinakailangan lamang para sa pag-invoice, walang epekto sa modelo
• D) Ang pagpapadala ng kasaysayan ay ipinag-uutos upang maiwasan ang pagbagal ng tugon

Paliwanag: Ang mga tawag sa LLM API ay walang estado; Hindi naaalala ng modelo ang mga nakaraang pag-ikot, kaya ang lahat ng nauugnay na kasaysayan ay isinasama sa bawat kahilingan upang mapanatili ang konteksto.

3. Ano ang isang 'token' sa pagpepresyo ng LLM?

• A) Isang beses na password na ginamit upang mag-log in sa API
• B) Isang nakapirming bayad na binayaran sa bawat kahilingan
• C) Ang pinakamaliit na yunit kung saan pinoproseso ng modelo ang teksto; karaniwang tumutugma sa bahagi ng salita ✔
• D) Isang yunit na sumusukat lamang sa haba ng output

Paglalarawan: Ang Token ay ang pinakamaliit na unit kung saan nagpoproseso ang modelo ng text; Karaniwan itong tumutugma sa isang fragment ng isang salita, at parehong input at output ay sinisingil batay sa bilang ng mga token.

4. Bakit mas mahal ang mga output token kaysa mga input token sa karamihan ng mga provider ng LLM?

• A) Ang mga token ng output ay palaging mas mahaba kaysa sa input
• B) Ang mga token ng input ay libre
• C) Ang mga token ng output ay ipinapadala nang dalawang beses sa internet
• D) Mas mataas ang halaga ng unit dahil ang pagbuo ng output ay nangangailangan ng mga karagdagang kalkulasyon para sa bawat token ✔

Paglalarawan: Ang bawat isa sa mga token ng output ay nangangailangan ng modelo na magsagawa ng sunud-sunod na pagbuo (computation); Ang gastos sa produksyon na ito ay mas mataas kaysa sa pagproseso ng input nang sabay-sabay, kaya ang presyo ng yunit ng output ay karaniwang mas mataas.

5. Sa anong sitwasyon mas kapaki-pakinabang ang paggamit ng streaming?

• A) Sa mahabang sagot; Binabawasan ang nakikitang pagkaantala at pinipigilan ang timeout ✔
• B) Sa napakaikli lamang, isang salita na sagot
• C) Upang bawasan ang gastos sa zero
• D) Upang itago ang API key

Paglalarawan: Sa mahabang mga tugon, binabawasan ng streaming ang nakikitang latency sa pamamagitan ng pagpapalabas kaagad ng mga unang salita at pinipigilan ang mga HTTP timeout sa malalaking halaga ng max_tokens.

6. Ano ang karaniwang nakakaapekto sa pagtaas ng parameter ng 'pagsisikap' sa mga modernong modelo?

• A) Palaging paikliin ang sagot
• B) Awtomatikong iniikot ang API key
• C) Binabawasan lang nito ang presyo ng input token
• D) Pinapataas ang lalim ng pag-iisip at paggastos ng token; Maaari itong mapabuti ang kalidad, ngunit pinapataas din nito ang latency at gastos ✔

Paglalarawan: Inaayos ng parameter ng pagsisikap kung gaano kalalim ang pag-iisip ng modelo tungkol sa isang gawain at kung gaano karaming mga token ang gagastusin nito; Maaaring mapabuti ng pag-upgrade ang kalidad, ngunit pinapataas din nito ang latency at gastos. Para sa mga simpleng gawain, sapat na ang mababang pagsisikap.

7. Ano sa pangkalahatan ang pinaka-epektibong paraan sa isang simple, mataas na dami ng gawain sa pag-uuri?

• A) Palaging gamitin ang pinakamahal at pinakamakapangyarihang modelo
• B) Pagtawag sa lahat ng modelo nang sabay-sabay para sa bawat kahilingan
• C) Pagpili ng pinakamagaan/pinakamurang modelo na nagagawa ang gawain sa pamamagitan ng pag-verify nito na may kaunting eval ✔
• D) pinapanatili ang halaga ng max_tokens na hindi kinakailangang masyadong mataas

Paliwanag: Kung ang gawain ay hindi kumplikado, ang pagpili ng isang mas mabilis at mas murang modelo na madaling magawa ang gawain (hal. Haiku class) sa halip na gamitin ang pinakamahal at makapangyarihang modelo ay makabuluhang bawasan ang gastos.

8. Sa aling sitwasyon mas pinabababa ng prompt caching ang gastos?

• A) Kapag ang malaki at nakapirming konteksto ay ginamit nang paulit-ulit sa maraming kahilingan ✔
• B) Kapag ang isang ganap na naiibang teksto ay ipinadala sa bawat kahilingan
• C) Kapag iisang kahilingan lamang ang ginawa
• D) Upang bawasan ang mga token ng output

Paglalarawan: Ang pag-cache ay isang prefix na tugma; Sa mga kaso kung saan ang isang malaki, hindi nababagong konteksto (system prompt, mga dokumento) ay muling ginagamit sa maraming kahilingan, ang pagbabasa mula sa cache ay isang maliit na bahagi (~0.1x) ng buong presyo.

9. Paano ko dapat i-edit ang prompt upang tumama ang prompt cache?

• A) Paglalagay ng variable na content sa simula at fixed content sa dulo
• B) I-embed ang kasalukuyang petsa at oras sa prompt ng system para sa bawat kahilingan
• C) Paglalagay ng nakapirming nilalaman (system prompt, mga dokumento) sa simula at variable na nilalaman sa dulo ✔
• D) Pagbabago ng pagkakasunud-sunod ng listahan ng tool sa bawat kahilingan

Paliwanag: Dahil ang cache ay isang prefix na tugma, naayos/hindi nagbabago ang nilalaman (system prompt, mga dokumento) ay sinisimulan; Ang variable na nilalaman (petsa, tanong ng user, ID ng kahilingan) ay inilalagay sa dulo. Kahit na ang isang solong byte na binago sa simula ay magpapawalang-bisa sa cache.

10. Para sa anong uri ng workload ang batch processing ay pinakaangkop?

• A) Live chat kung saan inaasahan ng user ang isang agarang tugon sa screen
• B) Isang maikling tanong lamang
• C) Pagbuo ng API key
• D) Mga trabahong delay tolerant, malaking volume at hindi nangangailangan ng agarang resulta ✔

Paglalarawan: Batch processing ay angkop para sa malalaking volume ng mga trabaho na hindi nangangailangan ng agarang tugon at mapagparaya sa pagkaantala; ang mga resulta ay inihahatid pagkatapos ng ilang panahon, ngunit ang halaga ng yunit ay karaniwang mas mababa.

11. Ano ang ginagamit upang kumpiyansa na tumugma kung aling kahilingan ang nabibilang sa mga resulta sa isang batch?

• A) Pagpapadala ng order (posisyon) ng mga kahilingan
• B) Haba ng mga sagot
• C) Huling 4 na digit ng API key
• D) Isang natatanging custom_id na ibinigay sa bawat kahilingan ✔

Puna: Maaaring ibalik ang maramihang resulta sa ibang pagkakasunud-sunod kaysa sa pagkakasunud-sunod ng pagsusumite; kaya kailangang itugma ang mga resulta ayon sa ID, hindi lokasyon, na may natatanging custom_id na ibinigay sa bawat kahilingan.

12. Ano ang inirerekomendang gawi kapag nakatanggap ka ng 429 (rate limit) na error mula sa API?

• A) Pagpipilit sa pamamagitan ng pagpapadala ng marami pang kahilingan sa parehong oras
• B) Sinusubukang muli nang may exponential backoff, kasunod ng retry-after heading ✔
• C) Kanselahin nang buo ang kahilingan at ipakita ang error bilang pag-crash sa user
• D) Pagbabago ng API key

Paliwanag: Ang 429 ay isang retryable error; Ang tamang diskarte ay ang subukang muli gamit ang exponential backoff, ayon sa retry-after header. Karamihan sa mga opisyal na SDK ay awtomatikong ginagawa ito.

13. Alin sa mga sumusunod na HTTP error code ang karaniwang itinuturing na maaaring muling subukan?

• A) 400 (hindi wastong kahilingan)
• B) 401 (error sa pagpapatunay)
• C) 529 (na-overload ang server) ✔
• D) 404 (hindi nahanap)

Paliwanag: 429 (speed limit), 500 (server error) at 529 (overload) ay pansamantalang mga error at maaaring muling subukan sa pamamagitan ng pag-back off. Ang mga error tulad ng 400 at 401 ay mga isyu sa kahilingan/pagkakakilanlan; Hindi ito malulutas ng pagsubok muli.

14. Alin sa mga sumusunod ang secure na paraan upang pamahalaan ang mga API key?

• A) Pag-iimbak sa environment variable/hidden manager, hindi ito i-embed sa code at regular na umiikot ✔
• B) Isulat ang susi nang direkta sa source code at ipadala ito sa repositoryo
• C) Paglalagay ng susi sa client side (browser) JavaScript
• D) Pagbabahagi ng isang solong susi sa buong koponan sa pamamagitan ng email

Paglalarawan: Ang mga susi ay hindi kailanman isinusulat sa source code o repositoryo; Ito ay nakaimbak sa isang environment variable o nakatagong tool sa pamamahala, na binibigyan ng kaunting mga pribilehiyo, at regular na iniikot.

15. Ano ang pinakamahusay na diskarte sa pagsasama ng LLM sa isang automation tool (n8n, Zapier, Make) sa mga tuntunin ng privacy?

• A) Pagpapadala ng lahat ng raw data sa modelo, kahit na hindi ito kinakailangan
• B) Pagsusulat ng API key sa plain text sa loob ng flow step
• C) Pag-minimize at pag-mask sa sensitibong data at pag-iimbak ng susi bilang mga lihim na kredensyal ✔
• D) Pagpapanatiling permanenteng personal na data sa history ng daloy

Paglalarawan: Habang ang pagpasok ng data sa automation ay dumadaan sa mga third-party na system at modelo, ang sensitibo/personal na data ay kailangang i-minimize, i-mask at mga kinakailangang field lang ang ipadala; Ang API key ay nakaimbak din bilang mga lihim na kredensyal sa loob ng tool.

16. Bakit ipinag-uutos ang pagpapatunay ng output sa isang tampok na produksyon na batay sa LLM?

• A) Ang pag-format lamang ang kailangan dahil hindi kailanman nagkakamali ang modelo
• B) Dahil ang modelo ay maaaring makagawa ng tuluy-tuloy ngunit minsan ay hindi tama; Dapat i-audit ang schema/tuntunin nang may pag-apruba ng mapagkukunan at tao ✔
• C) Dapat na iwasan ang pagpapatunay dahil ito ay nagpapataas lamang ng gastos
• D) Ang pagpapatunay ay para lamang bawasan ang bilang ng mga token

Paglalarawan: Ang mga LLM ay maaaring makagawa ng matatas ngunit minsan ay hindi tumpak (hallucinatory) na output; kaya lumabas ito sa mga desisyong may mataas na epekto; Dapat itong i-audit sa pamamagitan ng schema/rules checking, source validation, at pag-apruba ng tao kung kinakailangan.