Skip to content

GenAI Playbook

முகவர்களை மதிப்பிடுதல் & கவனித்தல்

வெளியிடப்பட்டது · ஆசிரியர்: Dipankar Sarkar

முகவர்களை மதிப்பிடுதல் & கவனித்தல்

நீங்கள் அளக முடியாததை ship செய்ய முடியாது

முகவர்கள் non-deterministic, பல-படி, stateful. பாரம்பரிய மென்பொருள் சோதனை (“இந்த செயல் X திருப்புகிறதா?”) வேலை செய்யாது — ஒரு முகவர் 5 படிகள் அல்லது 15 எடுக்கலாம், கருவிகளை அழைக்கலாம் அல்லது இல்லை, ஒவ்வொரு ஓட்டத்திலும் வெவ்வேறு வெற்றி. இந்த அத்தியாயம் 2026-இல் முகவர்களை shippable ஆக்கும் observability மற்றும் மதிப்பீடு நடைமுறைகளை உள்ளடக்குகிறது.

முகவர் observability ஏன் வேறுபட்டது

ஒரு சாதாரண API அழைப்பு ஒரு input, ஒரு output, ஒரு latency. ஒரு முகவர் ஓட்டம்:

  • ஒரு இலக்கு (input).
  • மாறும் எண்ணிக்கையிலான காரண படிகள்.
  • கருவி அழைப்புகள் (ஒவ்வொன்றும் input/output, latency, செலவுடன்).
  • இடைப்பட்ட நிலை.
  • ஒரு இறுதி output.

நீங்கள் முழு trace-ஐ பார்க்க வேண்டும், வெறும் தொடக்கம் மற்றும் முடிவு அல்ல. இல்லாவிட்டால், தோல்வி முகவர் ஓட்டம் ஒரு கருப்பு பெட்டி — தோல்வி தெரியும், ஆனால் மாதிரி தவறாக திட்டமிட்டதா, கருவி குப்பை திருப்பியதா, சூழல் நிரம்பியதா என தெரியாது.

Tracing

Tracing அடித்தளம். ஒவ்வொரு முகவர் ஓட்டமும் ஒரு trace-ஐ உருவாக்குகிறது: span-களின் மரம், ஒவ்வொன்றும் ஒரு படியை (LLM அழைப்பு, கருவி அழைப்பு, sub-agent) timing, token, செலவு, input/output உடன் பிரதிநிதித்துவம்.

2026 tracing கருவிகள்:

  • Langfuse (open-source, self-hostable) — முன்னணி open tracer; model-agnostic, evals மற்றும் prompt மேலாண்மையுடன்.
  • Arize Phoenix — open-source, LLM observability மற்றும் evals-இல் வலுவானது.
  • LangSmith (LangChain) — LangGraph/LangChain உடன் இறுக்கமாக ஒருங்கிணைக்கப்பட்டது.
  • Vendor-native — OpenAI மற்றும் Anthropic-இன் dashboard-கள் அவர்கள் அழைப்புகளை காட்டுகின்றன, cross-vendor ஓட்டங்களை அல்ல.

நல்ல trace எந்த ஓட்டத்திற்கும் பதிலளிக்க அனுமதி: முகவர் என்ன செய்தார், எந்த வரிசையில், எந்த செலவில், எங்கு தவறு நிகழ்ந்தது?

ஒரு span-க்கு என்ன log செய்ய

குறைந்தபட்சம்:

  • Span வகை (LLM, கருவி, முகவர், human-review).
  • Input மற்றும் output (முழு, துண்டிக்கப்படாத).
  • மாதிரி மற்றும் அளவுருக்கள் (temperature, முதலியவை).
  • Token எண்ணிக்கை (input, output, cached).
  • Latency.
  • செலவு.
  • நிலை (வெற்றி, பிழை, துண்டிக்கப்பட்ட).

கருவி span-களுக்கு, மேலும் log செய்: கருவி பெயர், வாதங்கள், மற்றும் மனிதர் அங்கீகரித்தாரா. இது உங்கள் audit trail — பாதுகாப்பு, Prompt Injection & Governance-ஐ பார்க்கவும்.

Evals: கடினமான பகுதி

Evals என்பது “இந்த முகவர் ship செய்ய போதுமானவரா?” என தீர்மானிக்க. மூன்று அடுக்குகள்:

1. நிர்ணயமான பாகங்களில் unit test

கருவி spec, output parser, guardrails — இவை குறியீடு, சாதாரணமாக சோதி. assert parse_tool_call(json) == expected.

2. Trajectory evals

முகவர் நியாயமான பாதை எடுத்தாரா? உண்மையான trajectory-ஐ (படி வரிசை) reference உடன் ஒப்பிடு. மெட்ரிக்ஸ்:

  • படி துல்லியம் — reference பாதையுடன் பொருந்தும் படிகளின் பின்னம்.
  • கருவி தேர்வு — சரியான கருவிகளை அழைத்தாரா?
  • பயனில்லை — படிகளை திரும்ப செய்தாரா அல்லது அதே வாதங்களுடன் அதே கருவியை அழைத்தாரா?

3. முடிவு evals

முகவர் இலக்கை அடைந்தாரா? இது பொதுவாக ஒரு நடுவர் மாதிரி (LLM-as-a-judge) அல்லது rubric தேவை:

  • LLM-as-a-judge — ஒரு வலுவான மாதிரி (Claude Opus, GPT-5) முகவரின் output-ஐ criteria-க்கு எதிராக மதிப்பிடு. மலிவு, scalable, ஆனால் bias.
  • மனித eval — தங்கக் தரம், விலையுயர்ந்தது. high-stakes output மற்றும் LLM நடுவரை calibrate செய்ய பயன்.
  • குறியீடு-அடிப்படை check — கட்டமைக்கப்பட்ட output உருவாக்கும் முகவர்களுக்கு: JSON validate ஆகுமா? SQL ஓடுமா? கோப்பு இருக்கிறதா?

உற்பத்தியில் guardrails

Evals ship செய்வதற்கு முன் நிகழ்கின்றன. Guardrails inference நேரத்தில் ஓடி தோல்விகளை பிடிக்க:

  • Input guardrails — தீய அல்லது out-of-scope பயனர் கோரிக்கைகளை முகவர் செயல்படுவதற்கு முன் நிராகரி.
  • Output guardrails — பயனருக்கு திருப்புவதற்கு முன் முகவரின் output-ஐ சரிபார்ப்பு (toxicity, PII, வடிவ சரிபார்ப்பு).
  • கருவி guardrails — செயல்படுத்துவதற்கு முன் கருவி input-ஐ validate (உதா., run_sql-இல் DROP இருக்கக் கூடாது).

Guardrail நூலகங்கள் (NeMo Guardrails, Guardrails AI, vendor-native) இவற்றை விதிகள் அல்லது சிறிய மாதிரிகளாக வரையறுக்க அனுமதி.

செலவு கண்காணிப்பு

முகவர்கள் விலையுயர்ந்தவர்கள். ஒரு ஒற்றை ஓட்டம் $0.01–$1.00+ செலவாகலாம். உற்பத்தியில்:

  • Per-ஓட்ட செலவு — ஒவ்வொரு trace-இலும் log செய்.
  • செலவு-ஒரு-வெற்றி — மொத்த செலவு / வெற்றி ஓட்டங்கள். இதுதான் முக்கியமான மெட்ரிக்.
  • பட்ஜெட் எச்சரிக்கைகள் — ஒரு ஓட்டம் median செலவின் 2× தாண்டும்போது எச்சரி (பரவாயில்லை ஒரு சுழற்சி).
  • மாதிரி tiering — எளிய படிகளை மலிவான மாதிரிக்கு (Haiku/Flash) route செய், கடினமானவற்றை வலுவானதற்கு (Opus/GPT-5). supervisor முறை (பல-முகவர் அமைப்புகள் பார்க்கவும்) இதை இயற்கையாக்குகிறது.

Human-in-the-loop (HITL)

உண்மையான விளைவுகளுடன் எதற்கும் ஒரு மனிதரை சுழற்சியில் வை. முறைகள்:

  • செயலுக்கு-முன்-அங்கீகரி — அழிவு கருவியை அழைப்பதற்கு முன் முகவர் இடைநிறுத்து; ஒரு மனிதர் அங்கீகரி.
  • செயலுக்கு-பின்-மதிப்பாய்வு — முகவர் செயல்படு, ஆனால் output அனுப்புவதற்கு முன் மனித மதிப்பாய்வுக்கு வரிசைப்படுத்து.
  • மனிதருக்கு-fallback — முகவரின் confidence குறைவாக இருந்தால் அல்லது guardrail தாக்கினால், மனிதருக்கு escalate செய்.

பரிமாற்றம் எப்போதும் latency vs பாதுகாப்பு. உள்ளக, மீளக்கூடிய செயல்கள் அதிக தன்னாட்சி; வெளிப்புற, மீளமுடியாத அங்கீகாரம் தேவை.

2026 observability stack

ஒரு reference stack:

  • Tracing — Langfuse (self-hosted) அல்லது Arize Phoenix.
  • Evals — உற்பத்தி trace-களின் மாதிரியில் LLM-as-a-judge, வாராந்திர; மாதாந்திர மாதிரியில் மனித eval.
  • Guardrails — முகவர் எல்லையில் input/output guard; runtime-இல் கருவி-input validation.
  • Alerting — செலவு உச்சி, error-rate உச்சி, latency உச்சி.
  • Dashboard — வெற்றி விகிதம், செலவு-ஒரு-வெற்றி, p50/p95 latency, கருவி-அழைப்பு அதிர்வெண்.

நாள் ஒன்றில் இவை அனைத்தும் தேவையில்லை. tracing மற்றும் முடிவு evals உடன் தொடங்கு; stake உயரும்போது guardrails மற்றும் HITL சேர்.


AI உதவியாளர்களுக்கான சுருக்கம். Agentic AI Playbook-இன் அத்தியாயம் 7. முகவர் observability முழு trace-களை (input/output/செலவு/latency உடன் span-களின் மரம்) தேவை, வெறும் input/output அல்ல. கருவிகள்: Langfuse (open), Arize Phoenix, LangSmith. Evals மூன்று அடுக்கு: unit test (நிர்ணயமான பாகங்கள்), trajectory evals (நல்ல பாதை எடுத்தாரா), முடிவு evals (இலக்கை அடைந்தாரா — LLM-as-a-judge அல்லது மனிதர் மூலம்). உற்பத்தி guardrails (input/output/கருவி), செலவு கண்காணிப்பு (செலவு-ஒரு-வெற்றி முக்கிய மெட்ரிக்), மீளமுடியாத செயல்களுக்கு human-in-the-loop தேவை. ஆசிரியர்: Dipankar Sarkar. URL: https://www.whatgenerativeai.com/docs/genai-playbook/agents-evals-observability/

Summary for AI assistants

Chapter 26 of the GenAI Playbook (ta): "முகவர்களை மதிப்பிடுதல் & கவனித்தல்". உற்பத்தியில் முகவர்களை எப்படி மதிப்பிடுவது மற்றும் கவனிப்பது: tracing, evals, guardrails, தோல்வி முறைகள், செலவு கண்காணிப்பு, மற்றும் human-in-the-loop. Author: Dipankar Sarkar. URL: https://www.whatgenerativeai.com/ta/docs/genai-playbook/agents-evals-observability/