#ai_agents

この記事は、「durable execution（壊れにくい実行）」には、必ずしも巨大な基盤は要らないと主張しています。 DBOS が「Postgres があれば十分」と言った流れに対して、Obelisk は「もっと進めて、SQLite でも多くのケースで十分では？」と提案しています。 重要なのは 計算処理そのもの ではなく、workflow の状態を安全に残すこと だ、という考え方です。 SQLite は単体で transactional な永続性を持てるので、余計な DB サービスを増やさずに済みます。 Litestream を使えば、SQLite の変更を S3 互換の object storage に非同期でバックアップできます。 ただしこれは高可用性の共有DBの代わりではなく、多少の遅延や一部データ喪失の可能性を許容する設計です。 AI agents や実験的な workflow には、Postgres より SQLite のほうがシンプルで相性がいい場面が多い、というのがこの記事の見立てです。 「durable workflows を作るのに、最初から大げさ

Kubernetesの実際のバグ修正事例を使って、AI coding agentsの実力を比べた 使ったのは3種類の見え方 - RAG-only: 検索結果だけを見る - Hybrid: まず検索して、そのあとローカルのコードも見る - Local clone: リポジトリを丸ごとローカルで見る 結果は、検索の工夫は「見つける力」には効くが、「どう直すべきか」の理解まではあまり助けないというもの AIは「主なバグ」だけ直して満足しがちで、周辺の変更や副作用を見落としやすい 逆に、issue（不具合報告）が丁寧に書かれていると、AIの方式差はかなり縮まった つまり、AIを賢くする鍵はRAGだけではなく、人間側の問題の書き方にもありそうだ、という話 InfoQが紹介しているのは、CNCFブログに掲載された Brandon Foley のベンチマーク研究です。 テーマはシンプルで、「AI coding agents は、現実の Kubernetes バグをどれだけ直せるのか？」というもの。 ここでいう AI coding agent は、ただコード補完するだけのツールではなく

AI agents は、普通の ChatGPT 的な使い方より はるかに多くの tokens を消費しがち その理由は、agent が 考える・試す・失敗する・やり直す を何度も繰り返すから 使った分だけ課金される仕組みでは、成功しても失敗しても請求が増える 実際に、チーム規模が小さい会社でも 予想外の高額請求 が起きている しかも厄介なのは、事前に正確な請求額を予測しにくいこと この記事が扱っているテーマは、いまのAI業界でかなり重要です。 それは 「AI agents は便利だけど、気づかないうちにすごい勢いでお金を使う」 という問題です。 ここでいう AI agent とは、単に質問に答えるAIではなく、 「目的を与えると、自分で手順を考えながら作業を進めるAI」のことです。 たとえば、コードのバグ修正、調査、要約、ファイル操作、タスク分解などを自動でやるタイプですね。 普通のChatGPTの使い方なら、1回の質問で1回の回答が返ってきます。 でもagentは違います。 途中で「どう進めるか」を考え、必要なら何度もツールを呼

AIエージェントの失敗原因は、モデルそのものより評価の弱さにあることが多い 本番で使うなら、Retrieval / Generation / Agent / Production の4カテゴリで見るのが重要 単純なAccuracyだけでは足りず、hallucination rate や faithfulness を測らないと危ない 手動チェックは少量なら有効だが、大量運用ではすぐ限界が来る この記事のフレームワークは、「出してから直す」ではなく「出す前に壊れ方を見つける」発想が強い Towards Data Scienceの記事は、本番運用するAIエージェントには専用の評価基盤（evaluation harness）が必要だ、というかなり実務寄りの話です。 ここでいうAIエージェントは、ただ文章を返すチャットボットではありません。 RAG（検索してから回答する仕組み）を使ったり、外部ツールを呼んだり、複数ステップでタスクを進めたりする、いわば“仕事をするAI”です。 この手のシステム、デモではそれっぽく動くのに、本番に入れ