Mercury 3 ट्यूटोरियल: रियल-टाइम इन्सिडेंट विश्लेषण असिस्टेंट बनाना

यह केवल एक वैचारिक उदाहरण है, Mercury 3 का सटीक आंतरिक प्रतिनिधित्व नहीं।

Inception का API इन इंटरमीडिएट स्टेट्स को एक्सपोज़ कर सकता है। सामान्य स्ट्रीमिंग में, Mercury परिष्कृत टेक्स्ट के ब्लॉक्स लौटाता है जिन्हें उत्तर में जोड़ा जा सकता है। diffusing=True के साथ, प्रत्येक चंक में मॉडल के परिष्करण के साथ उत्तर का वह समय का संपूर्ण वर्तमान संस्करण होता है।

हम अंतर को जल्द ही देखेंगे।

डेमो: रियल-टाइम सपोर्ट एस्केलेशन असिस्टेंट बनाना

डेमो बनाने से पहले, आइए मॉडल सेटिंग्स को स्वयं सपोर्ट एप्लिकेशन से अलग करते हैं।

सपोर्ट केस केवल वह इनपुट है जिसका हम Mercury 3 को अभ्यास कराने के लिए उपयोग करते हैं। महत्वपूर्ण मॉडल-पक्ष नियंत्रण हैं रीज़निंग बजट, कम्प्लीशन बजट और स्ट्रीमिंग मोड।

ये इस प्रयोग के लिए वर्किंग सेटिंग्स हैं, Mercury 3 के लिए सार्वभौमिक रूप से सर्वोत्तम सेटिंग्स नहीं।

चरण 1: आवश्यकताएँ

Mercury 3 शुरू करने के लिए कुछ ही कदम लेता है। साथ चलने के लिए, आपको चाहिए:

• एक Inception API कुंजी
• Python 3
• inceptionai पैकेज
• case_support.json के रूप में सहेजा हुआ सपोर्ट केस

शुरुआत करें inception प्लेटफ़ॉर्म पर साइन अप करके और API कुंजी प्राप्त करके। Get Started पर क्लिक करें और विवरण भरें:

नोट: लिखते समय, Inception नए खातों को API आज़माने के लिए 100 मिलियन मुफ्त टोकन प्रदान करता है।

आप अपनी API कुंजी का नाम रख सकते हैं या बस इस चरण को छोड़कर Create Key पर क्लिक करें।

अगला, API कुंजी कॉपी करें और अपनी पहली API कॉल करें। 

चरण 2: Mercury 3 आज़माएँ

कोई कोड लिखने से पहले, आप सीधे Inception प्लेटफ़ॉर्म से Mercury 3 का परीक्षण कर सकते हैं। API कुंजी बनाने के बाद, Next पर क्लिक करें और Try It Out टैब पर Run it now बटन चुनें।

यह प्रॉम्प्ट्स और मॉडल सेटिंग्स को किसी एप्लिकेशन में ले जाने से पहले तेजी से टेस्ट करने के लिए उपयोगी है।

चरण 3: वातावरण तैयार करें और एक API कॉल करें

शेष ट्यूटोरियल के लिए, हम Python से Mercury 3 को कॉल करेंगे। शुरुआत करें Inception SDK इंस्टॉल करके और API कुंजी को इस प्रकार एक्सपोर्ट करके:

!pip install -q inceptionaiसंचालित द्वारा

फिर डेमो द्वारा उपयोग किए गए पैकेज इम्पोर्ट करें:

import getpass, json, os, time, difflib
from pathlib import Path
from inceptionai import Inception
from IPython.display import clear_outputसंचालित द्वारा

getpass API कुंजी को इको किए बिना पूछता है, os इसे वहाँ रखता है जहाँ SDK इसे ढूंढता है, Path और json case_support.json लोड करते हैं और इसे प्रॉम्प्ट में सीरियलाइज़ करते हैं, और time.perf_counter() रिकॉर्ड करता है कि प्रत्येक प्रतिक्रिया और परिष्करण अवस्था कब आती है।

difflib क्रमिक डिफ्यूजन स्टेट्स की तुलना करता है और clear_output() सेल आउटपुट को बदल देता है ताकि रिप्ले पेज पर नीचे स्टैक होने के बजाय उसी जगह हो।

यदि API कुंजी पहले से सेट नहीं है, तो आप इसे इंटरैक्टिव रूप से पूछ सकते हैं:

if not os.environ.get("INCEPTION_API_KEY"):
    os.environ["INCEPTION_API_KEY"] = getpass.getpass(
        "Inception API key: "
    )
client = Inception()
MODEL = "mercury-3"
print("ready")संचालित द्वारा

Inception() पर्यावरण से API कुंजी पढ़ता है। जबकि अन्य इम्पोर्ट्स, जैसे time परिष्करण अवस्थाएँ कब आती हैं यह रिकॉर्ड करता है, difflib इंटरमीडिएट टेक्स्ट की तुलना में मदद करता है, और clear_output() हमें डिफ्यूजन प्रक्रिया को उसी जगह रिप्ले करने देता है।

चरण 4: मॉडल संदेश बनाएं

सपोर्ट केस अलग से case_support.json में संग्रहीत है। केस फ़ाइल में ग्राहक संदेश, ऑर्डर जानकारी, भुगतान रिकॉर्ड, फुलफ़िलमेंट लॉग, सपोर्ट नीति और इस परिदृश्य के लिए उपयोग किए जाने वाले प्रॉम्प्ट्स शामिल हैं।

आप अपना खुद का बना सकते हैं या इसे ऐसे ही उपयोग कर सकते हैं:

{
  "scenario": "Customer reports two charges for one order",
  "system_prompt": "You are a customer-support escalation assistant.\nUse only the evidence in the supplied case file.\nSeparate what the evidence shows from what you infer.\nDo not state that a refund has been issued unless the case file says so.\nIf the evidence is insufficient to decide, say so explicitly.",
  "task_prompt": "Analyze this customer-support case.\n\nReturn:\n1. The most likely explanation.\n2. Three pieces of evidence from the case file that support it.\n3. Two alternative explanations, and what is still uncertain.\n4. The next three actions for the agent, in priority order.\n\nKeep the answer concise. Write it so the customer could read it.",
  "packet_label": "CASE FILE",
  "customer_message": "I ordered one pair of headphones yesterday evening and my card now shows two charges of $129 each. I have one confirmation email and one tracking number. I only pressed buy once. Please refund the second charge today, I cannot afford to be out $258.",
  "order": {
    "order_id": "ORD-1048",
    "placed_at": "2026-10-28T19:41:08Z",
    "status": "shipped",
    "shipped_at": "2026-10-29T08:12:00Z",
    "item": "wireless headphones",
    "quantity": 1,
    "amount_usd": 129,
    "orders_on_account_that_day": 1
  },
  "payment_records": [
    {
      "entry": 1,
      "at": "2026-10-28T19:41:11Z",
      "amount_usd": 129,
      "status": "completed",
      "authorization_code": "A7X41K",
      "card_last_four": "4417"
    },
    {
      "entry": 2,
      "at": "2026-10-28T19:42:45Z",
      "amount_usd": 129,
      "status": "pending",
      "authorization_code": "B2M09T",
      "card_last_four": "4417"
    }
  ],
  "fulfillment_log": [
    "19:41:12 reserved 1 unit for ORD-1048",
    "19:42:47 reserved 1 unit (no order id attached)",
    "19:58:30 released 1 unreserved unit back to stock",
    "08:12:00 shipped 1 unit against ORD-1048, one tracking number issued"
  ],
  "customer_history": [
    {
      "date": "2026-10-07",
      "contact_reason": "reported two charges for one order",
      "outcome": "both charges settled; agent issued a refund for one of them"
    },
    {
      "date": "2026-06-19",
      "contact_reason": "delivery address change",
      "outcome": "resolved, no payment involved"
    }
  ],
  "support_policy": [
    "A pending card authorization can appear on a customer statement as a second charge.",
    "A pending authorization that is never captured usually disappears within 3-5 business days.",
    "Escalate to the payments team if both charges settle.",
    "Agents may not issue a refund against an authorization that has not settled.",
    "Tell the customer what you have confirmed and what you have not."
  ],
  "available_agent_actions": [
    "explain the pending authorization to the customer",
    "set a follow-up for a named number of business days",
    "escalate to the payments team",
    "issue a refund for a settled charge",
    "request the authorization expiry date from the payment processor"
  ]
}संचालित द्वारा

अब, JSON फ़ाइल लोड करें:

def load_incident(path: str) -> dict:
    return json.loads(Path(path).read_text())
case = load_incident("case_support.json")संचालित द्वारा

इसे Mercury 3 को भेजने से पहले, हम प्रॉम्प्ट कॉन्फ़िगरेशन को साक्ष्य से अलग करते हैं:

PROMPT_KEYS = (
    "system_prompt",
    "task_prompt",
    "packet_label",
)
def build_messages(case: dict):
    system = case.get("system_prompt", SYSTEM)
    task = case.get("task_prompt", TASK)
    label = case.get(
        "packet_label",
        "INCIDENT PACKET",
    )
    evidence = {
        k: v
        for k, v in case.items()
        if k not in PROMPT_KEYS
    }
    packet = json.dumps(evidence, indent=2)
    return [
        {
            "role": "system",
            "content": system,
        },
        {
            "role": "user",
            "content": (
                f"{task}\n\n"
                f"{label}:\n{packet}"
            ),
        },
    ]संचालित द्वारा

कुंजियाँ system_prompt, task_prompt, और packet_label नियंत्रित करती हैं कि हम Mercury को कैसे निर्देश देते हैं, इसलिए उन्हें साक्ष्य से हटा दिया जाता है, इससे पहले कि केस को स्वयं सीरियलाइज़ किया जाए। अब हम अंतिम संदेश तैयार कर सकते हैं:

messages = build_messages(case)संचालित द्वारा

यहाँ कोई रिट्रीवल सिस्टम या बाहरी टूल शामिल नहीं है। इस विश्लेषण के लिए Mercury को आवश्यक हर चीज सीधे रिक्वेस्ट में दी गई है।

चरण 5: Mercury 3 को रिक्वेस्ट करें 

स्ट्रीमिंग का परीक्षण करने से पहले, एक सामान्य नॉन-स्ट्रीमिंग रिक्वेस्ट बनाते हैं। निम्नलिखित हेल्पर Mercury API कॉल को रैप करता है और प्रतिक्रिया मेटाडेटा रिकॉर्ड करता है:

def usage_dict(response) -> dict:
    usage = getattr(response, "usage", None)

    if usage is None:
        return {}

    if hasattr(usage, "model_dump"):
        return usage.model_dump()

    return dict(usage)संचालित द्वारा

अब एक मॉडल कॉल परिभाषित करते हैं:

def run_nonstream(
    client,
    messages,
    effort: str,
    max_tokens: int,
):
    start = time.perf_counter()
    response = client.chat.completions.create(
        model=MODEL,
        messages=messages,
        reasoning_effort=effort,
        temperature=0.75,
        max_completion_tokens=max_tokens,
    )
    elapsed = time.perf_counter() - start
    choice = response.choices[0]
    text = choice.message.content or ""
    usage = usage_dict(response)
    return {
        "effort": effort,
        "elapsed_s": elapsed,
        "finish_reason": choice.finish_reason,
        "usage": usage,
        "text": text,
    }संचालित द्वारा

मुख्य मॉडल-पक्ष नियंत्रण हैं:

reasoning_effort=effort
temperature=0.75
max_completion_tokens=max_tokensसंचालित द्वारा

अब हम एक बेसलाइन कॉल कर सकते हैं:

result = run_nonstream(
    client,
    messages,
    effort="low",
    max_tokens=8192,
)
print(result["text"])संचालित द्वारा

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

यह फ़ंक्शन elapsed_s और usage फ़ील्ड भी रिकॉर्ड करता है। पहला एंड-टू-एंड रिक्वेस्ट समय मापता है, जबकि दूसरा टोकन अकाउंटिंग, जिसमें क्रमशः रिपोर्टेड रीज़निंग-टोकन उपयोग शामिल है।

इस ट्यूटोरियल के लिए उपयोग किए गए रन में, Mercury ने लगातार दूसरी भुगतान एंट्री को एक लंबित ऑथराइज़ेशन माना, न कि किसी पुष्टि किए गए दूसरे ऑर्डर का साक्ष्य। हालांकि, केस में जानबूझकर पर्याप्त जानकारी की कमी है, जिससे यह पता नहीं चलता कि वह लंबित ऑथराइज़ेशन अंततः गायब होगा या सेटल होगा।

चरण 6: स्टैंडर्ड स्ट्रीमिंग जोड़ें

एक सामान्य रिक्वेस्ट Mercury के समाप्त होने की प्रतीक्षा करता है और फिर पूरा उत्तर देता है। उत्तर को क्रमशः प्राप्त करने के लिए, हमें stream=True सक्षम करना होगा। स्टैंडर्ड स्ट्रीमिंग फ़ंक्शन इस तरह दिखता है:

def run_standard_stream(
    client,
    messages,
    effort: str,
    max_tokens: int,
):
    start = time.perf_counter()
    first_output = None
    finish_reason = None
    chunks = []
    stream = client.chat.completions.create(
        model=MODEL,
        messages=messages,
        reasoning_effort=effort,
        temperature=0.75,
        max_completion_tokens=max_tokens,
        stream=True,
    )
    for chunk in stream:
        choices = getattr(
            chunk,
            "choices",
            None,
        ) or []
        if (
            choices
            and getattr(
                choices[0],
                "finish_reason",
                None,
            )
        ):
            finish_reason = choices[0].finish_reason
        content = extract_delta_text(chunk)
        if content:
            now = time.perf_counter()
            if first_output is None:
                first_output = now
            chunks.append(content)
            print(
                content,
                end="",
                flush=True,
            )
    end = time.perf_counter()
    return {
        "time_to_first_output_s": (
            first_output - start
            if first_output
            else None
        ),
        "total_s": end - start,
        "num_chunks": len(chunks),
        "finish_reason": finish_reason,
        "final_text": "".join(chunks),
    }संचालित द्वारा

यहाँ महत्वपूर्ण व्यवहार chunks.append(content) है स्टैंडर्ड स्ट्रीमिंग में, जहाँ प्रत्येक चंक उत्तर के अगले हिस्से को रखता है, इसलिए चंक्स को जोड़ा जा सकता है और "".join(chunks) से अंतिम उत्तर में पुनर्निर्मित किया जा सकता है।

नोट: मीडियन समय पहले दृश्य आउटपुट तक 2.903 सेकंड था, जबकि मीडियन कुल लेटेंसी 3.375 सेकंड थी।

चरण 7: डिफ्यूजन स्ट्रीमिंग पर स्विच करें

डिफ्यूजन स्ट्रीमिंग सक्षम करने के लिए, निम्न पैरामीटर्स को True पर सेट करें:

stream=True
diffusing=Trueसंचालित द्वारा

API कॉल स्टैंडर्ड स्ट्रीमिंग से केवल एक अतिरिक्त आर्गुमेंट में भिन्न है, यानी diffusing=True। 

def run_diffusion_stream(
    client,
    messages,
    effort: str,
    max_tokens: int,
    live: bool = True,
):
    start = time.perf_counter()
    first_output = None
    finish_reason = None
    states = []
    empty_chunks = 0
    stream = client.chat.completions.create(
        model=MODEL,
        messages=messages,
        reasoning_effort=effort,
        temperature=0.75,
        max_completion_tokens=max_tokens,
        stream=True,
        diffusing=True,
    )
    for chunk in stream:
        choices = getattr(
            chunk,
            "choices",
            None,
        ) or []
        if (
            choices
            and getattr(
                choices[0],
                "finish_reason",
                None,
            )
        ):
            finish_reason = choices[0].finish_reason
        content = extract_delta_text(chunk)
        if not content:
            empty_chunks += 1
            continue
        now = time.perf_counter()
        if first_output is None:
            first_output = now
        states.append({
            "t_s": now - start,
            "text": content,
        })
        if live:
            clear_output(wait=True)
            print(content, flush=True)
    end = time.perf_counter()
    return {
        "time_to_first_output_s": (
            first_output - start
            if first_output
            else None
        ),
        "total_s": end - start,
        "num_refinement_states": len(states),
        "finish_reason": finish_reason,
        "final_text": (
            states[-1]["text"]
            if states
            else ""
        ),
        "states": states,
    }संचालित द्वारा

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

हम लौटाए गए स्टेट्स को भी रखते हैं ताकि परिष्करण अवस्थाओं की संख्या मापी जा सके और यह जाँचा जा सके कि बाद की अवस्थाएँ वास्तव में पहले दिखाई दिए टेक्स्ट को संशोधित करती हैं या नहीं।

पाँच रनों में, डिफ्यूजन स्ट्रीमिंग ने 9 दृश्यमान परिष्करण अवस्थाओं का मीडियन लौटाया, रेंज 7–12 रही। पहले दृश्यमान स्टेट तक का मीडियन समय 1.896 सेकंड था, और कुल मीडियन लेटेंसी 2.560 सेकंड थी।

चरण 8: स्टैंडर्ड और डिफ्यूजन स्ट्रीमिंग की तुलना

अब जब हम दोनों कोड पाथ समझते हैं, तो हम मापे गए व्यवहार की तुलना कर सकते हैं।

इस विशेष सपोर्ट प्रॉम्प्ट के लिए डिफ्यूजन में मीडियन लेटेंसी कम थी, लेकिन रेंज काफी हद तक ओवरलैप होती है। इसलिए, हमें यह निष्कर्ष नहीं निकालना चाहिए कि डिफ्यूजन स्ट्रीमिंग स्वभावतः तेज़ है।

चित्र: 12-स्टेट रन, ट्रांज़िशन दर ट्रांज़िशन। भूरे रंग की पट्टी वह टेक्स्ट है जिसे Mercury 3 ने पहले लिखा था और फिर बदल दिया, जबकि नीली पट्टी पिछले अंत से आगे का नया टेक्स्ट है। एक शुद्ध अपेंड में बिल्कुल भी भूरा नहीं दिखेगा।

मेरे रनों में, लौटाए गए डिफ्यूजन स्टेट्स ने पहले से दृश्यमान टेक्स्ट को संशोधित किया, न कि अपेंड-ओनली चंक्स जैसा व्यवहार किया। ऊपर के रन में, 11 में से कोई भी स्टेट ट्रांज़िशन शुद्ध अपेंड नहीं था, और हर एक अपने पहले वाले स्टेट से पहले 14 अक्षरों के भीतर भिन्न हो गया।

चरण 9: कम्प्लीशन बजट का परीक्षण करें

अगला, देखते हैं कि Mercury 3 का व्यवहार कैसा होता है जब रीज़निंग टोकन कम्प्लीशन बजट के साथ इंटरैक्ट करते हैं। ऊपर की सामान्य कॉल्स max_completion_tokens=8192 का उपयोग करती हैं, लेकिन व्यवहार को और स्पष्ट रूप से दिखाने के लिए हमें max_completion_tokens को 1600 तक घटाना होगा।

अब, वही रिक्वेस्ट एक बार लो और एक बार हाई रीज़निंग प्रयास पर चलाएँ। यहाँ मापा गया परिणाम है:

LOW
completion_tokens: 964
reasoning_tokens:  620
finish_reason:     stop
visible answer:    returned

HIGH
completion_tokens: 1539
reasoning_tokens:  1539
finish_reason:     length
visible answer:    noneसंचालित द्वारा

हाई पर, सभी 1,539 कम्प्लीशन टोकन रीज़निंग टोकन के रूप में रिपोर्ट हुए। इसलिए, मॉडल ने दृश्य उत्तर टेक्स्ट लौटाने से पहले कम्प्लीशन सीमा तक पहुँच बना ली।

चित्र: 1,600 और 8,192 टोकन कैप पर हाई-एफ़र्ट कम्प्लीशन बजट

1,600 कैप पर, पूरा बजट रीज़निंग में चला गया और इमिट करने के लिए कुछ नहीं बचा। 8,192 पर, मीडियन हाई-एफ़र्ट रन ने 2,292 टोकन रीज़निंग में लगाए और फिर भी 412-टोकन के उत्तर के लिए जगह बची। 8,192 कैप इस स्केल के दाएँ किनारे के बाहर बैठता है, इसलिए ऊपर की छवि में केवल पहली पंक्ति एक डैश्ड कैप लाइन दिखाती है।

फेल हुई हाई रिक्वेस्ट में महत्वपूर्ण संकेत है response.choices[0].finish_reason, जिसने length लौटाया। इसका मतलब है कि रिक्वेस्ट अपने अधिकतम कम्प्लीशन-टोकन बजट (max_completion_tokens) तक पहुँच गई। यह बजट रीज़निंग टोकन्स और दृश्य आउटपुट टोकन्स दोनों को शामिल करता है। इस रन में, Mercury 3 ने सभी 1,539 कम्प्लीशन टोकन्स को रीज़निंग टोकन्स के रूप में रिपोर्ट किया, इसलिए रिक्वेस्ट ने दृश्य उत्तर बनाने से पहले कम्प्लीशन सीमा तक पहुँच बना ली।

नोट: इस डेमो के लिए, शेष रनों में max_completion_tokens=8192 पर्याप्त था, लेकिन इसे सार्वभौमिक न्यूनतम नहीं माना जाना चाहिए।

चरण 10: लो और हाई रीज़निंग प्रयास की तुलना

अब सामान्य 8192 कम्प्लीशन बजट पर लौटें और केवल reasoning_effort को लो और हाई के बीच बदलें। हम चरण 5 के run_nonstream() हेल्पर का उपयोग करेंगे—एक रिक्वेस्ट लो रीज़निंग प्रयास के साथ और दूसरी हाई के साथ:

results = []

for effort in ["low", "high"]:
    result = run_nonstream(
        client,
        messages,
        effort=effort,
        max_tokens=8192,
    )
    results.append(result)

    print(
        effort,
        result["elapsed_s"],
        result["usage"],
    )संचालित द्वारा

रिपोर्ट किए गए परिणामों के लिए, मैंने एक ही रिक्वेस्ट पर निर्भर होने के बजाय प्रत्येक कॉन्फ़िगरेशन को पाँच बार दोहराया।

मीडियन्स थे:

मीडियन रीज़निंग उपयोग 828 से 2,292 टोकन तक बढ़ा, जबकि मीडियन लेटेंसी 2.936 से 8.146 सेकंड (लगभग 2.77x) तक बढ़ी।

चित्र: प्रत्येक प्रयास स्तर पर कम्प्लीशन बजट कहाँ जाता है?

दृश्य उत्तर की लंबाई में उतना बदलाव नहीं आया:

• लो: 468-टोकन मीडियन
• हाई: 412-टोकन मीडियन

और देखी गई रेंज ओवरलैप हुई:

• लो: 393–494
• हाई: 356–469

तो, ये रन इस दावे का समर्थन नहीं करते कि रीज़निंग प्रयास बढ़ाने से दृश्य उत्तर छोटा हो जाता है। लेटेंसी रेंज भी दिखाती है कि एक रन पर्याप्त नहीं है:

• लो: 1.602–4.993 s
• हाई: 4.102–9.068 s

नोट: सबसे तेज़ हाई रिक्वेस्ट वास्तव में सबसे धीमी लो रिक्वेस्ट से भी तेज़ थी।

चित्र: सभी दस रीज़निंग-एफ़र्ट रिक्वेस्ट्स लेटेंसी के अनुसार प्लॉट किए गए

तो, reasoning_effort="high" ने इस प्रयोग में रिपोर्टेड रीज़निंग-टोकन उपयोग और लेटेंसी को काफी बढ़ा दिया, जबकि दृश्य उत्तर की लंबाई व्यापक रूप से समान रही।

अंतिम विचार

Mercury 3 के तीन व्यावहारिक व्यवहार हैं:

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

• रीज़निंग टोकन कम्प्लीशन बजट साझा करते हैं। एक छोटा max_completion_tokens मान Mercury 3 द्वारा दृश्य उत्तर देने से पहले ही रीज़निंग में समाप्त हो सकता है।

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

ये परिणाम एक सिंथेटिक सपोर्ट केस पर थोड़े से रनों से आए हैं, इसलिए इन्हें इस डेमो से अवलोकन के रूप में माना जाना चाहिए, न कि Mercury 3 के बारे में सामान्य प्रदर्शन दावों के रूप में।