
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Fri, 14 Aug 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/llm-tracing/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-sdk-instrumentation.en</guid>
    <title>Langfuse SDK Instrumentation — What Is Captured Automatically and What You Add by Hand</title>
    <link>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-sdk-instrumentation.en</link>
    <description>Creating traces is not about installing an SDK, it is about drawing boundaries. Working from the Langfuse Python SDK v4, this post lays out what the decorator, the context manager, and manual observation creation each do differently, why propagate_attributes exists for pushing attributes down the tree, and exactly how far framework integrations for OpenAI and LangChain reach on their own. It covers what changed when v4 moved ingestion onto OpenTelemetry, the OTLP endpoint and headers, the rules that map gen_ai attributes to observation types, and why data disappears in short-lived processes. Second post in the Langfuse and ClickHouse LLM tracing series.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>observability</category><category>langfuse</category><category>llm-tracing</category><category>instrumentation</category><category>opentelemetry</category><category>python</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-sdk-instrumentation.ja</guid>
    <title>Langfuse SDK計測 — 何が自動で取れて何を手で入れるか</title>
    <link>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-sdk-instrumentation.ja</link>
    <description>トレースを作る作業はSDKを入れることではなく、境界を引くことです。本記事はLangfuse Python SDK v4を基準に、デコレータ、コンテキストマネージャ、手動生成という三つの計測方式が何を違えているのかを整理し、属性を下へ流すpropagate_attributesがなぜ必要か、OpenAIやLangChainのようなフレームワーク統合が自動で取ってくれる範囲はどこまでかを押さえます。v4で取り込み経路がOpenTelemetryに変わったことで何が変わったか、OTLPエンドポイントとヘッダ、gen_ai属性がobservation型へ対応づけられる規則、そして短命なプロセスでデータが消える理由まで扱います。Langfuse + ClickHouse LLMトレーシングシリーズの第二回です。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>observability</category><category>langfuse</category><category>llm-tracing</category><category>instrumentation</category><category>opentelemetry</category><category>python</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-sdk-instrumentation</guid>
    <title>Langfuse SDK 계측 — 무엇이 자동으로 잡히고 무엇을 손으로 넣나</title>
    <link>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-sdk-instrumentation</link>
    <description>트레이스를 만드는 일은 SDK를 설치하는 일이 아니라 경계를 긋는 일입니다. 이 글은 Langfuse 파이썬 SDK v4를 기준으로 데코레이터, 컨텍스트 매니저, 수동 생성 세 가지 계측 방식이 각각 무엇을 다르게 하는지 정리하고, 속성을 하위로 흘려보내는 propagate_attributes가 왜 필요한지, OpenAI와 LangChain 같은 프레임워크 통합이 자동으로 잡아 주는 범위가 어디까지인지를 짚습니다. v4에서 수집 경로가 OpenTelemetry로 바뀌면서 달라진 부분, OTLP 엔드포인트와 헤더, gen_ai 속성이 observation 타입으로 매핑되는 규칙, 그리고 짧게 사는 프로세스에서 데이터가 사라지는 이유까지 다룹니다. Langfuse + ClickHouse LLM 트레이싱 시리즈의 두 번째 글입니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>observability</category><category>langfuse</category><category>llm-tracing</category><category>instrumentation</category><category>opentelemetry</category><category>python</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-tracing-data-model.en</guid>
    <title>The Langfuse Tracing Data Model — How Trace, Observation, and Score Hold One Execution</title>
    <link>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-tracing-data-model.en</link>
    <description>Looking at the Langfuse UI first tells you nothing about what you are looking at. This post starts from the shape of the data Langfuse collects. What a trace groups, what separates a span from a generation from an event, how sessions and users layer on top of traces, and where scores attach — all checked against the official documentation. It draws the actual tree that one RAG call and one agent run leave behind, and explains why imagining observability data as relational leads your queries astray, and what it means that trace attributes are copied onto every observation row. First post in the Langfuse and ClickHouse LLM tracing series.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>observability</category><category>langfuse</category><category>llm-tracing</category><category>data-modeling</category><category>opentelemetry</category><category>llmops</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-tracing-data-model.ja</guid>
    <title>Langfuseトレーシングのデータモデル — trace、observation、scoreが一度の実行を収める形</title>
    <link>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-tracing-data-model.ja</link>
    <description>Langfuseの画面を先に見ても、何を見ているのかは分かりません。本記事はLangfuseが収集するデータの形から整理します。traceが何をまとめ、observationがspan・generation・eventに分かれる基準は何か、sessionとuserがtraceの上にどんな層として乗るのか、scoreがどこに付くのかを公式ドキュメントで確認します。RAGの一回の呼び出しとエージェントの一回の実行がそれぞれどんなツリーとして残るかを実際の構造で描き、観測データを関係モデルとして想像すると後で問い合わせがずれる理由、trace属性がobservationごとに複製される保存形式が何を意味するかまで押さえます。Langfuse + ClickHouse LLMトレーシングシリーズの第一回です。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>observability</category><category>langfuse</category><category>llm-tracing</category><category>data-modeling</category><category>opentelemetry</category><category>llmops</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-tracing-data-model</guid>
    <title>Langfuse 트레이싱 데이터 모델 — trace, observation, score가 한 번의 실행을 담는 방식</title>
    <link>https://www.youngju.dev/blog/observability/2026-08-14-langfuse-tracing-data-model</link>
    <description>Langfuse 화면을 먼저 보면 무엇을 보고 있는지 알 수 없습니다. 이 글은 Langfuse가 수집하는 데이터의 형태부터 정리합니다. trace가 무엇을 묶고 observation이 span·generation·event로 갈리는 기준은 무엇인지, session과 user가 trace 위에 어떤 층으로 얹히는지, score가 어디에 붙는지를 공식 문서 기준으로 확인합니다. RAG 한 번의 호출과 에이전트 한 번의 실행이 각각 어떤 트리로 남는지를 실제 구조로 그려 보고, 관측 데이터를 관계형처럼 상상하면 왜 나중에 질의가 어긋나는지, trace 속성이 observation마다 복사되는 저장 형태가 무엇을 뜻하는지까지 짚습니다. Langfuse + ClickHouse LLM 트레이싱 시리즈의 첫 번째 글입니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>observability</category><category>langfuse</category><category>llm-tracing</category><category>data-modeling</category><category>opentelemetry</category><category>llmops</category>
  </item>

    </channel>
  </rss>
