ポッドキャスト: アディ・ポラックによるコンテキスト・エンジニアリング
InfoQのポッドキャストで、Adi Polakは、LLMとの対話やエージェントシステム設計におけるプロンプトエンジニアリングの限界を超える「コンテキストエンジニアリング」の必要性について議論し、ステートフルなAIシステム構築の重要性を指摘した。
キーポイント
コンテキストエンジニアリングの必要性
LLMとの対話やエージェントシステム設計において、従来のプロンプトエンジニアリング（ステートレス）の限界を超え、コンテキストを管理・設計する「コンテキストエンジニアリング」の重要性が提唱されている。
ステートフルなAIシステム
コンテキストエンジニアリングにより、AIシステムは状態（コンテキスト）を保持する「ステートフル」なものとなり、より複雑で継続的なタスクや対話が可能になるとされる。
プロンプトエンジニアリングとの対比
プロンプトエンジニアリングは主に単発の入出力（ステートレス）を扱う技術であるのに対し、コンテキストエンジニアリングはシステム全体の状態や履歴を設計・管理するより高度なアプローチと位置付けられている。
影響分析・編集コメントを表示
影響分析
この議論は、LLM応用が単純なQ&Aから複雑なエージェントシステムへと発展する中で、必要なエンジニアリング手法の進化を示唆している。実装レベルの具体的な手法や標準はまだ発展途上だが、AIシステム設計の重要なパラダイムシフトの一端として注目される。
編集コメント
概念提唱の段階であり、具体的な実装方法や業界標準は未確立だが、LLM応用の高度化に伴う必須の設計課題として、実務家の関心を集めそうなテーマ。
トランスクリプト
導入 [00:19]
トーマス・ベッツ：こんにちは、InfoQポッドキャストへようこそ。私はトーマス・ベッツです。本日はアディ・ポラック氏にお話し伺います。彼女はConfluentのディレクターであり、『Scaling Machine Learning with Spark』や『High Performance Spark Second Edition』など、複数の書籍の著者でもあります。彼女は最近QConAIで登壇し、大規模なAIシステムを構築する際にプロンプトエンジニアリングの先にある「コンテキスト・エンジニアリング」と、その実現に必要な要素について語りました。それではアディ氏、InfoQポッドキャストへようこそ。
アディ・ポラック：お招きいただき、誠にありがとうございます、トーマス氏。
プロンプト・エンジニアリングとコンテキスト・エンジニアリングの定義 [00:43]
トーマス・ベッツ：まず会話の基礎として、定義を確認させてください。プロンプト・エンジニアリングとは何か、またそれがコンテキスト・エンジニアリングとどのように異なるのか、あなたの定義を教えてください。
アディ・ポラック：非常に素晴らしい質問ですね。これは多くの人々が自分自身に問いかけていることです。本質的には、既存のモデル、あるいは場合によっては複数のモデルに対してどのように指示を出すか、そして最終的に私たちが望む結果を得るためにはどうすればよいかという問題です。どのように翻訳するか、どのような言語を使用するか、コードを与えるのか、それとも私たちが扱う純粋な自然言語（英語）を与えるのかといった点です。
そして、もちろんプロンプトエンジニアリングの世界におけるベストプラクティスについても深く掘り下げていきます。ただし、これは高レベルの話です。いくつかのプラクティスは非常に速く陳腐化してしまいます。そのため、モデルとの連携方法であるワークフローを学び、変化させていく過程で、これらのプラクティスの動向にも注視する必要があります。例えば、「ロール割り当て（role assignment）」は非常に長い期間、モデルとの対話における主要なパターンの一つでした。「あなたはApache Sparkを専門とする経験豊富なバックエンドソフトウェアエンジニアです」といった具合です。
現在では、モデルはこれらの特定の技術により焦点を当てる必要があると仮定し、ソフトウェアエンジニアとして振る舞います。しかし、このロール割り当ての手法は徐々に廃れつつあり、代わりに特定のタスクに特化した環境がより多く導入されています。もう一つのパターンとして、「フューショット例（few-shot examples）」があります。これは人間が思考する方式に似ています。つまり、モデルに行うべきことを指示するのではなく、我々は「良い例」とみなされるもの、あるいは「悪い例」かもしれないものを提示します。それらを分類し、「これは良い例だ」「これは良くない例だ」と伝えることで、モデルはパターンを学習します。
結局のところ、裏側では機械学習や統計学が働いており、パターンを学習し、私たちが何を求めているのかを理解します。これは、人間が必ずしも100%明確に定義されていないパターンから学ぶのと似ています。したがって、これは存在するもう一つの優れたパターンであり、「思考の連鎖（Chain of Thoughts）」では、モデルが自らプロンプトを与え、自身にフィードバックを行い、処理過程全体を通じて思考します。
この裏側では、モデルに対する複数の呼び出しが行われます。そして今日、モデルはそれ自体でそれを処理する方法を知っており、これはそれで非常に興味深いことです。モデルからのフィードバックを受け取り、自身で処理を行うループを含むML AIパイプラインを想像してみてください。これが「思考の連鎖」です。もう一つのパターンは制約付きの設定（constrained settings）です。私たちは仕様を提示します。「これが私の仕様だ」「どのようにソフトウェアを構築したいか」「使用する言語はこれらだ」とモデルに伝えます。それを受け取り、消化し、これが私たちが作業するプロンプトの一部となります。もちろん、これは鵜呑みにはできません。これらは常に進化しているものです。
プロンプトエンジニアリングは動く標的である [03:36]
トーマス・ベッツ：はい。あなたが挙げたすべての点について、プロンプトエンジニアリングという概念がどのように学ばれてきたかを見ると、それは最初はまるで流行語のようでした。「そんなものはない」と思われていたのです。しかし私たちは気づきました。いや、実際にこのツールの使い方を学ぶ必要があると。なぜなら大規模言語モデル（LLM: Large Language Model）は単なる製品であり、私たちが持つ一つのツールに過ぎないからです。そして、それを適切に、あるいは不適切にどう使うかについては、進めながらある程度理解してきました。そしてそれらのLLMが絶えず進化しているため、私たちがそれらと対話する方法もまた進化し続けています。そこであなたは、単に「あなたの役割は〜です」と言うだけでなく、フューショット・ラーニング（few-shot learning：数例提示による学習）を行い、「これが良い例で、これが悪い例です」と伝えることで、モデルに追従すべきパターンを与えると述べました。私たちは依然として、LLMそのものを変更していないのです。モデルを再プログラミングしたり、新しいトレーニングデータを与えたりしているわけではありません。単に「このセッションの文脈において、このような振る舞いをしなさい」と言っているだけです。
現在ではセッションの容量が大きくなっているため、これらのコンテキスト（文脈）は拡大できますが、それでもなお「新しいことを始めるまで、この例に従い、その後で異なる振る舞いを指示する」という原則は変わりませんよね？
Adi Polak: そうです。そして、興味深いエッジケースをいくつか追加したいと考えています。モデルは次の単語やコードの行などを出力することに非常に優れていることは皆知っています。過去、おそらく1年前には、優れた数学モデルを作成するラッシュがありました。そのアイデアは、モデルが適切な方程式を考案し、スプレッドシートを取り込んで背景で統計や計算を行う方法を理解できる可能性があるとされていました。しかし、現在学んでいることは、より一般的なモデルの一部はこれらのことに優れているはずですが、実際にはそうではないということです。
したがって、ソフトウェアエンジニアとして、私たちはモデルに構築する必要があるものをプロンプトする作業に戻ります。つまり、スプレッドシートを与えて最善を期待するのではなく、「hey、このスプレッドシートやデータベース、または操作が必要な他のものに対してこれを行うコードを書いてください。あるいは、ここにある数学方程式を実装してください。または、感情分析のようなものを実装してほしいです。あるいは、この最先端のアルゴリズムをここに実装してください」というように、具体的な指示を行います。つまり、より具体的になるということです。
したがって、ドメインの専門知識がある場合、プロンプトエンジニアリングは真価を発揮します。つまり、現在学んでいる重要な点は、達成したい目標を理解し、そこに到達するためのステップの大まかなアイデアを持っている必要があるということです。
プロンプトから再利用可能なツールとスキルへ [06:05]
トーマス・ベッツ：はい。そして、私の同僚の多くが少なくとも次のようなアプローチを始めたと感じています。「この1つをやって、それからツールやスキルを作成する。結果として得られる手順をファイルに保存しておく」というものです。最初は単なるインストラクション・ファイルから始まりましたが、今では多種多様な形に進化しています。あなたが言ったように、「必要な処理を行うPythonスクリプトやPowerShellスクリプト、Bashスクリプトを作成する」といった形です。なぜなら、後で同じ質問をAIに投げかけた場合、毎回「今日はPythonスクリプトでこれを解決しよう」と考え直す必要があるかもしれないからです。そして明日、同じ質問を投げかけるとなれば、「MCPサーバーを呼び出して、あとは運に任せる」という感じになります。実際にやりたいことが明確になり、ドメイン知識を活用して優れたプロンプトを作成するための処理内容が確定すれば、その後で最適なツールは何かを特定することができます。
そのプロセスを保存しておけば、同じ手順を繰り返すことができます。しかも、毎回トークンを消費して新しいプロセスを考え出す必要もありません。
アディ・ポラック：その通りです。これをエンジニアリングチームとしてどのようにスケール（規模拡大）していくかという視点で考えると、このアプローチが理解できるでしょう。
人間中心型ワークフローとエージェント型ワークフロー [07:01]
トーマス・ベッツ：はい、スケーラビリティは確かに重要な要素です。そして、私が言いたいのは、私たちが議論したいことのひとつに、エージェントワークフローと人間中心のワークフローの違いがあります。ChatGPTやClaudeといった他のツールが登場した当初、プロンプトエンジニアリングの多くは人間中心のアプローチから始まりました。私は単にプロンプトを入力して、欲しい結果を得るだけでした。それがコードであれテキストであれ画像であれ、何かを依頼すればそれを得られるという仕組みです。そして今、これらのツールは独自のビルトイン・エージェントワークフローを採用するようになっています。「このタスクを完了してください」と依頼すると、ツールが計画を立て、「まずはこのような計画です」と示し、進捗とともにチェックしていく仕組みです。こうした変化はどのように進化しているのでしょうか？あなたが言及されているのは、コンテキストエンジニアリングが、これらの出来事が私たちの目の前でリアルタイムに進行する様子を観察する方法の一つであるということではないでしょうか？
Adi Polak：はい、少しだけですが。本当に驚くべきことです。数日前のことですが、私たちはオープンソースへの貢献を多く行っています。そのため、外部リポジトリへのgit pushを行うたびに、IP（知的財産権）が漏洩しないことを確認する専用システムを備えた内部システムを開発しました。これは、特にエンジニアリングの分野で望まれることで、私たちはオープンソースへの貢献とプラットフォームの構築の両方を行っています。したがって、IPが漏洩するミスを排除したいと考えています。そして数日前から少しコーディングをしていましたが、6年前の非常に古いコミットの一部がGitHubのPRコミットログ（すべてのSHAと関連情報をキャプチャするもの）で検出されました。私はオープンソースのライブラリを使用していましたが、そのインポート方法は他の用途と同じライブラリをインポートした方法と全く同じでした。
つまり、それは実際のIP（知的財産）のようなものではなく、単にライブラリをインポートしてその行を使用しているだけでした。そして私たちのシステムがそれを検出しました。ここで、エンジニアとして私が取るべき行動は、「PR（プルリクエスト）のコミットログがあることは知っている。Git の動作原理も理解している。SHA（セキュリティハッシュアルゴリズム）を取得し、その周囲の徹底的な実験を行い、そこにどのようなファイルがあったかを特定する必要がある。それらのファイルは今も必要か？削除できるか？その状態にリビルドやリベースを行うことができるか？」といった具合です。つまり、その行を削除すれば、GitHub はまるでその存在がなかったかのように振る舞います。私はこの作業を古くからの手動方式で処理しました。「必要なすべての手順」を書き留めたノートを持っていました。しかし、ファイル数が多く変更点も多いため、状況はすぐにカオスになりました。さらに、話しているのは6年前のコミットのことです。
当時の具体的な出来事や、自分が何をしたのかはあまり覚えていません。ただ、その一行を削除する必要があることはわかっていました。まるで干し草の山の中から特定の針を見つけるようなものでした。その作業を始めて4時間後、私は完全に失敗してしまいました。会議やSlackのやり取りなどがあったためです。それで思考の流れを失い、完全に台無しにしてしまいました。そこで、「よし、元に戻そう。最初からやり直そう」と考えました。それで元に戻したあと、「待てよ、Claude Codeがあるじゃないか。やるべきことはわかっている。Claudeに説明して、適切なコンテキスト（文脈）を与えれば、必要な情報やツールへのアクセス権限、Gitでの現在の状態をすべて伝えれば、これをやってくれるはずだ」と思いました。それで実際にそうしました。すると5分もかからず、そのコードをオープンソースリポジトリにプッシュすることができました。Claudeが内部に入り込み、「手術」を行って私のために修正し、削除すべきものを削除してくれたからです。
私の意見では、これはゲームチェンジャーです。これらのことを考えるとき、これは一つの例に過ぎませんが、これには非常に時間がかかってしまいます。なぜなら、私は日常的にこのような作業を行っていないし、エンジニアの誰もが日常的に行っているわけではないと思うからです。
コンテキストスイッチング、気散漫、エージェント支援 [10:38]
トーマス・ベッツ：あなたは気が散ったと述べていました。やろうとしたものの、会議に行かなくてはならず、Slackでの他の会話にも返信する必要があったと。そして「4時間後」と言ったとき、あなたは4時間ずっとコードを打ち続けていたわけではありませんでした。あなたの1日のうち4時間分の「人間の時間」が経過し、コンテキストスイッチング（文脈の切り替え）が発生していたのです。あなたは単にその一つの課題について考え続けることができたわけではありませんでした。また、ご存知の通り「ヤク刈り」のような状況、つまりここに行き着くために別のステップを実行し、さらにその先で別の手順を踏まなければならなかったという経験があるでしょう。そして、実際に達成したかった一つのことに到達する前に、やらなければならなかったタスクのスタックの中で自分がどこにいるかを覚えておかねばなりませんでした。私たちは、こうしたすべての情報を記憶し続けることに struggle（苦戦）することがあります。
そして、時にはメモ帳を開いて、ただノートを書くこともあります。「今ここで行っていること」と「私が完了した作業」を記録するのです。ツールがどのようなものかを見ているようです。これは低レベルのLLMではなく、あなたが言ったようにClaude Codeです。製品はその機能を追加しています。そして、より多くのLLM製品や、内部で実際にLLMを備えていると主張する他の製品を開発していくにつれて、エンジニアやアーキテクトである私たちが考えるべきことは、ユーザーがポジティブな体験を得られるように、アプリケーション内でそのコンテキスト（文脈）をどのように管理するかです。ユーザーは「このタスクを達成したい」と言います。私たちのソフトウェアは、「このタスクを達成する方法」を考え出し、ユーザーは「自分が何をしようとしているか」を書き留めます。私は人間に、「これが良いステップのように思えますか、それともそのまま実行すべきですか？」と尋ねるかもしれません。
では、それをどのように達成するのでしょうか？本当にマークダウンファイルを作成し、参照しながら進捗に応じて更新していくことなのでしょうか？そのコンテキストを管理するための良いテクニックは何でしょうか？
ワークフローをスキルとしてキャプチャする [12:13]
Adi Polak: はい。私が特に気に入っているアプローチの一つは、実際にプロセスを踏んでからClaudeにそれを「スキル」として保存させることです。この方法であれば、スキルのMD（Markdown）ファイルの空白から始めなくても済みます。こうすることで、実際に私が望む通りの進行になることを確認できます。つまり、対話を通じて進めていくのです。場合によってはClaudeが選択肢を示すことがあります。「これは意図しましたか、それともあれですか？明確にしてください」といった具合です。非常に慎重な人間と話すことに似ていて、少し考えれば、エッジケースやその他の事象について本当に深く考えることになります。
すべてのことが常に間違っているわけではありませんが、時には「いや、どこでつまずいたのか、そして本当に望んでいたことが何だったのか」を見失うことがあります。しかし、そうした作業を経てセッションを終えた後、「さあ、今学んだすべてのことをスキルとして保存し、そのスキルを追加して期待通りの結果が得られるようにしよう」と言えます。これは実証済みで、現在ではスキルを蓄積し、チーム全体や会社全体のスキルリポジトリを作成することが可能になりました。これにより、人々は互いの知識を活用する恩恵を受けられ、さらに複数のスキルを使用できるため、より良いソフトウェアの作成に役立っています。
コンテキストスイッチング、気散漫、エージェント支援 [13:29]
Adi Polak: 例えば、コーディングセッションに入る際、私は「ここにはスキルリポジトリがあるが、すべてをコンテキストに読み込んでいるわけではない」と言うことができます。ここは非常に重要なポイントです。すべての情報をコンテキストに読み込みたくはありませんが、そこに何が存在するかという知識は持っておきたいのです。つまり、それは検索可能であるべきです。追跡でき、そのスキルの品質レベルも把握できるようにしたいのです。もしそれを維持できれば、それは非常に良いことです。その後、特定のセッションや実行したい特定のタスクに対して、どのようなコンテキストを持ってくるのが適切かを判断できます。なぜなら、LLM（大規模言語モデル）にあまりにも大きなコンテキストを与えると、エラーが増え、最終的にはコストも高くなるからです。根本的な仕組みを考えれば、すべてのコマンドに対してすべてを連結しているだけだからです。
つまり、裏側では主に文字列の連結が行われているということです。大手企業が実装しているより洗練された方法があるかもしれませんが、結局のところそれが本質です。そのため、どのコンテキストを持ってくるかについて賢明である必要があります。システムを過負荷にしないよう、どのように管理するかについても賢明でありたいのです。
開発者体験 → エージェント体験 [14:48]
トーマス・ベッツ：はい。スキルライブラリというアイデアは気に入っています。「自分が知っていることをすべて読み込まなければならない」というのではなく、このリストを見て、「自分ができること」を確認し、そのスキルの中から必要なものを選んで「よし、これを参照しよう」という流れが理解できます。私は年齢的に、Stack Overflowですべての情報を検索したり、お使いのLLMツールに質問したりする以前は、本棚に非常に有用なリファレンス書籍を並べていた世代です。その本の索引を開いて、「これを探しているんだ」と言い、サンプルのコード片を見つけて、「よし、この汎用的な例を自分の具体的なケースにどう適用すればいいか？ この本やオンライン記事で示されているアイデアを応用できるな」と考えていました。
今、そのようなことを実行するソフトウェアが存在します。私たちはほぼ、同じような考え方を始める必要があるでしょう。私のような人間が、その参照資料をどのように保存し、どこでそれを検索するかを考えなければなりません。これは、これらのツールを単なるワンショットプロンプトとして使用する際に戻ってくるアイデアです。私が何でも尋ねれば何らかの答えが返ってくるものの、その品質はそれほど良くありません。もしあなたが製品やツールをより適切に使用し、それらの技法を活用し始めれば、インターネット上のすべてのことを知っていることが期待されることはありません。私もすべての書籍の内容を知っているわけではなく、それらを検索して参照していました。つまり、「これらを調べさせて、システムに組み込む」と宣言することで、ツールを成功させる準備を整えるのです。これは、これまで私たちが直面してきたソフトウェアの考え方とは異なる、新しいアプローチのように思えます。
Adi Polak: はい。少し考えてみてください。私たちは、開発者体験（DevEx）の世界から、エージェント体験へと移行しています。つまり、「どのように公開するか」という問題です。私自身は開発者であり、本が好きで、本を書き、そこに行って読み、学び、参照資料として使用することを好みます。しかし、私が現在持っているツールでは、私にとってより良い選択肢が他にも存在することは知っています。ただ、私のエージェント（自律型ソフトウェア）がそれらにアクセスできるようになる必要があります。そこで、新しく登場した優れたツールについて知りたい場合や、社内で開発したユーティリティーツールを使用したい場合に、それらにアクセスする方法を考えなければならないのです。
私たちは依然として、開発者のエクスペリエンスやフロー状態を重視し、人々が成功し生産的に活動できるための適切なツールを提供することに注力しています。さらに、エージェント的なエクスペリエンスも追加しています。ワークフローやシステムをどのように構築するか、そして開発ライフサイクル（SDLC）、CI/CD、さらには本番環境での運用に至るまでを跨ぐ、場合によってはマルチエージェントからなるシステムをどのように構築し、それらを通じて真に成功するかという問いに取り組んでいます。
これらのツールにはコンテキストが必要であり、多くの場合ステートフル（状態を保持する）です。そのため、これに関連する要素は多数ありますが、第一歩としてコンテキストが必要であり、チャットボットの時代のようなステートレスなアプローチから、ステートフルかつエージェント的なアプローチへと移行する必要があります。
エージェントシステムにおける短期記憶と長期記憶 [17:44]
トーマス・ベッツ：それは一時的な（short-term）メモリについての話ですね。私はこのプロセスを開始し、すぐに終了して死んで、新しいプロセスを起動して実行し、それで完了する。それがあなたが言っているステートレス（stateless）なものです。あなたはステートフル（stateful）について話しています。何日にもわたってビジネスプロセスを実行するエージェントがあり、その異なる部分を引き継ぐかもしれません。あるいはマルチエージェント（multi-agent）のシナリオについて話すと、オーケストレーター・エージェント（orchestrator agent）がさまざまなサブエージェント（subagent）を持っているというアイデアが好きです。それらの間でメモリをどのように管理しますか？ それらすべてが起きていることをすべて知っている必要があるのか、それともコンテキスト（context）を分割して「必要な情報でこの問題を解決し、より良い回答を得るために大きな絵を提供する」というような技術がありますか？
アディ・ポラック：それは私が構築しているワークフロー（workflow）に大きく依存します。したがって、私たちは常に一時的なメモリと長期的な（long-term）メモリについて考えます。これらは常に知りたいことです。「私が引き出す必要があるものは何か？」というように、非常に高いレイテンシ（latency）が必要で、今すぐ必要だが後で忘れてもよいものです。これは特定のタスク、あるいは特定のサブタスク（subtask）のためだけです。したがって、完全なタスクですらありません。そして、より長いセッション全体を通じてそのコンテキストを維持するための異なる技術があります。例えば要約（summarization）や、そのコンテキストの階層性について考えることです。
モデルが「Pythonで作業しているけど、また最初からやり直そうか」と言ってくることがあると思います。そして今やると、「よし、今度はMCPサーバーに切り替えて、あなたは突然JavaScript開発者になって、異なるプログラミング言語からのスクリプトを扱っている」という状況になります。そうならないようにしたいので、このコンテキストはセッション内に既に存在している必要があります。さて、私たちが構築するものやニーズによって異なりますが、長期記憶が必要になる場合もあります。つまり、長期記憶とは、私のシステム内に何が存在するか、私たちがその空間で操作している場所における「耐久性のある知識」のような全体的なものを指します。
ここで、スキルという概念が非常に重要になってきます。また、RAGのようなものを検討し始めたい場合もあります。これは、データベースや既存の他のデータシステムから情報を取得し、必要な箇所でその情報を補強するアプローチです。これはより長期のコンテキスト、つまり長期記憶であり、これも重要な柱となります。つまり、セッション内に存在する短期的な情報と、常に最新の状態に保つ必要がある長期記憶の両方があります。そのために、異なるデータパイプラインやMLパイプラインが必要になるかもしれません。最近では用語が少し変化していますが、それが存在する必要があることは理解しています。
RAGはマルチエージェントワークフローにおける多くのツールの一つ [20:30]
トーマス・ベッツ：さて、RAG（Retrieval-Augmented Generation）について言及してくださって嬉しいです。1年前、それが誰もが注目していた話題でした。「RAGが必須だ」「RAGを使わなければならない」という感じでした。それは、より良い結果を得るための最速で最も簡単な方法と見なされていました。しかし現在、RAGはツールボックスの中の単なる一つの道具に過ぎません。しかし、エージェントワークフロー（Agentic Workflow）に取り組む場合、「常にRAGモデルを持つ単一のソースを参照する」という単純な話ではなくなりました。「必要な時に、関連する回答を見つけ出し、それを解決しようとしているタスクの文脈に取り込む」という考え方はありましたが、それは1年前、つまり「古代」の話で、ほぼステートレス（Stateless）なモデルでした。「RAGを呼び出し、結果を持って帰る」という感じでしたが、今私はよりステートフル（Stateful）なソリューションを求めています。プロセスの最初のステップで外部の情報を探し、その情報を持ち帰り、その後、その結果を別の小さなエージェントに渡して、それに対して他の処理を行わせる。そういうことです。
そのような形で、これらの要素がマルチエージェントモデル（Multi-agent Model）として組み合わさっていくとあなたは考えていますか？
Adi Polak：はい。そして、それは私たちが構築しているワークフローが何であるかに大きく依存すると考えています。エンジニアリング向けのワークフローを構築する場合、それは異なる形になることがあります。なぜなら、今私たちはスキルに基づいた純粋なエンパワーメント、ソフトウェアの作成、私たちの知識や経験などに焦点を当てているからです。そして、その考えを持ってモデルに到達することは、通常、物事を行うための新しいスキルを持つことを意味します。ベストプラクティスがあり、モデルが従うべきデザインパターンがあります。テストスイートもあります。私には私のドクターエージェントがあり、それが私のためにものをテストしてくれます。だから朝起きたら、それを実行し、いくつかのチケットやその他すべてが期待通りに動作していることを確認します。これは100%生産性ツールです。さて、ビジネスインテリジェンス（BI）の部分のように、既存のデータを強化し、そこに新しいテーブルがあることを基にしたより良いSQLを作成したいという別の世界があります。
さて、大企業で働いている可能性があります。通常、大企業ではデータサイロが存在し、私はそこで何が起こったかを検索し、取得できる能力を持ちたいと考えています。たとえテーブルの正確な名前を必ずしも知らない場合でも。
したがって、RAG（Retrieval-Augmented Generation：検索拡張生成）のような技術がここで役立ち、私のクエリに到達し、SQLを拡張し、現在の知識の範囲を超えて広がることを可能にします。これはまさにRAGが構築された目的です。セマンティクス（意味論）に基づいた検索が可能になるような、適切なインデックス付きデータベースがどこかに存在します。ここで重要なのはセマンティクスです。なぜなら、私たちは検索対象を正確に知らない場合が多く、その場合、私たちが使用している言語を使って、モデルが「ああ、あの場所にそのようなテーブルが存在する」といったいくつかの提案をしてくれることを期待しているからです。私はカタログからこれを引っ張ってきましたが、これは新しいテーブルで、昨日作成されたばかりです。しかし、すでに最新のデータで満たされています。これについて調査する興味がありますか？あなたが抱いているビジネス上の質問にとって、これは意味を成しますか？
さて、これはエンジニアの生産性向上のためにAIを使用するのと全く異なるワークフローです。
KafkaとFlinkを用いたイベント駆動型アーキテクチャ [23:56]
トーマス・ベッツ：はい。その「発見可能性」の問題は常に存在します。もしあなたが新しいものを探しに行かないなら、新しいものが登場していることをどうやって知ることができるでしょうか？そこで、そうした変化を常に監視し、私たちに知らせてくれる異なるツールを持つことができます。私はあなたがConfluentで働いているので、Apache KafkaやApache Flinkに精通していることを知っています。それらの製品はAgentic（自律型エージェント）アーキテクチャにおいてどのような位置づけになるのでしょうか？私は多くの人がそれらを使用しており、これらのツールの上にワークフローを構築する場合にどのようなメリットがあるのか、そして彼らがまだ慣れていない場合にTeams（チーム）が採用し始めることをあなたが期待していることは何かについて、多くの人が疑問を持っているのを知っています。
Adi Polak：はい。すでに多くの企業が採用しており、世界中で開催されるデータストリーミングに関するKafka Summitや各種カンファレンスの主要なセッションで共有されている事例があります。例えばOpenAIがその一つです。同社は非常に大規模なKafkaクラスターとFlinkを運用しています。そして、ユーザーがリアルタイムで対話するモデルに関するすべての処理は、イベント駆動アーキテクチャ（event-driven architecture）を通じて構築されています。裏側では、Kafkaがこれらのイベントを非常に低レイテンシでリアルタイムに転送する役割を果たし、Flinkはエンリッチメント（enrichment）、要約、リアルタイム分析を担当しています。さらにこれらの基盤の上に、モデルにより多くのコンテキストを提供し改善するために、先ほど述べたように、現在のモデルはすでに自律的に行動する段階にあります。プロンプトエンジニアリング（prompt engineering）について議論した際にも触れましたが、思考の連鎖（chain of thoughts）が存在し、この思考の連鎖は本質的にイベント駆動パターンとして捉えることができます。
その一つは、おそらく新しいパターンとして定義でき、これらのタイプのソリューションを構築する際のインフラストラクチャとなります。したがって、社内でも、エンジニアリング作業をサポートするためのワークフローをどのように構築するかを考える際、必ずしも巨大な Flink クラスターが必要というわけではありませんが、特にチケットシステムに関連するプロセスやワークフローにおいて、「何が何をトリガーするか」というイベント駆動の考え方は非常に役立ちます。例えば、コード品質に関連するエージェントがコードをスキャンし、改善のための新しいチケットを提案したり、あるいはチケットを引き受けてすでにコード付きの解決策のアイデアを提供し、開発者の承認を待っているようなケースです。こうした可能性に多くの企業が関心を示し始めたため、私たちは「Flink Streaming Agents API」と呼ばれるもの、およびオープンソースのデータを開発しました。
これを利用し、試し、貢献したい誰にとっても、Flink リポジトリの一部として利用可能です。
バックログとエンジニアリングワークフローの自動化 [26:42]
トーマス・ベッツ：私は、イベント駆動型ワークフローが「この処理を開始して、その後これらのことが起こる」という従来のアプローチではなく、バックグラウンドで動作するエージェントがそれに応答するという「アジェンティック・プロセッシング（agentive processing）」へと進化していくというアイデアが好きです。そうすれば、さまざまなことが背景で動作し、それらのエージェントがそれに対応するようになります。多くの可能性が見えてきます。これもまた、「この作業を行え」という従来のパラダイムとは異なる、別の思考パターンが必要です。「これが起こったら、あれを開始する」という考え方です。SDLC（Software Development Life Cycle：ソフトウェア開発ライフサイクル）やCI/CDパイプラインといったソフトウェアの話にも触れましたね。コミットをチェックインすると、プルリクエストがトリガーされたり、このプロセスが実行されたりして、「外部に機密情報（IP）が漏れていないか」をチェックします。あるいは、それらの異なるプロセスがすべて発生し、それらがより大きなコンテキストモデルへと統合される。それがあなたが話していたFlinkの役割でしょうか？つまり、Kafkaで「このイベントが発生した」ということが示され、その後Flinkが介入して、「その事象に加え、他のこれらの事象も観測されたため、これがより大きな全体像です」というデータを強化（enriching）する、という理解でよろしいでしょうか？私の理解は正しいですか？それとも、より適切な説明方法があるのでしょうか？
Adi Polak: これは一例です。私が想定している例は、Jiraのチケットではなくても構いませんが、お好きなチケット管理システムを使って、無限にあるバックログ（課題リスト）を処理するケースです。この無限のバックログは、トリアージ（優先順位付け）、分類、整理を行い、社内アーキテクチャドキュメントからの追加情報で充実させ、製品や顧客からの優先順位付けを行う必要があります。これらは異なるシステムです。したがって、エージェントがそれらのシステムを巡回して要約し、優先順位付けを行うような日常業務を想像してみてください。単純なタスクについては、コーディングソリューションを提案し、さらにはプルリクエストを作成して開発者がアクションを起こせるようにすることも可能です。ここでマルチエージェントプロセスが作用し、特に膨大なバックログを抱える多くの企業において、一部のエンジニアリングプロセスを改善します。私たちは機能面のバックログの底まで到達することはありません。
そして、メンテナンスやマイグレーションに関連する小さな更新事項は常に存在し、それらを実行する必要があることは分かっています。しかし、顧客が具体的にそれを要求していないため、優先度は高くありません。ただし、LLM（大規模言語モデル）がそれらを拾い上げて解決策を提案できれば、チケットを受け取って自分たちで処理するよりも、レビューを通じてより迅速に実行できます。これらは私たちが構築している取り組みの一部であり、エンジニアがより意味のある作業を行えるよう支援することにもつながっています。
将来展望：創造性を中核スキルとして [29:13]
トーマス・ベッツ：さて、私はいつも会話の結びとして未来を見据えることを好んでいます。AI に関して私が感じているのは、「1〜3年後に何が見えているか」と尋ねるのではなく、むしろ「今から半年後、あるいは来年までに」どうなるかを問うべきだということです。特にコンテキストエンジニアリング（Context Engineering）の文脈において、人々はソフトウェアシステムの設計、アーキテクチャ構築、そして実装をどのように変えていくと予想されますか？
アディ・ポラック：はい。何がどう変化し、私たちに最適なソリューションが何になるかは分かりません。ただ言えるのは、聴取者の皆様が新しいことに挑戦し、新たなアイデアを持ち出し、創造性を使う機会を持っていることです。私たちはいつも、「夢に見れば、それは可能であり、構築できる」と言っています。私は心から信じています。現在私たちが持っているツールがあれば、夢に見たものは実現可能であり、数年以前よりもはるかに迅速に実行できるということです。何がどう変わるか、私たちがどこにいるかは分かりませんが、好奇心を持ち、この業界で最新情報をキャッチアップし続けたいと願い、ビルド（構築）を続けていきたいのであれば、今最も重要なスキルはあなたの創造性です。それを使い、実行し、挑戦してください。
トーマス・ベッツ：その通りです。試し続けてください。「ああ、前回試してから半年も経っていないから」と考える必要はありません。前回試したときと比べて、かなり変化している可能性があります。だからもう一度試してみてください。おそらく全く異なる結果が得られるでしょう。さて、これで時間切れです。アディ・ポラック、本日はお越しいただき、改めて感謝いたします。
Adi Polak：トマス、お招きいただきありがとうございます。いつもお話しできて嬉しいです。
Thomas Betts：そしてリスナーの皆さん、またすぐに別のエピソードでお会いできることを願っています。
Podcastの最新情報はRSSフィードでご覧いただけます。また、SoundCloud、Apple Podcasts、Spotify、Overcast、YouTubeでもご利用いただけます。
このページからは録音されたショーノーツにもアクセスできます。これらには、オーディオの該当部分に直接ジャンプできるクリック可能なリンクが含まれています。
原文を表示
Transcript
Introduction [00:19]
Thomas Betts: Hello, and welcome to the InfoQ Podcast. I'm Thomas Betts. Today I'm talking with Adi Polak. She's a director at Confluent and the author of several books, including Scaling Machine Learning with Spark and High Performance Spark Second Edition. She recently spoke at QConAI about context engineering and what it takes to move beyond prompt engineering when building AI systems of scale. So Adi, welcome to the InfoQ Podcast.
Adi Polak: Thank you so much for having me, Thomas.
Defining Prompt Engineering vs. Context Engineering [00:43]
Thomas Betts: So to start the conversation, let's get a baseline. What's your definition of what prompt engineering is and how does that differ from context engineering?
Adi Polak: That's a really great question. It's something that a lot of people are asking themselves. It's essentially, how do we instruct an existing model or how do we instruct multiple models sometimes? So it will give us what we want at the end. How do we translate? What is the language that we use? Do we give it code? Do we give it pure English language that we work with?
And then it of course dives into best practices inside the world of prompt engineering. But this is the high level. Some of the practices becomes outdated really fast. So this is another thing to watch as we learn and change the workflows of how we're working with models. For example, role assignment for a very, very long time, role assignment was one of the key pattern of how to work with the models. You're an experienced backend software engineer specialized in Apache Spark, for example.
And now the model assumes you need to focus more on these specific technologies, and the model is now acting as a software engineer. Now that role assignment is slightly going away, and now we have more environment that is specialized for that particular thing. Another pattern is a few shot examples. That's kind of like how we think as humans. So instead of telling the model what to do, we give it examples that we know are considered good examples, maybe bad examples. We classify them and we tell it, "Hey, this is a good example. This is an example, not good example". And the model learns the patterns.
At the end of the day, behind the scenes, it's machine learning, statistics, it learns the patterns and it understands what we want. Kind of like how as humans, we learn from patterns that sometimes are not 100% well-defined. So this is another great pattern that exists and chain of thoughts, the model kind of prompt itself and give itself a feedback and think throughout the process that it goes through.
And that behind the scenes creates multiple calls to the model. And today the models know how to do it on their own, which is kind of fascinating by itself. You can imagine a ML AI pipeline and a loop with the model where it takes feedback for itself and kind of awkward, and that is a chain of thoughts. And another pattern is constrained settings. We give it specifications. We tell the model, "Here's my spec. Here's how I want my software to be built. Here are the languages". Take it, digest it, and this will be part of the prompt that we work with. Of course, take it with a grain of salt. These are things that are always evolving.
Prompt Engineering as a Moving Target [03:36]
Thomas Betts: Yes. Everything you mentioned, as we've learned the idea of prompt engineering, it started as one of those, almost a buzzword, like that's not really a thing. And you realize, no, we actually have to learn how to use this tool because LLMs, they're just a product. They're just a tool that we have. And how to use it properly and improperly, we kind of figured that out as we were going. And because those LLMs keep evolving, how we interact with them keeps evolving. So you mentioned, instead of just saying you're a role, now you're doing the few shot and saying, these are good and bad examples. And you said that gives it patterns to follow. We're still talking about not changing the LLM at all. We're not reprogramming the model and giving it new training data. We're just saying in the context of this session, behave this way.
Now they have larger sessions, so those contexts can grow, but you're still saying, just follow this example until I start a new thing and tell you to behave something differently, right?
Adi Polak: Right. And I want to add some interesting edge cases. We know models are really good at spitting up and giving us the next word or line of code and so on. I think in the past, maybe a year ago, there was a rush to create really good mathematical models as well. And the idea was that a model could potentially be able to come up with the right equation and the right way of taking a spreadsheet and doing all the statistics and calculation behind the scenes. And what we've learning now that the more general models, some of them should have been good at these things, this is not the case.
So as software engineers, we're going back to prompting the model of the things that we need to build. So instead of giving it a spreadsheet and hoping for the best that it will do what it needs to do, we're taking it back to, "Hey, write me this code that does these things to that spreadsheet or database or anything that we need to operate on and here is the math equation or here's what I want you to implement like sentiment analysis or take this state-of-the-art algorithm and implement it in here". So it becomes more specific.
And so prompt engineering really shines when we have the domain expertise. So this is an important bit that we're learning now that we need to know what we want to achieve and we need to have a rough idea of what are the steps to get there.
From Prompts to Reusable Tools & Skills [06:05]
Thomas Betts: Yes. And I think I've seen a lot of my coworkers at least have started turning to, I'm going to do this one thing and then I'm going to create a tool or a skill. I'm going to save a file that says, here's how to do that. It started with just our instructions files, but now it's turned into a lot of different things. Like you said, create a Python script or a PowerShell script or Bash script that does the thing I needed to do because if I go back to, I'm going to ask it the question, it might every time have to go back and say, "Well, maybe today I'm going to solve that with a Python script". And then tomorrow you ask it the same question. It's like, "I'm just going to call an MCP server and hope for the best". Once you figure out what you're actually trying to do is going to do that thing that we need the domain knowledge to be able to write good prompts, we can then use that to figure out what are the best possible tools.
Save that so I can repeat that process again. And I don't need to use up my tokens coming up with a process every time.
Adi Polak: Right. And this is how we scale as an engineering team if you think about it.
Human-Centric vs. Agentic Workflows [07:01]
Thomas Betts: Yes, the scalability is definitely a factor. And I think that gets to one of the things we want to talk about was we have really an agent workflow versus a human-centric workflow that a lot of this prompt engineering started with ChatGPT came out, Claude, all the other tools. I would just type in a prompt and get what I want. And whether that's code or text or an image, I just ask for something and I get it. And now I've moved to those tools have either their own built-in agentic workflow like, "Please accomplish this task and it'll plan out and it'll be, let me come up with a plan, show you what the plan is going to be, check it off as I go through it". How is that evolving? Isn't that what you're kind of talking about is context engineering is one way that we're watching these things happen in real time in front of us?
Adi Polak: Yes, a little bit. It's kind of amazing. So just a couple of days ago, we contribute a lot to open source. And so we developed an internal system that separates. Every time we do a git push to an external repository, we have a dedicated system that makes sure there's no IP being exposed. This is something that you want in engineering, especially with engineering, it contributes all the time to both open source and also builds the platform. So we want to eliminate mistakes of IP being exposed. And so couple of days I've been coding a little bit, something small and some of my very old commits from six years ago, in GitHub, you have PR commit log that captures all the SHA and all the information there. Some very, very old commits got picked up because I used a library that was open source, but the way I imported that library was the same way we imported the same library for other things.
So it wasn't like a real IP, it's just importing a library and using it line. And our system picked it up. Now, what I would do as an engineer was like, "I know there's a PR commit log. I know how Git operates. I know I need to pick up the SHA, go do the whole surgical experiment around, go figure it out what the files were there. Do we still need them? Can I delete that? Can I rebuild rebase to that state?" So delete that line and now GitHub behaves as if that doesn't exist. I took it kind of like the old-fashioned way. I had my notes, "Here are all the steps that I need to do. " And it became messy really quick because you have a lot of files, you have a lot of changes. And I'm talking about commit from six years ago.
I don't really remember what happened back then, what exactly I did. I just knew I needed to delete that one line. It's kind of like I need all in the haystack. Four hours into that process, I completely messed it up. I had meetings and Slack and so on. So I lost train of thoughts and completely messed it up. So I was like, "Okay, revert. Let's go back". So I reverted and then I was like, "Hey, wait, I have Claude code. I know what needs to get done. Can I explain to Claude and give it the right context, right? Everything that I need to be there and the tool access and what is happening with Git, can you do that for me?" And so I did. And within five minutes, I was able to push that code to the open source repo because Claude went in, did the surgery, fixed it up for me, and deleted what needed to be deleted.
And that's a game changer, in my opinion, when you think about these things, because it was only one example, but this is where it would take me really long time just because I don't do it on a daily basis and I think no engineer does it on a daily basis.
Context Switching, Distraction, and Agent Assistance [10:38]
Thomas Betts: You mentioned that you got distracted, you were trying to do it, but then you had to go to meetings and you had to answer other Slack conversations. And so when you said it was four hours later, you weren't sitting there typing code for four hours. It was four human hours of your day and you were context switching. You didn't just get to think about that one problem. And I know there's a little bit of the yak shaving, if you will, of I went down here and then I had to do this other step and then I had to do another step before I could do that. And so you've had to remember, well, where was I in the stack of things I had to do before I could get to the one thing I actually wanted to accomplish? We sometimes struggle as people to remember all that stuff.
And sometimes I'll open up Notepad and I'll just write down notes. If here's what I'm doing, here's the stuff that I've done. It seems like we're seeing the tools. And this isn't the low level LLM, this is like you said, Claude Code. A product has been adding that capability in. And I think as we build more LLM products or more products that we're saying have AI in them and they're really LLMs under the covers, that's what we as engineers and architects need to think about is how do we manage that context within our application so that the user gets a positive experience? They say, "I want to accomplish this task. Our software figures out, here's how I can accomplish this task, but I'm going to write down what I'm going to do". I might ask the human, "Does this sound like a good step or should I just go off and do it?"
So how do we accomplish that? Is it really just like, let me write a markdown file and keep referencing it and updating as I go through? What are some good techniques for keeping that context managed?
Capturing Workflows as Skills [12:13]
Adi Polak: Yes. So one of my approach that I really like is actually going through the process and then asking Claude to save it as a skill. This way, I don't need to start from a blank sheet of a skill MD. This way, I can make sure it's actually how I want things to happen so we're having a conversation. Sometimes Claude will give me options. It's like, "Did you mean this or did you mean that? Could you clarify?" And similar to speaking with the very thoughtful human, if you think about it for a second, it's really think about edge cases and so on.
Not everything, not all the time that makes mistakes and sometimes like, no, we lost track of where we were and what I really wanted to happen. But after we do that, we have a session and then I can say, "Hey, save everything you just learned into a skill and let's added that skill to make sure it actually captures what expected". And this has proven itself because now we're able to stock skills and create a repository of skills across the team and across the company where people can take advantage of wanting each other knowledge essentially and it helps us create better software because then we can use multiple skills.
Context Switching, Distraction, and Agent Assistance [13:29]
Adi Polak: So when I'm entering a session, a coding session, for example, I can say, "Here's my skills repository, but I'm not loading everything to my context yet". And this is a very important point here. I don't want to load everything to my context, but I do want to have the knowledge of what exists there. So it should be searchable. I want to be able to track it. I want to know what's the level of quality that I have for that skill as well. So if we can maintain that, that's really good. And then I can decide for a specific session, for a specific task that we want to operate on is what's the right context to bring? Because LLM, if we are overwhelming it with too large of a context, it's going to make more mistakes and it's going to cost more because at the end of the day, what happens, the mechanics of things, it's just concatenating everything for every command, right?
So it's a string concatenation behind the scenes for the most parts, right? Maybe there are more sophisticated ways to go about that the big companies are implementing, but at the end of the day, that's it. And so we want to be smart about what the context that we're bringing. We want to be smart about how we're managing that and not overwhelm the system if we can.
Developer Experience → Agent Experience [14:48]
Thomas Betts: Yes. I like the idea of having the skills library. It's not, I have to load up all of these things I know how to do, but I know I can go and look at this list that says, "Here are the things that I know how to do and look through those skills and realize, okay, I need that one. Now go look it up". I'm old enough that I used to have books on a shelf that had very useful reference before you could just find everything on Stack Overflow or ask whatever your LLM tool is and you turn to the index and say, "I'm looking for this. " And you'd find some sample bit of code and you're like, "Okay, how do I take this generic example and use it in my specific case? I can apply the idea that they're showing in this book or I find an article online and I apply it".
Now we've got software that does that. We almost need to start thinking of those same ways. How would I as a human store this reference material that I know how to do? Where would I go look it up? It gets back to the idea that when you use these as just a one-shot prompt, I can ask it anything and it's going to be something, the quality is not going to be that good. If you start using the product better, using the tools better and using those techniques, no one was expected to know everything that's on the internet. I didn't know everything was in those books, I would go look them up. So set up the tools to be successful by saying, "Here, go look these things up and building that into our systems". That just seems like a different way of thinking about software than we've really had to address before.
Adi Polak: Yes. If you think about it for a second, we're moving from a world of the developer experience, the DevEx world into an agent experience, like, how do I expose... Me as a developer, I love books, I wrote books, I want to go there and read and learn and use it as reference. But I know this is today with the tools that I have, there are better options for me out there, but my agents now need access to it. So now I wanted to know about this great tool that just came out or I wanted to know about utility tool that we developed in house that I want to use.
We still care a lot about developer experience and flow state and giving people the right tools to be successful and productive. And we're also adding the agentic experience. How do we build the workflows and the systems and how do we build those sometimes multi-agent systems that goes across our development life cycle, the SDLC and CI/CD and what's happening in production and so on to really be successful with that.
And those tools needs context and they're often stateful. So there's a lot of things that goes into it, but the first step is we need context and we need to move from a stateless kind of like the chatbot era to a stateful and agentic approach.
Short‑Term vs. Long‑Term Memory in Agent Systems [17:44]
Thomas Betts: And that's talking about sort of long-term memory. I'm going to start this process and it's not, I'm going to finish this immediately and I'm done and I die and I start up a new process and I run it and it's done. That's the stateless thing you're talking about. You're talking about stateful. I might have an agent that's doing a business process over days and it's going to pick up different pieces of that. Or going to your multi-agent scenario, I like the idea of the orchestrator agent having all these different subagents. How do you manage the memory between all of those things? Do they all need to know everything that's going on or is there some techniques you know to break up the context and say, solve this problem with what you need to know and here's the bigger picture so you give a better answer?
Adi Polak: It very much depends on the workflow that I'm building. So we always think about short-term memory and long-term memory. These are always things that we want to know. It's like, what do I need to know that I need to pull in? It's like a Very high latency, I need it right now and I can forget it about it later. It's only for this specific task or only for this specific subtask even. So it's not even a full task. And then there are different techniques where we can maintain that context throughout the longer session like summarization and thinking about the hierarchy of that context.
I think sometimes the model will tell me, "Hey, I'm working with Python, but then I'll kick it off again". And now it's like, okay, now we're switching to MCP servers and maybe you're a JavaScript developer suddenly and you find yourself with different scripts from different programming language. So we don't want that and we want this context to be already with the session. Now, depending on what we're building, depending on what our needs are, it could also be that we need a long-term memory. So a long-term memory, it's more about overall what exists in my system, what do you call a durable knowledge of where we're operating in that space.
And this is where things like skills also becomes really, really important. And also maybe we want to start looking at things like RAG, kind of like bringing that information from databases or other data system that existed and retrieving that information and augmenting it where we need. Now this is more of a long-term context, long-term memory, it's also an important pillar. So I have my short what's exist in my session, and then I have my long-term, I need to always keep it up to date, have a different, maybe a data pipeline, maybe an ML pipeline. Names are a little bit changing these days, but I do know that I need that to exist.
RAG as One Tool Among Many fo Multi-Agent Workflows [20:30]
Thomas Betts: Well, and I'm glad you brought up RAG because a year ago that was the thing everyone was latching onto. You got to have RAG, you got to have RAG. It's the fastest, easiest way to just get a better result. And now RAG is just one more tool in the toolbox. But it seems like if you're working on the agentic workflow, now it's not like, oh, always go look up this one source that I have a RAG model for. It's when I need to get there, go and find the relevant answers, bring that into, again, this context of this task I'm trying to solve, we had that idea, but it was still, again, a year ago as the ancient past, that was the stateless model almost. It was like, go call RAG, come back, but now I want to have this more stateful solution where one step of the process went out and looked and found that information, brought that in, and then the results of that get passed off to another smaller agent that does something else with it, right?
Is that kind of how you're envisioning these things fitting together into a multi-agent model?
Adi Polak: Yes. And I think it very much depends on what's the workflows that we're building. If we're building workflows for engineering, sometimes that will look different because now we're looking at pure enablement that are based on skills and writing software and our knowledge and experiences and so on. And reaching the model with that thought in mind usually means that we have new skills of how we're going to do things. We have best practices, we have design patterns that we want the model to follow, we have a testing suite. I have my doctor agent that test things for me. So I wake up in the morning and I run it and I make sure some of the tickets and everything is operating as I expect it to operate. Now this is 100% productivity tool. Now there's a whole other world of BI, like the business intelligence part where we want to enrich existing data and we want to create better SQL that are based on new tables that we have in there.
Now, it could be that we work at a large company. Usually when we have large companies, we have silos of data in places and I want to be able to retrieve and I want to be able to search what happened there, even if I don't necessarily know the exact name of the tables.
So this is where things like RAG can help and reach my queries and reach my SQL and expand beyond what I know right now can really help because this is what it was built for. There is a good indexed database sitting somewhere where we can do that retrieval based on semantics that we have. Now the semantics is really important because the idea is we don't know exactly what we're searching and when we don't know exactly what we're searching, we want to be able to use whatever language we're using and the model will try to give us a couple of ideas of, "Oh, this table exists over there". I just pulled it out of my catalog. It's a new table. They just created that yesterday, but it's already populated with the latest data. Would you be interested in looking into it? Would that make sense for the business question that you're asking?
Now this is a whole different workflow than using AI for improving productivity as engineers.
Event‑Driven Architectures with Kafka & Flink [23:56]
Thomas Betts: Yes. That discoverability problem is always out there. If you don't go out there and look for new things, how do you know the new things are coming out? And so we can have different tools that are constantly watching for that and letting us know. I know that you, since you work at Confluent, you're familiar with Apache Kafka, Apache Flink. Where do those products fit into an Agentic architecture? I know a lot of people are out there using them and wondering what are the benefits that those provide if I'm building some of my workflows on top of those tools and what are some of the things that you're hoping that Teams will start adopting if they aren't familiar with?
Adi Polak: Yes. So there's one thing that companies are already adopting and they shared it in some of the largest stages and some of Kafka Summit and conferences that we have around the world around data streaming. So one of them, for example, is OpenAI. They have a very large Kafka cluster as well as Flink. And for them, everything that they do with the models that people interact with them in real time, they build it through event-driven architecture. So behind the scenes, you have Kafka that operates for those, transferring those events in real time, very, very low latency. And then they have Flink for enrichment, summarization, real-time analytics. On top of those, in order to improve and give back to the model more context, and I talked about before about the models today are already taking steps on their own. As we talked about prompt engineering, we touched on the fact that we have chain of thoughts, and that chain of thought is essentially you can think about as event-driven pattern.
One of those, probably we can define it as a new pattern, and it becomes the infrastructure for when we want to build these type of solutions. So even in house, when we're thinking about how we build workflows to support some of the engineering work, right? Maybe we don't need a huge Flink cluster, but it definitely helps to think event driven on these things like what triggers what, especially for processes and workflows that are related to maybe our ticketing system, maybe related to code quality that we have agents running over code and suggesting new tickets of how we can do better. Maybe agents that are picking up tickets and already giving us ideas for solutions with code and just waiting for our developer to actually approve those. And because we started to see more companies curious about that, we actually developed some what we call Flink Streaming Agents API and the open source data.
And for anyone who wants to use it, try it, contribute to it, it's available as part of the Flink repository.
Automating Backlogs and Engineering Workflows [26:42]
Thomas Betts: I like the idea of those event-driven workflows becoming more of the agentic processing as opposed to, I'm going to start a process, then these things happen, I can have stuff working in the background, and then those agents are responding to it. And I can see a lot of ... Again, it's a different paradigm you have to think about as opposed to do this work. It's like, when this happens, start that. You mentioned software to SDLC stuff, CICD pipelines. I check in a commit, kick off a pull request or run this process and check, did I have any IP going out? Or all those different things can happen, and having that loop into just the bigger context model. Is that what you were talking about Flink is for enriching the data? So Kafka is this event happened, then Flink comes in and says, "Because that happened and I also saw these other things happen, here's the bigger picture". Am I understanding that correctly or is there a better way to explain that?
Adi Polak: This is one example. The example I had in mind is more of we have an endless backlog of Jira tickets, or not Jira, whatever your favorite system for tickets. And this endless backlog needs to be triaged, sorted, organized, and enriched with more information from our internal architecture docs, prioritization that comes from product, from customers and so on. So these are different systems. So imagine that you have a daily routine that runs in agents that go there and summarize that for you, prioritize that for you. And for the simple things, even suggest coding solution, even creates a pull request and opens a pull request for a developer to take action on. This is where we have the multi-agent process kicking in and improving some of the engineering processes, especially giving many companies who have a huge backlog. We never get to the bottom of the features backlog.
And there's always small things that we need to update related to maintenance or related to migration especially that we know we need to do. No, it's not a priority because the customer didn't ask for them specifically, but maybe if an LLM could pick it up and suggest a solution, we can execute faster on reviewing rather than taking the tickets and doing it ourselves. So these are some of the things that we're building and helping engineers do more meaningful work as well.
Looking Ahead: Creativity as the Core Skill [29:13]
Thomas Betts: Well, I always like to wrap up our conversations with a look towards the future. And the thing is with AI, I feel like I can't ask, what do you see one to three years down the road? So maybe it's just six months from now or within the next year. How do you think people will be designing, architecting and building software systems differently, specifically around talking about context engineering?
Adi Polak: Yes. I don't know how things are going to change and what would be the best solutions for us. The only thing I can say is if people listening in the house have the opportunity to try new things, bring new ideas, use their creativity. We always say if you can dream it, you can do it, you can build it. I truly believe with the tools that we have today, if you can dream it, you can do it and you can execute it much faster than we could have had years back. I don't know how things will change. I don't know where we'll be, but if you're curious, if you want to stay up to date in this industry, if you want to continue building, your creativity is the most important skill right now, use it, do it, go for it.
Thomas Betts: Yes. Just keep trying it and don't think that, "Oh, I haven't used it in six months". It's probably changed quite a bit since the last time you tried it out. So try something again. You'll probably get a much different result. Well, I think that's about time. Adi Polak, thanks again for joining me today.
Adi Polak: Thomas, thank you so much for having me. It's always a pleasure catching up.
Thomas Betts: And listeners, we hope you'll join us again soon for another episode of the InfoQ Podcast.
You can keep up-to-date with the podcasts via our RSS Feed, and they are available via
SoundCloud,
Apple Podcasts,
Spotify,
Overcast
and YouTube.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
関連記事
低品質な強化学習環境の提供を止める方法（事例付き）
ジェミニで強化学習を担当したオーリエル・W氏が、大手ラボが抱える課題としてデータ品質の重要性やドメイン専門家の欠如などを指摘し、高品質な学習環境の構築方法を解説している。
[AINews] 今日は何も大きな出来事はありませんでした
Anthropic が RSI の兆候を示し、OpenAI の ChatGPT が月間アクティブユーザー数で 10 億人を突破。SpaceX AI は IPO について説明しているが、最も重要なのは AIE WF のチケット確保とイベント参加である。
ロシアのプロパガンダに抵抗する能力において最も優れた大規模言語モデルとは
エストニア言語研究所は、外国の敵対国が推進する危険なプロパガンダを拡散する懸念に対応するため、大規模言語モデルがロシア連邦の戦略的トピックに対して立場を取らない能力を評価する「プロパガンダ抵抗」ベンチマークを発表した。