LangSmith: egy observability termékből lett agentplatform

A LangSmith LLM-alkalmazásokhoz való hosztolt tracing- és értékelési platform: minden hívás, amelyet az ügynök tesz, egy runokból álló fává válik, bemenetekkel, kimenetekkel, késlenséggel és token számokkal, amelyet kereshet, értékelhet és összehasonlíthat. A pozíció a dokumentáció elolvasása után: ez a legteljesebb eszköz a fajtájában, és egyben a legdrágább, ha érteni kell hozzá, mert már nem csak observability termék.

Az observability költségvetésért a Langfuse, az Arize Phoenix és a Helicone versenytársa, és egyre inkább a saját runtime-jével is, mert ugyanaz a gyártó ugyanazon az árazási oldalon adja el a Deploymentet, a Studiót, az Engine-t, a Fleetet, a Sandboxokat és az LLM Gatewayt. Ez a terjedés a legfontosabb mérlegelendő szempont, mert minden további szolgáltatás külön van mérve.

Mi ez

A platformnak négy része van, amelyek egy számlát osztoznak: tracing, értékelés, promptkezelés és egy agent runtime. Az erőforrásmodell fontosabb a funkcióknál. Egy szervezet workspace-eket tart, a workspace-ek tracing projekteket, adathalmazokat, annotációs sorokat és promptokat, minden trace pedig pontosan egy projektben van. Az alapvető tények:

• Egy trace egy végrehajtás, amely egymásba ágyazott runokból áll; a run először létrejön, majd a munka előrehaladtával frissül, ezért az eseménylimit és a tracelimit különböző szám.
• A tracing a langsmith SDK dekorátorjaival, egy REST ingest API-val vagy bármely instrumentált alkalmazás OpenTelemetry spanjeivel működik.
• Az offline értékelések referencia kimenetekkel rendelkező példákból álló adathalmazokon futnak, az online értékelések referencia nélkül élő trace-eket értékelnek.
• Az értékelők lehetnek kód, LLM-as-judge, egy típusos döntési modell, páros összehasonlítás vagy ember, és egy értékelő több projekthez is csatolható.
• Annotációs sorok, adathalmaz-verziók és splitek, egy commit tagekkel működő prompt regisztráció és egy playground mind része.
• Önálló telepítés létezik, de csak licenckulcs mögé tett Enterprise kiegészítésként.

Hogyan működik

Az instrumentálás a saját folyamatodban fut, és HTTPS-en küld runokat a LangSmithnek. Az SDK háttérszálról dolgozik, és egy sessionhöz tartozó akár 100 runt egyetlen API-hívásba gyűjt, így a tracing nem kerül a kérés útjába. Egy kiszolgálóoldali queue ezután átveszi az ingestet, az újrapróbálkozásokat és az integritás-ellenőrzéseket, mielőtt a trace-tárba ír.

Ez a queue magyarázza, miért az ingest korlátok fix ablakként és nem sima átlagként vannak megfogalmazva, és miért a 429 egy visszakerítéssel kezelendő normális esemény, nem kiesés. A terheléselosztó minden csomagon fix percenkénti limiteket kényszerít ki: 5000 POST vagy PATCH kérés a runs végpontokra, 5000 a feedbacks végpontra, 2000 minden más végpontra és 30 törlés. Az SDK kötegel, és éppen ez tartja egy terhelt alkalmazást ezek alatt.

Első lépések

Két környezeti változó kapcsolja be a tracinget kódmódosítás nélkül, ami helyi fejlesztésnél számít: a LANGSMITH_TRACING szabályozza a dekorátort és a context managert, a LANGSMITH_PROJECT pedig a cél projektet nevezi meg, alapértelmezésen default értékkel. A minimális Python beállítás egy pipeline-t követ beágyazott runokként:

import asyncio

from langsmith import Client, traceable
from openai import AsyncOpenAI

client = Client()
llm = AsyncOpenAI()


@traceable(run_type="retriever", name="retrieve_docs")
async def retrieve_docs(question: str) -> list[str]:
    return ["Annual report: revenue up 12 percent."]


@traceable(run_type="llm", name="answer")
async def answer(question: str, context: list[str]) -> str:
    reply = await llm.chat.completions.create(
        model="gpt-5.4-mini",
        messages=[{"role": "user", "content": f"{question}\n{chr(10).join(context)}"}],
    )
    return reply.choices[0].message.content


@traceable(name="support_agent")
async def support_agent(question: str) -> str:
    return await answer(question, await retrieve_docs(question))


async def main() -> None:
    try:
        print(await support_agent("How did revenue move?"))
    finally:
        await client.flush()  # background thread must finish before exit


asyncio.run(main())

A dekorátor továbbítja a kontextust, így a három függvény kézi szülőhuzalozás nélkül faként jelenik meg, és a run_type dönti el, hogyan rajzolja ki a felület a csomópontot: az llm ad token számokat és késlenséget, a retriever és a tool jelöli a többi lépést. Ugyanez a kliens futtat offline értékeléseket egy adathalmazon, és itt kezd el a hozamásodni az érték.

Ugyanez az API hajtja az értékelési ciklust. Az evaluate egy célfüggvényt, egy adathalmazt és egy értékelőlistát vesz, kísérletet hoz létre példánként egy runnal, és CI-ból vezérelhető: Értékeld minden becommitolt prompt módosítást a megcímkézett adathalmaz-verzión, és buktasd a buildet, ha a groundedness pontszám egynél többet esik. A LangSmith automatikusan verziózza az adathalmazokat, amikor a példák változnak, így egy tag egy CI futást egy adott adatállapothoz rögzít. A dokumentáció egyértelmű: írj öt-tíz válogatott példát a jó kimenetre, mielőtt bármilyen értékelőt megírsz.

Mennyibe kerül

A seat a látható ár, a trace a mért mennyiség. A Developer csomag egyetlen seatre ingyenes, havi 5000 base trace-et tartalmaz; a Plus havi 39 dollár egy seat és 10.000 base trace, korlátlan további seattal; az Enterprise egyedi árú, és hozzáadja az önálló és hibrid telepítést, az egyéni SSO-t, valamint az attribútum- és szerepközpontú hozzáférésszabályozást.

Egy esemény egy run létrehozása vagy frissítése, ezért az ugyanabban a clock órában létrehozott és majd patchelt run kétszer számít az órás limit felé, és a 2 MB-os run későbbi 3 MB-ra frissítése 5 MB-ot számít az ingest volumeni limitjébe. Ezt kell modellelni a kapacitástervezésben: a trace alakja, nem a kérések száma hajtja a korlátot.

A platform többi része LangChain Standard Unitokban számlázódik, egy LSU 1,00 dollár. Az Engine hat óránként fut, egy futás becsültLSU-mennyisége 7 és 45 között van a trace volumen és az észrevett hibák számától függően. A Fleet 7 LSUt tartalmaz a Developer és 37 LSUt a Plus csomagban, a Sandboxok 8 LSUt, egy perceived error értékelő futás 0,015 LSUt. Egy 39 dolláros seat tehát kevésbé mondja meg a számlát, amint a runtime használatban van.

Natív tracing vagy OpenTelemetry

A LangSmith két úton fogad OpenTelemetry spaneket. Az SDK integrációval a LANGSMITH_OTEL_ENABLED=true beállítással a LangChain és a LangGraph a LangSmith exporteren át küld spaneket, a LANGSMITH_OTEL_ONLY=true pedig megakadályozza, hogy a saját formátumban is küldjön. Bármely más alkalmazásnál egy szabványos OTLP exportálót kell a https://api.smith.langchain.com/otel alap végpontra állítani; regionális végpontok vannak EU, APAC és AWS US területekre. Az exporter maga fűzi hozzá a jel útvonalát, ezért a /v1/traces a basis URL-ben 404-et ad.

pip install "langsmith[otel]"          # needs langsmith >= 0.3.18, 0.4.25 recommended

export LANGSMITH_TRACING=true
export LANGSMITH_OTEL_ENABLED=true
export LANGSMITH_ENDPOINT=https://api.smith.langchain.com
export LANGSMITH_API_KEY=...

# fan out one OTLP stream to LangSmith and to the rest of the stack
export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.smith.langchain.com/otel
export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=...,Langsmith-Project=support"

# OTel-only, for teams that do not want a second transport
export LANGSMITH_OTEL_ONLY=true

A csere a kényelem és az overhead között van. Az OTel út attribútum-leképezési gyakorlatot kér, mert a span attribútumokat a langsmith névtérrel kell felcímkézni, hogy run típusok, run ID-k és dotted order legyenek belőlük; a LangChain saját bejelentése az OpenTelemetry utat valamivel magasabb overheadként írja le, és a natív formátumot ajánlja, ha a LangSmith az egyetlen cél. A natív forma pending runokat is ad, amelyek már a munka közben megjelennek a felületen.

Ahol nyiklik

Először a gyengeségek, mert ezek döntik el, kell-e ez a termék. A számlázási egység a trace, ami csendben jutalmazza a mintavételt és bünteti azt az alkalmazást, amely minden kérést trace-el; a terheléselosztó korlátai service key vagy personal access tokenenként érvényesek, nem szervezetenként, így egy vízszintesen skálázott flottához több kulcs kell, vagy az SDK kötegelése. A workspace szintű szerepközpontú hozzáférés csak Enterprise csomagban van, egy növekvő csapat Pluszon egy szerepkörlét oszt. És az erőforráshierarchia alattuk épül át: a workspace-ek korábban tenantok voltak, az agentek beta csoportosításként jelentek meg a projektek fölött, és egy agent alapú workspace agent és környezet szerint címezi a trace-eket, nem projekt szerint.

Amit a LangSmith nem ad fel, az a mérhetőség: a run fák, a beszélgetésszintű nézetek és az adathalmazokra épülő regressziós tesztelés referenciaimplementációja, és a foglalásokkal működő annotációs sor komoly válasz arra a kérdésre, ki jelöl mit. Ha az alkalmazásod már LangGraphon fut, a választás magától értetődik, és a váltási költség a runtime-ban van, nem a trace-ekben.

Ítélet

A LangSmith megéri az árát, ha az ügynök viselkedése, nem az elérhetősége az, ami elromlik, és ha embereknek kell runokat jelölniük, amelyek kiadási kaput hajtanak. Kevésbé éri meg az ára, ha csak egy kérésnaplót szeretnél, ha egy felhasználói kérésenkénti trace már több, mint amennyi a büdzsébe fér, vagy ha a platform szélesülése nem derül ki, miért fizetsz.

1. Vedd fel, ha CI-ban futó, adathalmazokra épülő regressziós teszteket akarsz, nem csak egy trace böngészőt.
2. Vedd fel, ha több embernek kell runokat jelölnie, mert a foglalással működő annotációs sorokat és a dataset exportot nehéz újraépíteni.
3. Vedd fel, ha eleve LangGraphon fejlesztesz, és számítsd be a runtimeot a döntésbe, ne tettesd, mintha a trace-ek külön dolgok lennének.
4. Óvatosan, ha minden kérést trace-elsz: modelleld az óránkénti esemény- és bájtkorlátokat, mielőtt élesben bekapcsolod az instrumentálást.
5. Nézz máshová, ha önálló telepítést akarsz értékesítési beszélgetés nélkül, workspace szintű hozzáférésszabályozást, vagy ha jobban passzol egy lapos, trace-enkénti ár, mint egy LSU-alapú platform.

Források

1. LangSmith árazás
2. LangSmith dokumentáció: administration overview
3. LangSmith dokumentáció: custom instrumentation
4. LangSmith dokumentáció: trace with OpenTelemetry
5. LangSmith dokumentáció: evaluation concepts
6. LangSmith dokumentáció: self-hosted deployment
7. LangChain: end-to-end OpenTelemetry a LangSmithben