メインコンテンツへスキップ

LLMOps

LLM-as-a-Judgeだけでは足りない? Langfuse Code Evaluatorsで評価を設計し直す

本記事でわかること # LLM-as-a-Judgeの「苦手な評価」とは何か Langfuseのコード評価(Code Evaluators)機能の概要と使い方 コード評価をLLM評価と組み合わせた実践的な運用パターン INACTIVEなエバリュータへの手動バッチ実行を活用した安全な本番導入フロー 対象読者 # LangfuseでLLM-as-a-Judgeを使っているエンジニア 評価コストや判定のブレに課題を感じている方 Langfuseの評価機能を本番導入する前に安全に試したい方 LLM-as-a-Judgeだけでは足りないケース # LLMアプリを本番運用していると、こんな疑問が浮かぶことがあります。「この評価、本当にLLMが必要?」

Hermes Agent × Langfuse で LLMOps の観測性を高める:ネイティブプラグインの導入と運用上の注意点

ガオ株式会社では、社内およびグループ企業間の業務で自律型エージェント Hermes Agent (NousResearch/hermes-agent) の活用を進めています。 エージェントが Tool を呼び出しながら自律的に業務を進めるようになると、LLM API call 単位のログだけでは挙動を追いきれません。さらに自律型エージェントの場合、人手が介在せず判断と実行が連続して走るため、観測性 — 後から誰が何を要求し、エージェントが何を判断し、どの Tool をどう実行したかを追える状態 — が、従来以上にガバナンスや内部統制の観点で重要になります。

LangfuseでLLM-as-a-Judgeの評価をカテゴリ化する ― 数値しきい値に頼らない評価設計

本記事でわかること # LLM-as-a-Judgeで数値スコアを使うことの問題点 Langfuseのカテゴリ型・Boolean型スコアを使って、直感的な Evaluator を設計する方法 JSON Schemaによる型安全な評価出力の仕組み RAG精度・コンテンツ安全性・サポートチケット分類など実務ユースケースへの適用例 対象読者 # Langfuseで LLM-as-a-Judge(自動評価)を運用している方 評価スコアのしきい値設定に迷いを感じている方 評価結果をダッシュボードで分析しやすくしたい方 「0.7以上なら合格」という設計の脆さ # 本番LLMアプリの評価パイプラインを運用していると、自動評価(LLM-as-a-Judge)はもはや欠かせない仕組みです。人間がすべてのトレースをレビューするのは非現実的なため、LLMに評価させるアプローチが普及してきました。

LLMOps:評価基盤の運用編 — Langfuse 活用

こんにちは。ガオ株式会社の黒澤です。本記事は「LLMOps:評価基盤の設計編 — Langfuse 活用 」の続編です。 設計編では評価軸の定義から Judge プロンプト設計・ゴールデンデータセット構築・メタ評価(Cohen’s Kappa・Confusion Matrix)まで解説しました。本記事ではその後の「誰が・いつ・どうやって評価を運用するか」を整理します。

ガバナンスを高めるKong AI Gateway + Langfuseで"アプリ計装なし"のLLMオブザーバビリティ

LMアプリケーションの可観測性(オブザーバビリティ)を確保しようとする際、Langfuse SDK や OpenTelemetry SDK をアプリケーション側に組み込んで計装するのが一般的なアプローチですが、これは多少なりとも手間がかかることと、社内のエージェントを勝手に動かす人などが意図的に観測されないように対応しないこともありえるでしょう。