스크립트
00:00:00皆さん、聞こえますか?よかった。持ち時間は20分と短いですので、早速
00:00:20本題に入りたいと思います。Reductoの共同創業者兼CEOのディートです。今日は
00:00:25現実世界で実際に機能するエージェントの構築において、非常に実用的でありながら、あまり目立たない要素である「データ」についてお話ししたいと思います。今日もデータに関するセッションをたくさんご覧になったことでしょう。私たちは主に、非構造化画像やPDF、表計算シートなど、人間が日常的に扱っている最も難解なデータソースを扱う方々のためのインフラ構築に注力してきました。すでにReductoを使ったり試したりした方はいますか?ありがとうございます。
00:00:55前提としてお伝えしておくと、当社はエージェント型ドキュメント処理プラットフォームを提供しています。世界をリードする多くのAIチームが、目的に応じてAIアプリケーションやワークフローを構築するのを支援しています。
00:01:08顧客には、皆さんもよくご存じのHarveyやLigor、RogoといったAIネイティブ企業だけでなく、世界最大級の大企業も含まれています。これは今日お話しする内容にとって重要な前提となります。
00:01:19当社は大手IT企業、グローバル金融機関、保険会社などと連携しています。こうした組織は数十年分の過去データを保有していますが、従来はデモの域を超えて活用することが非常に困難でした。
00:01:34これまでに、あらゆる企業にわたって何拾億枚ものドキュメントを処理してきました。末尾の「+」記号はずっと付けっぱなしですが、数値が更新され続けているため、この表記のままにしています。
00:01:46しかし、それらの経験を通じて得た最も重要な学びであり、今日重点的にお話ししたいのは、Reductoの製品そのものではありません。
00:01:51私たちが得た知見の細部であり、皆さんがご自身の取り組みに持ち帰って実践できる内容です。
00:01:58私たちがこれまで行ってきた取り組みや学びの多くは、AIアプリケーションの適用範囲が近年大きく変化したという、より広い文脈に基づいています。
00:02:07単なる情報要約プロダクトから、実際に業務をこなすエージェントへと変化したのです。
00:02:13それに伴い、議論する価値のある点がいくつか見つかりました。
00:02:161つ目は、課題自体の捉え方です。Twitterで大量のPDF処理サービスのリリースを見かけるものの、人々が直面するボトルネックや、なぜ特にPDFが難しいのかという点です。
00:02:26また、各種ツールごとの強みと弱みについても説明します。
00:02:31従来のコンピュータビジョンとVLM(視覚言語モデル)には、それぞれ適材適所が存在すると考えています。
00:02:35そしてさらに興味深い点として、本セッションの後半では次なるフロンティアに焦点を当てます。
00:02:40ループ内にエージェントを組み込むことで何が可能になったのか。
00:02:43さまざまなタスク用ハーネスを活用した結果、判明したことです。
00:02:47そして、RAGからエージェントプロダクトの構築へ移行する際の評価(Eval)に関する学びについてです。
00:02:53ですが、まずは最初の点から始めましょう。これは皆さんも耳にタコができるほど聞いた話だと思います。
00:02:58数年前にAI Engineerカンファレンスに参加したなら、どのセッションでも「RAG」という言葉を聞いたはずです。
00:03:04誰もが何かしらのRAGアプリケーションを開発していました。
00:03:07一時期、あらゆるアプリは実質的に何らかの形での情報要約でしたよね?
00:03:12完璧なプロンプトやユーザーがアップロードしたファイルなど、特定のコンテキストから情報を抽出していました。
00:03:19そして、検索プロダクトのようなものを構築していました。
00:03:22企業内検索や、
00:03:23コンテンツに基づいて単純な質疑応答を行うチャットボットなどです。
00:03:27それだけでした。
00:03:28しかし今日、何度も耳にするバズワードは「エージェント」です。
00:03:34エンジニアの皆さんなら、Claude Codeなどのツールに多くのエンドツーエンド作業を任せているのではないでしょうか。
00:03:41そして、これと同様のシフトが、あらゆるホワイトカラー業務で起き始めています。
00:03:46金融、保険、医療など、どの分野でもAIが自律的な判断をし始めています。
00:03:51単にPDFからの質問に答えるだけでなく、PDFの生成や修正まで含む、エンドツーエンドの成果物を作ろうとしているのです。
00:03:58これは全く異なるフレームワークです。
00:04:00単なる情報検索プラットフォームの構築と比べ、必要なツールも直面する課題も大きく変わります。
00:04:06そして、これらすべてに共通する核心は、こうしたマルチステップのパイプラインを扱う際、解決すべき課題がさらに重要になるということです。
00:04:18単なる一問一答であれば、質問に答えること自体に伴うリスクは当然存在します。
00:04:24しかし、エージェントが複数のファイル群に基づいて連鎖的な決定を下し、複数のデータソースを取り込む場合、不良インプットのリスクがパイプライン全体に及ぶことになります。
00:04:36それこそが、私たちが注力している部分です。
00:04:38結局のところ、現実世界における言語モデルツールの価値の多くは、その知性をどのようなコンテキスト(文脈)に適用するかによってのみ生きてくるからです。
00:04:48多くの企業において、データは構造化されておらず、散在しており、マルチモーダルです。
00:04:53きれいに整理されたリポジトリなどではありません。
00:04:56さまざまなチームや部署が、Google ドライブや Box など、思い思いの場所にデータを保存しています。
00:05:04データフォーマットはデフォルトで非構造化されています。
00:05:07情報コーパスの中に何が含まれているか、必ずしも把握できているわけではありません。
00:05:11そして、それに伴うあらゆるダウンストリームの問題が発生します。
00:05:14問題の一部はパースや抽出の精度であり、これは間違いなく重要です。
00:05:18しかし、適切なコンテキストを検索できているかという問題もあります。
00:05:22また、そのコンテキストとどう対話し、修正を加えるかという問題でもあります。
00:05:27そして、Reductoやこの分野の他の人々もしつこく強調しているのが、PDFは驚くほど依然として非常に難解な問題であるということです。
00:05:36基盤モデル企業と多く協業しているデータラボ、Surgeをご存じでしょうか。
00:05:42彼らは「GDP PDF」という素晴らしいベンチマークを出していますが、最先端モデルの知性をもってしても正解率は30%程度にとどまります。
00:05:52そしてこれは完全に、「モデルがPDFのような文書に含まれる内容を精査し、正しく判断を下せるか」という発想に基づいています。
00:06:01PDFが難しい理由は(ベンチマークの話は後ほど戻りますが)、根本的にファイル形式として非常に古い上、まったく異なる文脈で設計されたからです。
00:06:11私が生まれるよりも前からPDF処理に携わっているような人たちにも出会ったことがあります。
00:06:161990年代初頭に、PDF印刷用プリンタードライバーの開発を行っていた人々です。
00:06:21当時はそれが目的でした。
00:06:22作成時のドキュメントを忠実に再現し、最終的に印刷できるようにすることが求められていたのです。
00:06:30しかし、今日の懸念事項の多くはそこにはありません。
00:06:33最終的に私たちが求めているのは、Markdownのような表現であり、エージェントが効果的に推論できる形式です。
00:06:39現実世界において 人間は視覚的に多くの文脈を読み取っています
00:06:44投資銀行に就職したばかりの一般的なアナリストは AIエージェントが資料を解析できるかなど考えません
00:06:54彼らは非常にクリエイティブなスライドを作成します
00:06:57金の卵を産むガチョウが描かれたソフトバンクのスライドを見たことがあるでしょう
00:07:01そういった詳細が重要になるのです
00:07:02ですよね?
00:07:03解析対象となるデータの多くは 綺麗な罫線がなくセルが結合された表構造だったりします
00:07:10折れ線グラフや図表もありますし
00:07:12人間である私でさえ読みにくいような 乱雑な手書き文字もあります
00:07:17そうしたロングテールな課題に対応する場合 解決しなければならないのがこの問題です
00:07:22この分野で大きな質的転換が可能だと感じ 2023年に当社を立ち上げました
00:07:29しばらくの間 PDF処理といえば 自然言語処理(NLP)パイプラインの改変版が一般的でした
00:07:37簡単なOCR処理を行った後 そのテキストを後処理しようとする手法です
00:07:41レイアウトが常に一貫している場合は それでも機能しました
00:07:44そうですよね?
00:07:45W-2(源泉徴収票)の形式が決まっていれば テンプレートで対処できる限られた範囲の問題です
00:07:51しかし視覚言語モデル(VLM)は 本質的に汎用的であるため非常に興味深いのです
00:07:56「人間と同じように文書を読み取る」という前提が 初めて成り立つのです
00:08:01「ロングテールな事例に対応する」という前提も可能になります
00:08:04従来のOCRでは不可能だった手書き文字などの処理において VLMは素晴らしい力を発揮しました
00:08:12しかし一方で VLMが万能なソリューションだとは考えていません
00:08:16大規模にこの問題を解決しようとするなら 数億枚の文書を扱う企業であれば
00:08:21決定性など 考慮すべき二次的な要素が数多く存在します
00:08:25処理効率も非常に重視されるポイントです
00:08:27そのため 従来のコンピュータビジョン(CV)が今でも非常に強力な場面があります
00:08:33自動運転技術の研究が進む中で この点は見落とされがちでした
00:08:37物体検出のような技術は 10年前よりもはるかに洗練されています
00:08:421億パラメータ未満のモデルでも 文書のレイアウト検出には非常に効果的です
00:08:48大型の基幹モデルを使わなくても 十分に高度な処理が可能です
00:08:52しかもこれらのモデルはCPU上で動作させることができます
00:08:54大規模に運用することも可能です
00:08:55領域単位で どこが処理の難所であるかを把握できるのです
00:09:00そしてVLMは「意味理解」という概念をもたらします
00:09:03パイプライン内で発生しがちなエラーを特定し 修正することができるのです
00:09:09この「意味理解」の考え方に基づき 問題を分解して複雑な部分を把握できれば
00:09:18ページ内のテキストを分割し 手書き部分の位置を認識することで
00:09:21「エージェント・イン・ザ・ループ」という概念を導入できます
00:09:25従来は人間のレビューチームがエラーを確認・修正していましたが
00:09:29VLMにより「エージェンティックOCR」というアプローチが可能になります
00:09:33具体的には IDE上で高速にコード編集を行うCursorのようなツールを想像してください
00:09:41出力に対してトークン単位で修正を適用する投機的デコーディングの概念があります
00:09:45これと同様の原則を適応できます 単にGeminiにOCR結果を送信し
00:09:51綺麗なプロンプトを書いて 原文から逸脱しないよう丁寧にお願いするだけではありません
00:09:56なぜなら そのような「次のトークン予測」を行うと
00:09:58非常に知能の高いモデルであっても 新たな損失パターンを生み出し
00:10:02原文に忠実ではない修正を始めてしまうことがあるからです
00:10:05例えば「合計」という文字があり 人間が表の中で計算ミスをしていた場合
00:10:08モデルが勝手に表の数値を足し算して修正してしまうことがあります
00:10:13本当に必要なのは 目的のトークンレベルでの修正だけです
00:10:16ピリオドとカンマの誤りや 数字の0と英字のOの誤認など
00:10:19そうした極めて細かい部分が非常に重要なのです
00:10:21これは「人間がその文書を読んだときにどう見えたか」を
00:10:25いかに正確に表現するかという課題です
00:10:27私たちが考えるエージェンティックOCRは 「ヒューマン・イン・ザ・ループ」の類推に近く
00:10:34最初の入力はCVとVLMによる解析を通し
00:10:39検証・修正レイヤーを経ることで 最終的に高い信頼性の出力を得ます
00:10:44しかし先ほど述べたように 課題は単なる構文解析や抽出にとどまりません
00:10:50優れた文書変換パイプラインを持っていたとしても
00:10:56パイプラインの詳細まで精査することが重要になります
00:10:59絶好の例として RAGプラットフォームを構築したことがあるなら
00:11:04表などの扱いについて 何らかの検討を行った経験があるはずです
00:11:07Markdownのような形式でも、うまく符号化できるものは多くあります。
00:11:13ですが、結合セルに大きな意味が含まれているこのような表では、
00:11:18そうした構造を保持することが重要になります。
00:11:20これはモデルの限界によるものではありません。
00:11:22LLMは、同じ表のHTML構造などを推理するのに非常に優れています。
00:11:26ですが、大量のトークンを消費するため、コストが急速に膨らみます。
00:11:29かといって、逆の極端な例として、
00:11:31シンプルな表までいちいちHTMLで符号化したくはないでしょう。
00:11:35無駄なHTMLタグが大量に発生してしまうからです。
00:11:38そこで私たちが取ったアプローチは、これを動的な問題として捉えることでした。
00:11:42シンプルな表であれば、Markdownでデータを近似すれば十分です。
00:11:47より複雑な表であれば、HTMLのような形式を使いたくなるかもしれません。
00:11:50しかし、パイプラインで考慮すべきなのは言語モデルだけではありません。
00:11:55エンベディングに関連する処理を行う場合は、
00:11:57文脈の検索(Retrieval)という二次的な問題も生じます。
00:12:01先ほどお見せした表ですが、
00:12:03HTML表現で見ると非常にごちゃごちゃしています。
00:12:08スニペットの大半は単なるHTMLタグであり、
00:12:11ドキュメントの構造を分類しているに過ぎません。
00:12:14残念なことに、一般的なベンチマーク評価であれば、
00:12:17モデルの手助けをして探しているものをピンポイントで示すような
00:12:22コンテンツが存在するかもしれませんが、
00:12:24現実の人間は表の中の数値をいちいち列挙したりしません。
00:12:28単に「売上は時間経過でどう変化したか?」と質問し、
00:12:30適切な表が必要に応じて検索されるものだと前提しています。
00:12:34言語モデルはそのテキストを効果的に推理できますが、
00:12:37大規模なコーパスから抽出する場合、
00:12:39エンベディングモデルは人間の自然言語プロンプトと
00:12:44HTMLタグと数値が混ざった複雑なデータ群を関連付けるのに苦戦します。
00:12:47そのため、わずかな手間で大きな効果を得られる非常に有効な手段は、
00:12:51エンベディングモデル自体に最適化した表現を作成することです。
00:12:55同じ表を取り上げ、
00:12:56その表の自然言語による表現を作成することで、
00:12:58両方の良さを享受できるようになります。
00:13:00推理のためにモデルへ実際に渡す際には
00:13:02HTML形式の表表現を使用し、
00:13:04適切なスニペットを確実に検索したい時には
00:13:07その自然言語ブロックを使用するのです。
00:13:12さらに、パースや抽出にとどまらない取り組むべき課題が数多く存在します。
00:13:18業界の関心は歴史的にパースや抽出に集中してきましたが、
00:13:22そこには大きな改善の余地があると考えているからです。
00:13:25先ほどGDP PDFベンチマークについて触れましたが、
00:13:30データパイプラインを向上させた結果として
00:13:34得られる成果を解りやすく示す好例だと思います。
00:13:37分かったのは、前述と同じベンチマークを使用した場合——
00:13:40残念ながらアクセスが切断されたため
00:13:43Fableでテストすることはできませんでしたが——
00:13:46他のモデルでテストし、元のPDFと
00:13:50ここにあるパース結果のような構造化表現の両方を与えると、
00:13:52モデルの種類を問わず、
00:13:55GeminiでもAnthropicでもOpenAIでも、
00:13:58入力を改善するだけで最終的なLLMの性能が向上するということです。
00:14:04その効果は非常に顕著で、GPT 5.5やOpusといったモデルは
00:14:09標準状態のFableなどを凌駕するほどです。
00:14:12精度面だけでなく、より良い入力を提供した結果、
00:14:17モデルが消費する推理トークン数も削減されます。
00:14:20データの表現に割くリソースが減り、実際の出力に集中できるからです。
00:14:24結果として、レイテンシが低下し、
00:14:27より迅速に正解にたどり着くことができます。
00:14:30しかし、そうしたパイプラインを構築し、
00:14:33パース層のすべてを精査し終えたとしても、
00:14:37人間が行う作業の多くは、
00:14:41コーパス内にあるデータの全容を正確に把握し、
00:14:44それを適切なパイプラインへルーティングして問題を分解したり、
00:14:48最終的にドキュメントを編集・修正したりすることを必要とします。
00:14:51そこで私たちが試みたのは、言語モデルとドキュメントの
00:14:54あらゆるやり取りを、人間が行うのと同じくらい効果的に
00:14:57行うにはどうすべきか、という問題として捉えることでした。
00:15:00フォームに入力する場合、フィールドの入力箇所の精度を
00:15:03どのようにして担保するかという問題です。
00:15:05オーケストレーション側における非常に良い例として、
00:15:08分類と分割は、LLMに最高のパフォーマンスを発揮させるための
00:15:12見落とされがちですが重要な手法だと思います。
00:15:14もちろん、大量の文脈をただ流し込むことも可能です。
00:15:17「干し草の山の針」のようなテストを行うのであれば、
00:15:19それでも問題ないかもしれません。
00:15:20しかし実際には、過剰な情報を渡すことで、
00:15:24トークンコストの問題だけでなく精度の低下も見られます。
00:15:28代わりに、適切なドキュメントを適切なパイプラインへ
00:15:33どのように分類するかといったことを熟考することで、
00:15:36大きな改善の余地が得られることが分かっています。
00:15:38また、大きなドキュメントであっても、実際に適切な
00:15:41スニペットのみを渡すにはどうすればよいかという点も重要です。
00:15:43例えば紙の郵便物のようなユースケースでは、
00:15:47送られてくる書類束が数百ページに及ぶこともあります。
00:15:50その中に何が含まれているか、事前に把握するのは困難です。
00:15:53ページ順が混ざっているといった問題が発生することもあり、
00:15:57そうした整理作業をモデルにさせようとすると、
00:16:01本来達成したい目的——
00:16:03郵便物からのデータ抽出、その分析、
00:16:05あるいは意思決定といった作業の妨げになります。
00:16:10先ほど後半の部分について触れましたが、
00:16:13そちらの方がより興味深い要素だと考えています。
00:16:16初期の分類と分割の層が整い、
00:16:20整理の手順が確立された後の話です。
00:16:22チームとして非常に期待を寄せているのは、
00:16:26エージェントのハーネスが、これまで難解な未解決問題と
00:16:29されてきた壁を突破する強力なフロンティアになっている点です。
00:16:34すぐに取り上げる具体例の一つに、
00:16:37折れ線グラフのようなものがあります。
00:16:39私たちは世界最大級のヘッジファンドの多くと協力していますが、
00:16:41折れ線グラフのようなデータは歴史的に非常に困難でした。
00:16:43第一に画像フォーマットであること、
00:16:46第二に、従来のビジョンエンコーダーを使用すると
00:16:49見落とされてしまうようなピクセルレベルの細かさが
00:16:52多数存在するからです。
00:16:53売上の推移といった大まかな傾向は捉えられても、
00:16:55個々のデータポイントまで読み取ることはできません。
00:16:57そのため私たちは、特定のタイプの問題を解決するために
00:17:00適切なツールをエージェントに持たせる方法を検討してきました。
00:17:04グラフ抽出の例では、
00:17:05左側のグラフには非常に膨大なデータテーブルが含まれています。
00:17:09すべてのピクセルを手作業でプロットしようとすれば
00:17:11極めて困難な作業になります。
00:17:14また、モデルにとっても
00:17:16線の間の複雑な形状を近似することすら容易ではありません。
00:17:19一発の処理(シングルショット)でこれを完遂できる
00:17:22標準モデルは存在しません。
00:17:24右側に表示されているのは、
00:17:25元となった折れ線グラフから生成することができた
00:17:28Markdownテーブルの再構成結果です。
00:17:30元の折れ線グラフから生成したものです。
00:17:32そして、そこにたどり着くための唯一の方法が
00:17:34あらゆるツールを持ったエージェントを使うことでした。
00:17:36専用のコード インタープリターを備えており、
00:17:37自身が生成しているチャートを視覚化する機能もあります。
00:17:40そして、それを繰り返し実行します。
00:17:41折れ線グラフのエラーを何度も何度も繰り返し見つけていき、
00:17:45最終的な出力にたどり着くことができるのです。
00:17:47これは、構造化抽出のような問題にも当てはまります。
00:17:51これまでしばらくの間、ドキュメントから
00:17:53構造化出力への変換機能がありましたが、
00:17:55同じようなタスクの周囲にエージェントのハーネスを
00:17:57構築することで、さらに一歩進めることができます。
00:18:00親エージェントにサブエージェントが従うべき検証基準を設定させ、
00:18:03処理を実行させることができます。
00:18:05これにより、何万ものフィールドを持つCBPフォームのようなものがある場合、
00:18:09数万ものフィールドを持つフォームにおいて、
00:18:11自然と発生する多くの問題に直面することになります。
00:18:13例えば、コンテンツや行が脱落するなどです。
00:18:15そして今朝、MicroOneがこの分野で非常に優れた
00:18:17ベンチマークをリリースしました。
00:18:20そこでは、市場に二極化が見られることが示されています。
00:18:23市場には二極化が存在します。
00:18:24最大の推論能力を持つフロンティアモデルは非常に正確です。
00:18:28行が抽出されさえすれば、
00:18:30それがハルシネーションによる行である可能性は低く、
00:18:31実際に正しく取得できています。
00:18:33しかし、ベンチマーク全体では多くのコンテンツが暗黙的に脱落します。
00:18:37リコール(網羅率)には非常に苦戦しています。
00:18:39その一方で、多くの専用ドキュメント処理サービスは、
00:18:42精度の観点からはフロンティアモデルに劣るものの、
00:18:46リコールの観点ではその差を埋めています。
00:18:48このように、常に一定のトレードオフが存在していました。
00:18:51そして、この種のタスクにおいて精度とリコールの両方の
00:18:54局所的最適解を見つけることができたのは、
00:18:57エージェントハーネスを用いた場合においてのみでした。
00:19:00最後の、そしてこの講演で最も重要かもしれないポイントは、
00:19:04結局のところ評価(eval)があらゆる決定の基礎となるべきだということです。
00:19:09すべての決定の根底にあるべきだということです。
00:19:10それは私たちがプロダクトを考える上での大きな要素でもあります。
00:19:12これは、評価に使用する既存のデータセットだけでなく、
00:19:16リアルタイムのプロダクション監視にも当てはまります。
00:19:19本番環境のデータは、用意された人工的なセットにある
00:19:21どのようなデータとも異なるためです。
00:19:25そして、評価を単なるマクロな視点としてだけでなく、
00:19:28単なるマクロレベルの視点として捉えるのではなく、
00:19:30私たちが共に働く優れたチームは、
00:19:33パイプラインの各ステップの粒度で評価を行っています。
00:19:36まず第一に、パイプラインへの入力が
00:19:38良好であることを確認したい場合があるでしょう。
00:19:40もちろん、構文解析パイプラインなども評価すべきです。
00:19:43しかし、どれほど完璧な構文解析であっても、
00:19:47適切なコンテキストが渡されなければ意味がありません。
00:19:50そのため、検索パイプラインや、
00:19:52検索パイプラインなどの詳細について
00:19:54しっかり考えることが重要です。
00:19:56そして最終的に最も重要なのは、
00:19:58エージェントの最終的なパフォーマンスを向上させられるかということです。
00:20:03最後に、私たちがどこに向かっているのか、
00:20:06そして業界がどこに向かっているのかについて触れて締めくくります。
00:20:08最も重要なのは、エージェントがますます優秀になるにつれて、
00:20:12数年前の標準だったような
00:20:15決定的(デテミニスティック)なパイプラインから脱却できるということです。
00:20:17多くの顧客は、実質的にエージェントが移動し探索するための
00:20:20ファイルシステムを作成し、
00:20:22使用したいツールをエージェント自身に決定させています。
00:20:25私たちがCLIを作成することで、ドキュメントが常に1つの特定の花道を辿るような
00:20:28エンドツーエンドのパイプラインを構築する代わりに、
00:20:32特定の種類のドキュメントを読む必要があるかどうかをエージェントが判断し、
00:20:35それを2つのセットに分割します。
00:20:381つはエージェントが必要に応じて読み取れるコンテンツフィールドであり、
00:20:41もう1つは必要となるすべてのメタデータです。
00:20:44引用などの処理を行う場合、バウンディングボックスなどが必要になることがあり、
00:20:47そういった詳細が含まれます。
00:20:50編集に関するこの部分は省略します。
00:20:52この分野では非常に興味深い研究が多く行われていると思います。
00:20:54すでに一部をリリースしていますが、今後数ヶ月の間に、
00:20:57文書生成のようなものにより一層注目していくことになります。
00:21:01本日のまとめとして、お時間をいただいたことに心より感謝いたします。
00:21:041つ目は、構文解析の問題を分解することを強くお勧めします。
00:21:08可能な限り、それぞれのタスクに適したツールを選ぶべきであり、
00:21:11精度、コスト、レイテンシのフロンティア領域に到達できるようにしてください。
00:21:162つ目は、エージェントによる検証は業界にとって久々の大きな変革であり、
00:21:21本番環境で機能するパイプラインを確実に構築するための素晴らしい機会です。
00:21:263つ目は、わずかな労力で、データの消費者向けフォーマットといった詳細から
00:21:31多くの改善の余地(ヘッドルーム)が得られるということです。
00:21:34同様に、データ処理だけでなくデータオーケストレーションについても
00:21:39考えることが非常に重要です。
00:21:41そのため、パイプラインを拡張する手段として、
00:21:44分類や分割といったツールを常に検討すべきです。
00:21:465つ目は、あらゆる段階で評価を確実に実行することです。
00:21:49そして6つ目は、次のフロンティアが自分にとってどのようなものか考えることです。
00:21:52今日の時代の最も成功している企業の多くは、
00:21:562、3年前に行っていたこととは大きく異なるやり方をしているためです。
00:21:59ご質問がございましたら、いつでもお気軽にご連絡ください。
00:22:03メールアドレスは firstname@reducto.ai です。
00:22:06お客様のユースケースでお役に立てることがあれば、ウェブサイトからもお問い合わせいただけます。
00:22:10ご清聴ありがとうございました。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기