簡単にいうと、LLMの仕組みを理解してLLMの気持ちになってどういうコンテキストを与えたらうまくいくのか？どうやれば安定したLLMプロダクトを開発できるのか？というLLMプロダクト開発の基本が書かれた本です。 内容はいささか古く（おそらく2024年中頃までに書かれている）、この本から即座に実践に入れる類いの本ではないので、まさに「教科書」です。この本を索引として、必要な知識を深掘りする必要性があります。 この本に書かれている知識のまま、知識更新を怠ると極めて危険です。いろいろな情報がアップデートされています。 この記事に間違いとか解釈違いとかあったら、是非ご連絡ください！ コーディングエージェント使いが読むべきか？ 非エンジニアが読むべきか？ 内容の解説 という構成です。 コーディングーエージェント使いが読むべきか？最近コーディングエージェントを使う人が一気に増えました。そういったコーディ

こちらのイベントで登壇した資料になります。 https://findy.connpass.com/event/348365/ Algomatic では全方位全職種積極採用中です： https://jobs.algomatic.jp/

本日、Forkwell さんに悪ふざけに付き合ってもらってイベントやりました。ありがとうございます。「転職したらMCPサーバーだった件」 🎵🧭 というタイトルで登壇しました！ 🔍 イベント詳細: - イベント名: 転職したらMCPサーバーだった件 - 公式URL: https://forkwe…

Thoughtworks Technology Radar is a twice-yearly snapshot of tools, techniques, platforms, languages and frameworks. This knowledge-sharing tool is based on our global teams’ experience and highlights things you may want to explore on your projects.

MCP logo ©︎ 2024–2025 Anthropic, PBC and contributors | MIT license はじめに 本記事は、セキュリティエンジニアのAzaraこと齋藤とコーポレートセキュリティエンジニアのhamayanhamayanが、社内で行ったディスカッションを元に記述した記事です。 本記事は、MCP の利活用の際に考えるべき、セキュリティに関する考慮事項や、脅威の想定、実装時気にすべき観点などについてまとめたシリーズの前編になります。前編では、MCPに関する基本的な事項を扱いながら、利用者側の目線でMCPに対するセキュリティを考えていきます。社内での利活用の際に参考になれば幸いです。 また、GMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したアプリケーションに対する脆弱性診断・ペネトレーショ

ChatGPTと楽しく図解の作成をしていたら、突然現れたこんな図。 いやいやこんなの望んでないし。なにこれ！？ この現象、ズバリ日本語の文字化けです。 ここで、「何だよ、全然使えないじゃん」と諦めるのはまだ早い。 だって、速攻で解決できるから。（※2025/5/12執筆時点では、有料プランに加入しAdvanced Data Analysis機能が使えるユーザーのみ） ただ、ChatGPTに日本語フォントが入っていないだけなんです。 ならば渡してあげましょう。

はじめに 普段、Kaggle に取り組む際には様々な方法で train, test パイプラインを組んでいると思いますが、Kaggle Notebook 上で直接編集する方や Kaggle の Docker によって Kaggle Kernel と同様の環境をローカルで作り上げている方もいるのではないか、と思います。 先日、Kaggle から以下のようなメールが届きました。どうやら Colab や VS Code 上で Kaggle の Jupyter Server にアクセスができるとのことです。 Connect Colab and VS Code to Kaggle Jupyter Servers: You can now connect your preferred notebook editor directly to Kaggle's powerful Jupyter Serve

CursorやClineなどで生成AIを使ってコーディングをしていると、Reasoningモデルとか、Thinkingモードとか、そういったワードに出会うことが多い。これらが意味することについて理解できてないと感じていた。 何かを学ぶとき、資料を読むだけではなく手を動かしてみると理解が早くなる。そこでChatGPTのDeep Researchでハンズオン資料を作り、それを元に学ぶと効率が良いのではないかと考えた。今回の記事ではハンズオンの作成と実施の過程をまとめておく。 ハンズオン資料をDeep Researchで作る 次のように質問してDeep Researchでハンズオン資料を作る。 すると https://chatgpt.com/share/6819d686-5ae0-8010-8196-d532528dc82a のような資料が作られた。 序文 実験の章の一部 見出しはこういう感じ。

In this notebook we delve into the evaluation techniques for abstractive summarization tasks using a simple example. We explore traditional evaluation methods like ROUGE and BERTScore, in addition to showcasing a more novel approach using LLMs as evaluators. Evaluating the quality of summaries is a time-consuming process, as it involves different quality metrics such as coherence, conciseness, rea

このノートブックでは、簡単な例を用いて、抽象的な要約タスクの評価技術について探求します。伝統的な評価方法であるROUGEやBERTScoreといったものに加えて、LLM（大規模言語モデル）を評価者として使用するより新しいアプローチを紹介します。 要約の品質を評価することは、時間がかかるプロセスです。これには、一貫性、簡潔さ、可読性、内容などのさまざまな品質指標が関わってきます。ROUGEやBERTScoreなどの従来の自動評価指標は具体的で信頼性がありますが、実際の要約の品質と必ずしも相関しない可能性があります。特に、開かれた生成タスクに対する人間の判断との相関は比較的低いことが示されています。(G-Eval論文) 人間による評価、ユーザーフィードバック、モデルベースの指標に頼る必要が高まっていますが、潜在的なバイアスに注意する必要があります。人間の判断は貴重な洞察を提供しますが、スケール

LLMをプロダクトに活用していく上でプロンプトの出力結果を評価していかなければいけない訳ですが、可能な限り自動で定量評価できると改善もしていきやすくなり大変助かります。 そこで所謂LLM-as-a-Judgeと呼ばれるLLMに評価してもらう手法を取るわけですが、やはり「このスコアはどれくらい信じられるのか...?」という疑問が湧いてきて"評価の評価"がしたくなってきます。 というところで、本記事では使いそうなLLM-as-a-Judgeの手法について調べた後、"評価の評価"の仕方を調べてみた結果をまとめていきます。 LLM-as-a-Judgeの手法 まず初めに、LLM-as-a-Judgeにも様々な手法が存在するので、それらを確認していきます。 スコアベース 一番ベーシックなものはスコアをつけてもらうやり方です。 次のように実際のインプット、それに対するLLMの回答をプロンプトに加えて、

2024/05/08 AWS オンラインセミナー、「AI Agent 開発の 0→1 - AWS の実証事例に学ぶ、企画から組織展開までのメソッド」での発表資料になります。 https://pages.awscloud.com/eib-aiml-250508-reg.html

ジェネラティブエージェンツの大嶋です。 「AIエージェントキャッチアップ #23 - OpenEvals / AgentEvals」という勉強会を開催しました。 generative-agents.connpass.com アーカイブ動画はこちらです。 www.youtube.com OpenEvals / AgentEvals 今回は、LangChainが公開したLLMアプリの評価のライブラリ「OpenEvals」と「AgentEvals」について、READMEを読んだり動かしたりしてみました。 OpenEvalsのGitHubリポジトリはこちらです。 github.com AgentEvalsのGitHubリポジトリはこちらです。 github.com 今回のポイント OpenEvalsの概要 OpenEvalsは、LangChainが公開した評価のためのライブラリです。 OpenEv

マルチエージェントの開発を行う上で、評価はどのように行うのが良いのでしょうか。最終回答の精度のみの評価だと本当に呼ばれるべきエージェントが呼ばれたのか、呼ばなくて良いエージェントを呼んでいないか、非効率な実行経路になっていないかなどを考慮することができません。 langchain-ai/agentevals のエージェントの軌跡（Trajectory）評価を使用すると、ルールベースでエージェントが適切なツールを呼び出しているかどうかを確認したり（オプションで厳密な順序で）、LLM を判定基準として使用して軌跡を評価したりできます。また、langchain に実装されている TrajectoryEvalChain も利用可能です。 4/2 🎉azure-ai-evaluation にエージェント評価用の新しい組み込み評価機能（プレビュー版）が追加されました！ IntentResolutio

Langfuse Night #1 での登壇資料です。 https://connpass.com/event/340099/

「LLMの評価」というフレーズを見て、どんなことを思い浮かべるでしょうか？ おそらく大半はLLMモデル自体の評価のことを思い浮かべると思います。新しいモデルが出てきた時に𝕏で見かける「GPT-4o のMMLUベンチマークは89%!」みたいなアレ。 ですが、プロダクト開発にLLMを使っている人の間では、プロンプト等が十分な品質を出しているかの確認などにも評価という言葉を使っていることは多いのではないかと思います。 うまい具合に後者を区別するためにいい感じの呼び名を付与したい気持ちがあるのですが、英語圏での例を見てみるとシンプルに"Evals"と呼んでることもあれば Evaluating LLM System Evaluating LLM-based Applications などなど表現の仕方は様々になっています。 そしてそのプロダクト開発文脈での評価も、実態としてはオフライン評価やオンラ