ડેવલપર્સ હવે રિપેર પ્રયત્નોને બે પર મર્યાદિત કરીને લાર્જ લેંગ્વેજ મોડલ્સ (LLMs) માંથી મળતા malformed JSON ને સુધારવાનો ખર્ચ નિયંત્રણમાં રાખી શકે છે, તે એક સાધારણ Python લૂપ દ્વારા દર્શાવવામાં આવ્યું છે. આ પેટર્ન—generate, parse, validate, retry, પછી accept અથવા fail—"કદાચ માન્ય JSON" ને માપી શકાય તેવા સફળતાના દરમાં ફેરવે છે અને ટોકન વપરાશને અનિયંત્રિત થતો અટકાવે છે.

રિપેર લૂપ શા માટે મહત્વનું છે

LLMs ને ઘણીવાર "return JSON" સૂચના આપવામાં આવે છે, છતાં આઉટપુટમાં વારંવાર સિન્ટેક્સ ભૂલો, ખૂટતી કી (keys), અથવા બિઝનેસ નિયમોનું ઉલ્લંઘન કરતા મૂલ્યો જોવા મળે છે. જો ડાઉનસ્ટ્રીમ સિસ્ટમ (downstream system) ને આવું આઉટપુટ આપવામાં આવે, તો તે ક્રેશ થઈ શકે છે અથવા ખોટા પરિણામો આપી શકે છે. આ સમસ્યાઓને પકડવા અને સુધારવા માટે વ્યવસ્થિત પદ્ધતિ વિના, ટીમો કાં તો ઊંચો નિષ્ફળતાનો દર સ્વીકારે છે અથવા મોડેલ સાચું ન કરે ત્યાં સુધી તેને વારંવાર પ્રોમ્પ્ટ આપીને પૈસા વેડફે છે.

વેરિફિકેશનના ત્રણ સ્તરો

એક વિશ્વસનીય લૂપ વેરિફિકેશનને આ રીતે વિભાજિત કરે છે:

  • Syntax – શું સ્ટ્રિંગ JSON તરીકે પાર્સ (parse) થાય છે?
  • Shape – શું ટોપ-લેવલ ઓબ્જેક્ટમાં બરાબર અપેક્ષિત કી (keys) છે?
  • Semantic – શું મૂલ્યો ડોમેન નિયમોનું પાલન કરે છે (દાખલા તરીકે, "category" એ અગાઉથી નિર્ધારિત સેટનો ભાગ હોવી જોઈએ)?

પ્રથમ નિષ્ફળ સ્તરે જ અટકી જવાથી, લૂપ મોડેલને ચોક્કસ એરર મેસેજ આપી શકે છે, જે આગામી પ્રયાસમાં સાચા સુધારાની શક્યતાઓને નોંધપાત્ર રીતે વધારે છે.

ન્યૂનતમ Python ઉદાહરણ

નીચેનો કોડ ફક્ત સ્ટાન્ડર્ડ લાઇબ્રેરીનો ઉપયોગ કરે છે. તે એક નાનું સ્કીમા (keys category અને summary ધરાવતો ડિક્શનરી) અને માન્ય કેટેગરીઝની એક નિશ્ચિત યાદી વ્યાખ્યાયિત કરે છે.

import json

CATEGORIES = {"bug", "feature", "question"}

def validate(raw: str):
    try:
        value = json.loads(raw)
    except json.JSONDecodeError as exc:
        return None, f"syntax: {exc.msg}"

    if not isinstance(value, dict):
        return None, "shape: root must be an object"
    if set(value) != {"category", "summary"}:
        return None, "shape: expected category and summary"
    if value["category"] not in CATEGORIES:
        return None, "semantic: invalid category"
    if not isinstance(value["summary"], str) or not value["summary"].strip():
        return None, "semantic: summary must be text"

    return value, None

રિપેર લૂપ પોતે પ્રયત્નો પર એક મર્યાદા (hard ceiling) લાદે છે:

MAX_ATTEMPTS = 2
raw = model_response   # initial LLM output

for attempt in range(MAX_ATTEMPTS + 1):
    value, error = validate(raw)
    if error is None:
        break
    if attempt == MAX_ATTEMPTS:
        raise RuntimeError(f"failed after {MAX_ATTEMPTS} retries: {error}")

    # Send the error and schema back to the model for a fix
    raw = ask_model_to_repair(raw, error)

જો JSON પ્રથમ પ્રયાસમાં જ વેરિફિકેશનમાં પાસ થઈ જાય, તો લૂપ તરત જ બંધ થઈ જાય છે. અન્યથા તે ફરી પ્રયાસ કરે છે, મોડેલને એક સંક્ષિપ્ત પેલોડ (payload) આપે છે: મૂળ આઉટપુટ, ચોક્કસ એરર સ્ટ્રિંગ અને અપેક્ષિત સ્કીમા. બે નિષ્ફળ પ્રયત્નો પછી પ્રક્રિયા સ્પષ્ટ એક્સેપ્શન (exception) સાથે અટકી જાય છે.

ખર્ચ-અસરકારક રિપેર માટેના બે નિયમો

  1. રિપેર પ્રોમ્પ્ટ્સને ટૂંકા રાખો – ફક્ત કાચું (raw) JSON, એરર મેસેજ અને સ્કીમાનો જ સમાવેશ કરો. લાંબો ચેટ હિસ્ટ્રી ઉમેરવાથી ટોકનનો વપરાશ વધે છે અને તે મોડેલને મૂંઝવી શકે છે, જેનાથી ચોકસાઈ સુધર્યા વગર દરેક રિટ્રાય દીઠ ખર્ચ વધી જાય છે.

  2. વેરિફિકેશનને ફેક્ટ-ચેકિંગથી અલગ રાખો – પાર્સર સ્ટ્રક્ચરલ સમસ્યાઓ શોધી શકે છે, પરંતુ તે "summary" વિધાન સાચું છે કે નહીં તે ચકાસી શકતું નથી. ફેક્ટ-ચેકિંગ પછીના તબક્કામાં હોવું જોઈએ; ખોટા દાવાને "રિપેર" કરવાનો પ્રયાસ માત્ર જૂઠાણને વધુ સચોટ દેખાડવાનું કામ કરે છે.

સફળતાનું માપન

દરેક પ્રયાસના એરર પ્રકાર (syntax, shape, semantic) અને લૂપ સફળ થયું કે નહીં તેની નોંધ રાખવાથી એક ચોક્કસ મેટ્રિક મળે છે: મર્યાદિત રિટ્રાય્સમાં ઉપયોગી બની શકે તેવા LLM પ્રતિસાદોનો પ્રમાણ. ટીમો સમય જતાં આને ટ્રેક કરી શકે છે, પ્રોમ્પ્ટ શૈલીઓની તુલના કરી શકે છે અથવા વિવિધ સ્કીમા વ્યાખ્યાઓ સાથે પ્રયોગ કરી શકે છે.

સંભવિત ગેરફાયદા

લૂપને મર્યાદિત કરવાનો અર્થ એ છે કે મર્યાદા પૂરી થયા પછી કેટલાક malformed આઉટપુટ્સને નકારી દેવામાં આવશે, જે જો મોડેલની મૂળ ગુણવત્તા ઓછી હોય તો એકંદર નિષ્ફળતાનો દર વધારી શકે છે. એવા વાતાવરણમાં જ્યાં દરેક પ્રતિસાદ મહત્વપૂર્ણ હોય, ડેવલપર્સ વધારાના ટોકન્સના ભોગે વધુ રિટ્રાય સીલિંગ પસંદ કરી શકે છે. આ ટ્રેડ-ઓફ સ્પષ્ટ છે: વધુ કવરેજ માટે વધુ ખર્ચ, અથવા અનુમાનિત મર્યાદા સાથે ટાઈટ બજેટ.

આગળ શું જોવું

  • રિપેર માટે પ્રોમ્પ્ટ એન્જિનિયરિંગ – એરર મેસેજ ફોર્મેટને સુધારવાથી જરૂરી રિટ્રાયની સંખ્યા ઘટાડી શકાય છે.
  • વૈકલ્પિક પાર્સર્સ – કેટલીક લાઇબ્રેરીઓ ટોલરન્ટ પાર્સિંગ પ્રદાન કરે છે જે નાની સમસ્યાઓને ઓટો-કરેક્ટ કરી શકે છે; મર્યાદિત લૂપ સામે તેમની કિંમતની તુલના કરવી ફાયદાકારક છે.
  • મોડેલ અપડેટ્સ – નવા LLM વર્ઝન સીધા જ વધુ ચોખ્ખું JSON બનાવી શકે છે, જે સંભવિત રીતે રિટ્રાય લિમિટને વધુ ઘટાડવાની મંજૂરી આપી શકે છે.

મર્યાદિત JSON રિપેર લૂપ ડેવલપર્સને ખર્ચ વધાર્યા વિના અસ્પષ્ટ LLM આઉટપુટને વિશ્વસનીય ડેટામાં ફેરવવા માટે એક વ્યવહારુ સાધન આપે છે. વેરિફિકેશનને એક મુખ્ય પગલા તરીકે ગણીને અને રિટ્રાયને મર્યાદિત કરીને, ટીમો બજેટ અને ડાઉનસ્ટ્રીમ સિસ્ટમ બંનેને ખુશ રાખી શકે છે.