Evaluating LLM Output Quality In Production

மார்ச் 2023 இல், GPT-4 97.6% துல்லியத்துடன் பகா எண்களைக் (prime numbers) கண்டறிந்தது. ஜூன் 2023 ஆகிவிட்டபோது, அதே மாதிரியின் துல்லியம் 2.4% ஆகக் குறைந்தது. யாரும் குறியீட்டை (code) மாற்றவில்லை. யாரும் ப்ராம்ப்ட்டை (prompt) மாற்றவில்லை. அந்த மாதிரி தானாகவே மாறியது.

தயாரிப்பில் (production) LLM-களுடன் இருக்கும் முக்கியப் பிரச்சனை இதுதான். மாதிரியை (model) உங்களால் கட்டுப்படுத்த முடியாது. அது காலப்போக்கில் மாறக்கூடிய ஒரு சார்புநிலை (dependency). நீங்கள் அதை அளவிடவில்லை என்றால், அது பழுதாகிவிட்டது என்று உங்கள் பயனர்களே உங்களுக்குச் சொல்வார்கள்.

வெறும் உணர்வுகளையோ அல்லது "எனக்கு நன்றாகத் தெரிகிறது" என்பதையோ மட்டும் நம்பிவிட முடியாது. உங்களுக்குத் திரும்பத் திரும்பப் பெறக்கூடிய சமிக்ஞைகள் (repeatable signals) தேவை.

பாரம்பரிய மென்பொருள்கள் தீர்மானிக்கத்தக்கவை (deterministic). ஒரே உள்ளீடு (input) எப்போதும் ஒரே வெளியீட்டைத் (output) தரும். LLM-கள் இந்த விதியை மீறுகின்றன. அவை தீர்மானிக்க முடியாதவை (non-deterministic) மற்றும் "சரியானது" என்பது பெரும்பாலும் தெளிவற்றதாக இருக்கும்.

இதை நிர்வகிக்க, உங்களுக்கு மூன்று அடுக்கு மதிப்பீடுகள் தேவை:

  • Offline evals: பின்னடைவுகளைக் (regressions) கண்டறிய ஒவ்வொரு மாற்றத்திலும் ஒரு நிலையான சோதனைத் தொகுப்பை (fixed test set) இயக்கவும்.
  • Reference-free checks: உங்களிடம் சரியான விடை இல்லாதபோது, மாயத்தோற்றத்தைக் கண்டறிதல் (hallucination detection) போன்ற சமிக்ஞைகளைப் பயன்படுத்தவும்.
  • Production monitoring: தரக் குறைவு மற்றும் மாற்றங்களைக் கண்காணிக்க உண்மையான டிராஃபிக்கைக் (traffic) கவனிக்கவும்.

இதன் அடிப்படை ஒரு Golden Dataset ஆகும். சீரற்ற மாதிரிகளை (random samples) பயன்படுத்த வேண்டாம். கவனமாகத் தேர்ந்தெடுக்கப்பட்ட கடினமான நிகழ்வுகளைப் பயன்படுத்தவும். காலியான உள்ளீடுகள், விசித்திரமான விளிம்பு நிலை நிகழ்வுகள் (edge cases) மற்றும் எதிரித்தனமான ப்ராம்ப்ட்களைப் (adversarial prompts) பயன்படுத்தவும். 8,000 சீரற்ற உதாரணங்களை விட 80 துல்லியமான உதாரணங்கள் சிறந்தவை.

ஒரு LLM-ஐத் தீர்ப்பாளராகப் (judge) பயன்படுத்தும்போது, இந்தத் சார்புகளைக் (biases) கவனியுங்கள்:

  • Position bias: தீர்ப்பாளர்கள் பெரும்பாலும் தாங்கள் முதலில் பார்க்கும் பதிலையே ஆதரிப்பார்கள். ஒப்பீடுகளை இரு வரிசைகளிலும் (both orders) செய்வதன் மூலம் இதைச் சரிசெய்யலாம்.
  • Verbosity bias: பதில்கள் தெளிவாக இல்லாவிட்டாலும், நீளமான பதில்களுக்குத் தீர்ப்பாளர்கள் அதிக முக்கியத்துவம் அளிக்கிறார்கள்.
  • Self-enhancement bias: மாதிரிகள் தங்களது சொந்தக் குடும்பத்தைச் சேர்ந்த உரைகளையே விரும்புகின்றன. வெளியீடுகளைத் தீர்ப்பளிக்க வெவ்வேறு மாதிரி குடும்பங்களைப் (model families) பயன்படுத்தவும்.

நிகழ்நேரக் கண்காணிப்பிற்கு (real-time monitoring), பின்வருவனவற்றைச் சரிபார்க்க RAG Triad-ஐப் பயன்படுத்தவும்:

  • Faithfulness: பதில் சூழலோடு (context) ஒத்துப்போகிறதா?
  • Answer relevance: அது கேள்விக்குப் பதிலளிக்கிறதா?
  • Context relevance: சிஸ்டம் சரியான ஆவணங்களை எடுத்ததா?

மாதிரியின் தரத்தை ஒரு நிலையான பண்பாகக் கருதுவதை நிறுத்துங்கள். அதை லேட்டன்சி (latency) அல்லது பிழை விகிதங்களைப் (error rates) போலக் கருதுங்கள். அது மாறிக் கொண்டே இருக்கும். அது எப்போது சரியில்லாமல் போகிறது என்பதைக் கண்டறிவதே உங்கள் வேலை.

சிறிய அளவில் தொடங்குங்கள். 20 golden உதாரணங்களை எழுதுங்கள். உங்கள் வெளியீடுகளைக் (deploys) கட்டுப்படுத்த அவற்றைப் பயன்படுத்தவும். பின்னர் மலிவான production heuristics-களைச் சேர்க்கவும்.

நிம்மதியாகத் தூங்கும் குழுக்கள் மிகவும் புத்திசாலித்தனமான மாதிரிகளைக் கொண்டவை அல்ல. மாறாக, தங்கள் மாதிரி அறிவாற்றலை இழக்கும்போது (gets dumber) ஒரு மணி நேரத்திற்குள் அதைத் தெரிந்துகொள்ளும் குழுக்களே நிம்மதியாகத் தூங்குகின்றன.

Source: https://dev.to/nazar_boyko/evaluating-llm-output-quality-in-production-39an

Optional learning community: https://t.me/GyaanSetuAi