एजेंट मूल्यांकन के लिए Potato बनाम LangSmith और Langfuse: एक व्यावहारिक तुलना

LangSmith और Langfuse प्रोडक्शन में LLM ऐप्लिकेशन को ट्रेस और मॉनिटर करने के लिए बने हैं। Potato इसलिए बना है कि उन ट्रेस में जो दिखता है उस पर संरचित मानवीय निर्णय जुटाए जाएँ और यह मापा जाए कि निर्णय देने वाले आपस में कितना सहमत हैं। जिन टीमों को दोनों की ज़रूरत होती है, वे आम तौर पर किसी ऑब्ज़र्वेबिलिटी टूल में ट्रेस कैप्चर करती हैं और मानवीय अध्ययन Potato में चलाती हैं।

तीनों टूल इतने ओवरलैप करते हैं कि तुलना अक्सर होती है, और वे सिर्फ़ एक जगह ओवरलैप करते हैं। तीनों किसी एजेंट के रिकॉर्ड किए गए रन के साथ मानवीय निर्णय जोड़ सकते हैं। हर एक किस चीज़ के इर्द-गिर्द व्यवस्थित है, यह अलग है, और यही अंतर तय करता है कि आप जो सवाल पूछ रहे हैं उसके लिए कौन-सा टूल सही बैठता है।

हर टूल किस काम के लिए बना है

LangSmith LLM ऐप्लिकेशन को instrument, ट्रेस और डीबग करता है, और LangChain तथा LangGraph के साथ इसका इंटीग्रेशन सबसे गहरा है। इन फ़्रेमवर्क पर बने ऐप्लिकेशन के ट्रेस बिना अतिरिक्त instrumentation के पहुँचते हैं, और प्लेटफ़ॉर्म रन की जाँच, latency और लागत पर नज़र रखने और डेटासेट पर मूल्यांकन प्रयोग चलाने के इर्द-गिर्द व्यवस्थित है। इसकी एनोटेशन कतारें rubric वाली फ़ीडबैक कुंजियाँ, प्रति रन समीक्षकों की कॉन्फ़िगर करने योग्य संख्या, pairwise कतारें, और ऐसे समीक्षक सपोर्ट करती हैं जो एक-दूसरे का फ़ीडबैक नहीं देख सकते।

Langfuse यही दायरा ओपन सोर्स के रूप में कवर करता है, किसी एक फ़्रेमवर्क के बजाय किसी भी LLM ऐप्लिकेशन के लिए, और ट्रेसिंग के साथ prompt प्रबंधन भी देता है। स्कोरिंग ट्रेस स्तर पर और observation (span) स्तर पर उपलब्ध है, और इसके categorical score configs से लेबल का एक तय सेट परिभाषित किया जा सकता है और एक ही span पर कई नामित स्कोर जोड़े जा सकते हैं।

Potato एक एनोटेशन प्लेटफ़ॉर्म है जिसे एजेंट ट्रेस तक बढ़ाया गया। यह ऐप्लिकेशन के बजाय अध्ययन के इर्द-गिर्द व्यवस्थित है, इसलिए इसकी बुनियादी इकाइयाँ ये हैं कि कौन क्या एनोटेट करता है, हर आइटम कितने लोग देखते हैं, असहमति होने पर क्या होता है, और सहमति के आँकड़े बताते हैं कि लेबल का कोई अर्थ है या नहीं। एजेंट ट्रेस मौजूदा रिलीज़ में रजिस्टर 61 एनोटेशन प्रकारों में से एक आइटम प्रकार भर हैं, और इसी वजह से उन्हें inter-annotator agreement, प्रशिक्षण चरण, adjudication और crowdsourcing विरासत में मिलते हैं, बिना इनमें से कुछ भी एजेंटों के लिए दोबारा बनाए।

तीनों में से कोई भी अमूर्त रूप से बेहतर नहीं है। काम का सवाल यह है कि आपकी अड़चन यह देखना है कि एजेंट ने क्या किया, या उन मानवीय लेबल पर भरोसा करना जो आप उसके बारे में जुटा रहे हैं।

उनके बीच ट्रेस ले जाना

Potato आपके कोड को instrument करने के बजाय ट्रेस को बाद में पढ़ता है, इसलिए यह 15 ट्रेस फ़ॉर्मैट के लिए कन्वर्टर रजिस्टर करता है:

python -m potato.trace_converter --list-formats

सूची में react, openai, anthropic, langchain, langfuse, multi_agent, mcp, otel, atif, webarena, web_agent, swebench, swe_agent_trajectory, claude_code और aider शामिल हैं। LangSmith के रन एक्सपोर्ट langchain कन्वर्टर से गुज़रते हैं, क्योंकि अलग से कोई langsmith कन्वर्टर नहीं है। CrewAI, AutoGen और LangGraph के लॉग multi_agent से गुज़रते हैं।

किसी एक्सपोर्ट को बदलना वर्कफ़्लो की हर दिशा में एक ही कमांड है:

# LangSmith runs, exported from LangSmith, converted for annotation
python -m potato.trace_converter \
  --input langsmith_export.jsonl \
  --output data/traces.jsonl \
  --input-format langchain
 
# Langfuse traces, exported from Langfuse
python -m potato.trace_converter \
  --input langfuse_traces.json \
  --output data/traces.jsonl \
  --input-format langfuse

अगर आपका फ़्रेमवर्क सूची में नहीं है, तो --auto-detect फ़ील्ड के पैटर्न देखकर कन्वर्टर चुनता है, और नया कन्वर्टर BaseTraceConverter की एक subclass होता है। पहचान पहले मेल खाने वाले कन्वर्टर को चुन लेती है, इसलिए जब पता चल जाए कि आपकी फ़ाइलों के लिए कौन-सा फ़ॉर्मैट सही है, तो उसे स्पष्ट रूप से बताएँ।

ट्रेस बिना एक्सपोर्ट चरण के भी आ सकते हैं। Potato का trace ingestion LangSmith के रन payload फ़ॉर्मैट में /api/traces/* पर भेजे गए रन स्वीकार करता है, इसलिए कोई LangChain callback या ट्रेसिंग SDK रन होते ही उन्हें एनोटेशन कतार में भेज सकता है:

trace_ingestion:
  enabled: true
  api_key: "your-api-key"
  notify_annotators: true

ट्रेस आ जाने के बाद Potato क्या जोड़ता है

स्कीमा ही वह जगह है जहाँ एनोटेशन प्लेटफ़ॉर्म अपनी उपयोगिता साबित करता है। trajectory_eval में शुद्धता लेबल, उप-प्रकारों वाला पदानुक्रमित एरर वर्गीकरण, कॉन्फ़िगर करने योग्य भार वाले गंभीरता स्तर और एक चलता हुआ गुणवत्ता स्कोर, सब एक ही ट्रेस से जुड़े एक ही स्कीमा में होते हैं:

annotation_schemes:
  - annotation_type: trajectory_eval
    name: step_evaluation
    description: "Mark each step and classify anything that went wrong"
    steps_key: conversation
    step_text_key: text
    error_types:
      - name: execution
        subtypes: [wrong_tool, wrong_args, api_error]
    severities:
      - name: minor
        weight: -1
      - name: critical
        weight: -10
    show_score: true

ट्रेस की तुलना के लिए गंभीरता के भार ही असली मायने रखते हैं। चिह्नित चरणों की सीधी गिनती बताती है कि एक एजेंट ने चार ग़लतियाँ कीं और दूसरे ने दो, और भारित स्कोर बताता है कि क्या वे चार सिर्फ़ ऊपरी थीं और वे दो ख़तरनाक।

तुलनात्मक मूल्यांकन pairwise स्कीमा से होता है, जिसके तीन मोड हैं। binary मोड दो क्लिक करने योग्य टाइल और एक वैकल्पिक टाई बटन दिखाता है, scale मोड चुनाव की जगह दोनों आइटम के बीच एक स्लाइडर रखता है, और multi_dimension मोड हर नामित आयाम, जैसे उपयोगिता, सटीकता और सुरक्षा, के लिए अलग A/B फ़ैसला माँगता है।

कोडिंग एजेंटों का अपना डिस्प्ले है, क्योंकि JSON स्ट्रिंग के रूप में पढ़ा गया unified diff समीक्षा के लायक नहीं रहता:

unified diff रेंडरिंग, सिंटैक्स हाइलाइटिंग और फ़ाइल ट्री के साथ Potato का कोडिंग ट्रेस डिस्प्ले

coding_trace डिस्प्ले diff को फ़ाइल ट्री के साथ रेंडर करता है और लंबे टर्मिनल आउटपुट को समेट देता है, और code_review स्कीमा कॉन्फ़िगर करने योग्य श्रेणियों में लाइन से जुड़ी टिप्पणियाँ, प्रति-फ़ाइल रेटिंग आयाम और pull request जैसा फ़ैसला जुटाता है। इसके बाद coding_eval एक्सपोर्टर process reward model लेबल, कोड समीक्षा एनोटेशन, DPO preference pair और SWE-bench के अनुकूल स्कोर लिखता है, यानी वह रूप जो प्रशिक्षण डेटा को चाहिए, न कि वह जो किसी डैशबोर्ड को चाहिए।

वेब एजेंट के ट्रेस SVG एक्शन ओवरले वाले स्क्रीनशॉट और एक फ़िल्मस्ट्रिप के रूप में रेंडर होते हैं:

SVG एक्शन ओवरले वाले स्क्रीनशॉट और फ़िल्मस्ट्रिप नेविगेशन दिखाता वेब एजेंट ट्रेस व्यूअर

मल्टी-एजेंट रन को चरणों की एक धारा में समेटने के बजाय उनकी अपनी एनोटेशन सतहें हैं। रजिस्ट्री में एनोटेटर द्वारा संपादित किए जा सकने वाले इंटरैक्शन ग्राफ़, एजेंटों के बीच विफलता का श्रेय तय करने, handoff समीक्षा, प्रति-एजेंट और प्रति-टीम स्कोरकार्ड, साझा टाइमलाइन पर टूल के लिए होड़, और उभरते व्यवहार की टैगिंग के लिए स्कीमा हैं। यही बात embodied और मल्टीमॉडल एजेंटों पर लागू होती है, जहाँ computer-use trajectory, full-duplex वॉइस इंटरैक्शन और वीडियो temporal grounding पूर्ण दर्जे के स्कीमा हैं।

निर्णयों को मापना, सिर्फ़ जुटाना नहीं

किसी प्रोजेक्ट में सबसे देर से जो अंतर दिखता है, वह यह है कि दो एनोटेटरों के असहमत होने के बाद क्या होता है। Potato असहमति को सुलझाए जाने वाले टकराव के बजाय एक माप मानता है, इसलिए टेक्स्ट एनोटेशन अध्ययन जिन सहमति आँकड़ों, adjudication कतार, प्रशिक्षण चरणों और gold आइटम का इस्तेमाल करता है, वही बिना अतिरिक्त कॉन्फ़िगरेशन के एजेंट ट्रेस पर लागू होते हैं। Potato की अपनी टूल तुलना 2026-06-24 की जाँच के अनुसार दर्ज करती है कि ट्रेसिंग प्लेटफ़ॉर्म मानवीय निर्णयों को स्कोर के रूप में जुटाने के लिए बने हैं और उनमें से कोई भी उन निर्णयों पर reliability आँकड़ा दस्तावेज़ित नहीं करता, और यह भी कि Langfuse उसी ट्रेस पर पिछले एनोटेशन की जगह नया एनोटेशन रख देता है, इसलिए वहाँ स्वतंत्र दोहरे एनोटेशन के लिए कोई जुगाड़ करना पड़ता है।

यह तब मायने रखता है जब मूल्यांकन ही सबूत हो। बिना समीक्षा वाले एकल निर्णयों से बनी सफलता दर का कोई error bar नहीं होता, और भटक चुका समीक्षक हूबहू ऐसे एजेंट जैसा दिखता है जिसमें सुधार हुआ हो।

चलते हुए एजेंट को देखना

Potato रिकॉर्डिंग दोबारा चलाने के बजाय एनोटेशन पेज के भीतर एजेंट चला भी सकता है। live_agent ब्लॉक एक vision मॉडल को headless ब्राउज़र से जोड़ता है और सत्र को एनोटेटर तक स्ट्रीम करता है, जो उसे रोक सकता है, निर्देश भेज सकता है या मैन्युअल नियंत्रण अपने हाथ में ले सकता है:

live_agent:
  endpoint_type: anthropic_vision
  ai_config:
    model: claude-sonnet-4-20250514
    api_key: ${ANTHROPIC_API_KEY}
  max_steps: 30
  allow_takeover: true
  allow_instructions: true
 
instance_display:
  fields:
    - key: agent_trace
      type: live_agent
      label: "Live Agent Session"
      display_options:
        show_overlays: true
        show_filmstrip: true

तीन स्थितियों में यह सेटअप बाद की समीक्षा से ज़्यादा फ़ायदेमंद है। किसी विनाशकारी कार्रवाई से पहले रन रोकना एक सुरक्षा उपाय है जो रिकॉर्ड किए गए ट्रेस नहीं दे सकते। रन के बीच में रिकॉर्ड किया गया मानवीय नियंत्रण प्रदर्शन डेटा बन जाता है। और यह देखना कि एजेंट किसी हस्तक्षेप से कैसे उबरता है, एक ऐसे सवाल का जवाब देता है जो किसी पूरे हो चुके ट्रेस में नहीं होता।

दोनों को साथ चलाना

प्रोडक्शन का आम सेटअप दोनों का इस्तेमाल करता है, और बँटवारा साफ़ है क्योंकि दोनों टूल अलग चीज़ें चाहते हैं। एजेंट को LangSmith या Langfuse से instrument करें और हर रन को ट्रेस होने दें। उन रन का नमूना लें जिन पर मानवीय राय ज़रूरी है, जो आम तौर पर विफलताएँ, सीमांत मामले और एक यादृच्छिक नियंत्रण नमूना होते हैं। उन्हें Potato के लिए बदलें, हर ट्रेस पर कई एनोटेटरों के साथ एनोटेशन अध्ययन चलाएँ, और स्कोर के साथ सहमति रिपोर्ट पढ़ें। एरर वर्गीकरण की गिनतियाँ वापस डेवलपमेंट में दें, जहाँ उप-प्रकारों का वितरण बताता है कि आपके पास एक व्यवस्थित विफलता है या एक लंबी पूँछ।

python -m potato.trace_converter \
  --input langfuse_failed_traces.json \
  --output data/traces_to_review.jsonl \
  --input-format langfuse
 
potato start config.yaml -p 8000

चुनाव

LangSmith तब चुनें जब ऐप्लिकेशन LangChain या LangGraph पर बना हो और ज़रूरत प्रोडक्शन में दृश्यता की हो, क्योंकि ट्रेस बिना instrumentation के काम के पहुँचते हैं और managed सेवा इंफ़्रास्ट्रक्चर का सवाल ही ख़त्म कर देती है। Langfuse तब चुनें जब आपको वही दृश्यता ओपन सोर्स के रूप में कई प्रदाताओं के साथ चाहिए, और उसी टूल में prompt versioning भी। Potato तब चुनें जब आपको जो नतीजा चाहिए वह मानवीय लेबल का ऐसा सेट हो जिसका बचाव किया जा सके, जब अध्ययन में हर आइटम पर कई एनोटेटर और एक सहमति आँकड़ा चाहिए, जब एजेंट कोडिंग, मल्टी-एजेंट या embodied इस हद तक हों कि ट्रेस को ख़ास उसी के लिए बना डिस्प्ले चाहिए, या जब डेटा को आपके अपने इंफ़्रास्ट्रक्चर पर ही रहना हो। Potato GPL-3.0-or-later के तहत है और self-hosted है, जिसमें प्रति सीट या प्रति ट्रेस कोई लागत नहीं है।

यहाँ LangSmith और Langfuse के बारे में कही गई बातें 2026-06-24 को देखे गए उनके दस्तावेज़ों पर आधारित हैं, और दोनों तेज़ी से बदलाव जारी करते हैं। सुधार GitHub रिपॉज़िटरी पर स्वागत योग्य हैं। सेटअप के लिए एजेंट मूल्यांकन गाइड देखें, और कच्चे ट्रेस से लेकर एक्सपोर्ट किए गए निर्णयों तक के पूरे उदाहरण के लिए AI एजेंटों का मूल्यांकन देखें।