Tutorial Mercury 3: Construirea unui asistent de analiză a incidentelor, în timp real

Acesta este doar un exemplu conceptual, nu reprezentarea internă exactă a Mercury 3.

API-ul Inception poate expune aceste stări intermediare. Cu streamingul normal, Mercury returnează blocuri de text rafinat care pot fi adăugate la răspuns. Cu diffusing=True, fiecare fragment conține în schimb versiunea completă curentă a răspunsului, pe măsură ce modelul o rafinează.

Vom vedea imediat diferența.

Demo: Construirea unui asistent de escaladare pentru suport, în timp real

Înainte de a construi demonstrația, să separăm setările modelului de aplicația de suport propriu-zisă.

Cazul de suport este doar inputul pe care îl folosim pentru a pune la lucru Mercury 3. Controalele importante din partea modelului sunt bugetul de raționare, bugetul de completare și modul de streaming.

Acestea sunt setări de lucru pentru acest experiment, nu setări Mercury 3 optimizate la nivel general.

Pasul 1: Cerințe preliminare

Cu Mercury 3 e nevoie de doar câțiva pași pentru a începe. Ca să urmărești, ai nevoie de:

• O cheie API Inception
• Python 3
• Pachetul inceptionai
• Cazul de suport salvat ca case_support.json

Începe prin a te înscrie pe platforma Inception și a obține cheia API. Dă click pe Get Started și completează detaliile:

Notă: La momentul scrierii, Inception oferă 100 de milioane de tokeni gratuiți pentru conturile noi, pentru testarea API-ului.

Îți poți denumi cheia API sau poți sări peste acest pas și să dai click pe Create Key.

Apoi, copiază cheia API și fă primul tău apel la API. 

Pasul 2: Testează Mercury 3

Înainte de a scrie cod, poți testa Mercury 3 direct din Platforma Inception. După ce creezi cheia API, dă click pe Next și selectează butonul Run it now din fila Try It Out.

Acest lucru e util pentru a testa rapid prompturi și setări ale modelului înainte de a le muta într-o aplicație.

Pasul 3: Pregătește mediul și fă un apel la API

Pentru restul acestui tutorial, vom apela Mercury 3 din Python. Începe prin a instala SDK-ul inception și exportă cheia API astfel:

!pip install -q inceptionaiFuncționează cu

Apoi importă pachetele folosite de demo:

import getpass, json, os, time, difflib
from pathlib import Path
from inceptionai import Inception
from IPython.display import clear_outputFuncționează cu

getpass cere cheia API fără a o afișa, os o plasează acolo unde SDK-ul o caută, Path și json încarcă case_support.json și îl serializează în prompt, iar time.perf_counter() înregistrează când ajunge fiecare răspuns și stare de rafinare.

difflib compară stările de difuzie consecutive, iar clear_output() înlocuiește outputul celulei, astfel încât reluarea să se întâmple în același loc, nu în cascadă pe pagină.

Dacă cheia API nu este deja setată, o poți solicita interactiv:

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")Funcționează cu

Inception() citește cheia API din mediul de lucru. În timp ce celelalte importuri, precum time, înregistrează când sosesc stările de rafinare, difflib ajută la compararea textelor intermediare, iar clear_output() ne permite să rederulăm procesul de difuzie în același loc.

Pasul 4: Construiește mesajele Modelului

Cazul de suport este stocat separat în case_support.json. Fișierul caz conține mesajul clientului, informații despre comandă, înregistrări de plată, loguri de îndeplinire, politica de suport și prompturile pe care vrem să le folosim pentru acest scenariu.

Îți poți construi propriul caz sau îl poți folosi ca atare:

{
  "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"
  ]
}Funcționează cu

Acum, hai să încărcăm fișierul JSON:

def load_incident(path: str) -> dict:
    return json.loads(Path(path).read_text())
case = load_incident("case_support.json")Funcționează cu

Înainte de a-l trimite către Mercury 3, separăm configurația promptului de evidențe:

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}"
            ),
        },
    ]Funcționează cu

Cheile system_prompt, task_prompt și packet_label controlează modul în care instruim Mercury, așa că sunt eliminate din evidențe înainte ca dosarul cazului să fie serializat. Putem acum pregăti mesajele finale:

messages = build_messages(case)Funcționează cu

Aici nu este implicat niciun sistem de regăsire sau tool extern. Tot ce are nevoie Mercury pentru această analiză este furnizat direct în cerere.

Pasul 5: Fă o cerere către Mercury 3 

Înainte de a testa streamingul, să facem o cerere normală, fără streaming. Helperul următor învelește apelul către API-ul Mercury și înregistrează metadatele răspunsului:

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)Funcționează cu

Acum să definim un apel de model:

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,
    }Funcționează cu

Principalele controale din partea modelului sunt:

reasoning_effort=effort
temperature=0.75
max_completion_tokens=max_tokensFuncționează cu

Putem acum face un apel de bază:

result = run_nonstream(
    client,
    messages,
    effort="low",
    max_tokens=8192,
)
print(result["text"])Funcționează cu

Mercury primește întregul caz de suport și returnează analiza cerută, inclusiv cea mai probabilă explicație, dovezile care o susțin, explicații alternative, incertitudini și următoarele acțiuni recomandate.

Funcția înregistrează, de asemenea, câmpurile elapsed_s și usage. Primul măsoară timpul end-to-end al cererii, în timp ce celălalt include contabilitatea tokenilor, inclusiv folosirea raportată a tokenilor de raționare.

Pe parcursul rulărilor folosite în acest tutorial, Mercury a identificat în mod constant a doua înregistrare de plată ca fiind cel mai probabil o autorizare în așteptare, mai degrabă decât dovada unei a doua comenzi confirmate. Totuși, în mod deliberat cazul nu are suficiente informații pentru a ști dacă acea autorizare în așteptare va dispărea sau se va deconta în final.

Pasul 6: Adaugă streaming standard

O cerere normală așteaptă ca Mercury să termine înainte de a returna răspunsul complet. Pentru a primi răspunsul incremental, trebuie să activăm stream=True. Funcția de streaming standard arată astfel:

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),
    }Funcționează cu

Comportamentul important aici este chunks.append(content) în streamingul standard, unde fiecare fragment conține următoarea bucată din răspuns, astfel încât fragmentele pot fi acumulate și reconstruite în răspunsul final cu "".join(chunks).

Notă: Timpul median până la primul output vizibil a fost 2,903 secunde, în timp ce latența totală mediană a fost 3,375 secunde.

Pasul 7: Comută la streaming prin difuzie

Pentru a activa streamingul prin difuzie, setează următorii parametri la True:

stream=True
diffusing=TrueFuncționează cu

Apelul API diferă de streamingul standard printr-un singur argument în plus, adică 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,
    }Funcționează cu

Cu streamingul standard, fragmentele sunt adăugate. Însă cu streamingul prin difuzie, cel mai recent fragment nenul reprezintă versiunea completă curentă a răspunsului. Așadar, în loc să-l adăugăm, înlocuim ceea ce a fost afișat anterior.

Păstrăm și stările returnate pentru a măsura numărul de stări de rafinare și pentru a verifica dacă stările ulterioare chiar revizuiesc textul apărut anterior.

Pe cinci rulări, streamingul prin difuzie a returnat o mediană de 9 stări de rafinare vizibile, cu un interval 7–12. Timpul median până la prima stare vizibilă a fost 1,896 secunde, iar latența totală mediană a fost 2,560 secunde.

Pasul 8: Compară streamingul standard cu cel prin difuzie

Acum că înțelegem ambele căi de cod, putem compara comportamentul măsurat.

Pentru acest prompt de suport, difuzia a avut o latență mediană mai mică, dar intervalele se suprapun substanțial. Așadar, nu ar trebui să concluzionăm că streamingul prin difuzie este inerent mai rapid.

Figura: Rulare cu 12 stări, tranziție cu tranziție. Bara maro este text pe care Mercury 3 îl scrisese deja și apoi l-a înlocuit, în timp ce bara albastră este textul nou după capătul anterior. Un append pur nu ar arăta deloc maro.

În rulările mele, stările de difuzie returnate au revizuit textul vizibil anterior, mai degrabă decât să se comporte ca fragmente doar de adăugat. În runda de mai sus, niciuna dintre cele 11 tranziții de stare nu a fost un append pur, iar fiecare a deviat de la starea anterioară în primele 14 caractere.

Pasul 9: Testează bugetul de completare

În continuare, să analizăm comportamentul Mercury 3 privind interacțiunea tokenilor de raționare cu bugetul de completare. Apelurile normale de mai sus folosesc max_completion_tokens=8192, dar pentru a evidenția mai clar comportamentul, trebuie să reducem max_completion_tokens la 1600.

Acum, rulează aceeași cerere o dată cu efort de raționare scăzut și o dată cu ridicat. Iată rezultatul măsurat:

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:    noneFuncționează cu

La ridicat, toți cei 1.539 tokeni de completare au fost raportați ca tokeni de raționare. Prin urmare, modelul a atins limita de completare înainte de a returna text de răspuns vizibil.

Figura: Buget de completare la efort ridicat, cu plafon de 1.600 și 8.192 tokeni 

La plafonul de 1.600, întregul buget a mers pe raționare și nu a mai rămas nimic pentru emitere. La 8.192, rularea mediană cu efort ridicat a cheltuit 2.292 tokeni pentru raționare și tot a mai avut loc pentru un răspuns de 412 tokeni. Plafonul de 8.192 se află în afara marginii din dreapta a acestei scale, motiv pentru care doar primul rând din imaginea de mai sus arată o linie punctată a plafonului.

Semnalul important în cererea eșuată la ridicat este response.choices[0].finish_reason, care a returnat length. Asta înseamnă că cererea a atins bugetul maxim de tokeni de completare (max_completion_tokens). Acest buget include atât tokenii de raționare, cât și tokenii de output vizibil. În această rulare, Mercury 3 a raportat toți cei 1.539 tokeni de completare ca tokeni de raționare, așa că cererea a atins limita de completare înainte de a produce un răspuns vizibil.

Notă: Pentru acest demo, max_completion_tokens=8192 a fost suficient pentru rulările rămase, dar nu ar trebui tratat ca un minim universal.

Pasul 10: Compară efortul de raționare scăzut și ridicat

Revenim acum la bugetul normal de completare 8192 și variem doar reasoning_effort între scăzut și ridicat. Vom folosi helperul run_nonstream() din Pasul 5 pentru a face o cerere cu efort scăzut și alta cu efort ridicat:

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"],
    )Funcționează cu

Pentru rezultatele raportate, am repetat fiecare configurație de cinci ori, nu m-am bazat pe o singură cerere.

Medianele au fost:

Folosirea mediană a raționării a crescut de la 828 la 2.292 tokeni, în timp ce latența mediană a crescut de la 2,936 la 8,146 secunde (aprox. 2,77x).

Figura: Unde merge bugetul de completare la fiecare nivel de efort?

Lungimea răspunsului vizibil nu s-a schimbat nici pe departe la fel de mult:

• Scăzut: mediană 468 tokeni
• Ridicat: mediană 412 tokeni

iar intervalele observate s-au suprapus:

• Scăzut: 393–494
• Ridicat: 356–469

Așadar, aceste rulări nu susțin afirmația că mărirea efortului de raționare face răspunsul vizibil mai scurt. Intervalele de latență arată, de asemenea, de ce o singură rulare nu e suficientă:

• Scăzut: 1,602–4,993 s
• Ridicat: 4,102–9,068 s

Notă: Cea mai rapidă cerere la ridicat a fost de fapt mai rapidă decât cea mai lentă la scăzut.

Figura: Toate cele zece cereri cu efort de raționare, reprezentate după latență

Așadar, reasoning_effort="high" a crescut substanțial folosirea raportată a tokenilor de raționare și latența în acest experiment, în timp ce lungimea răspunsului vizibil a rămas în linii mari similară.

Gânduri finale

Există trei comportamente practice ale Mercury 3:

• Streamingul prin difuzie folosește un contract de output diferit. Streamingul standard adaugă text nou, în timp ce streamingul prin difuzie returnează stări succesive ale răspunsului complet, care ar trebui să înlocuiască starea anterioară.

• Tokenii de raționare împart bugetul de completare. O valoare mică pentru max_completion_tokens poate fi epuizată de raționare înainte ca Mercury 3 să producă un răspuns vizibil.

• Un efort de raționare mai mare schimbă latența contra calcule suplimentare. În rulările mele, modul ridicat a folosit mult mai mulți tokeni de raționare raportați și a durat mai mult, așa cum era de așteptat, în timp ce lungimea răspunsului vizibil a rămas în linii mari similară.

Aceste rezultate provin dintr-un număr mic de rulări pe un caz sintetic de suport, deci ar trebui tratate ca observații ale acestui demo, nu ca afirmații generale despre performanța Mercury 3.