Head of a Plataeat ramp.

プラティート・ランプの頭部。

I've been working on LLMs for four years, which is, well, which is a kind of a long time, I guess, in LM land.

私はLLMに4年間携わっているが、これはLMの世界では長い方だと思う。

Everything started happening really when ChatGPD came out.

ChatGPDが登場したとき、すべてが本当に始まったんだ。

So, I was trying to build what people would now call an AI agent company.

だから私は、今でいうAIエージェントの会社を作ろうとしていた。

Back then, we were just doing customer support.

当時はカスタマーサポートをやっていただけだった。

We're trying to make our chatbot smarter, and we're trying to figure out what models to use, or what tech to use to get them to respond to customers better.

私たちはチャットボットをより賢くしようとしていて、どのようなモデルを使うべきか、どのような技術を使えば顧客によりよく対応できるかを考えている。

And we were messing with GPD 2 on support, and models were so frustratingly stupid, and the context windows were small, and they were not very smart reasoning, and it was just incredibly annoying.

サポートでGPD 2をいじっていたんだけど、モデルがバカバカしくてイライラしたし、コンテキストウィンドウは小さいし、あまり賢い推論もできないし、とにかく信じられないほどイライラしたんだ。

And we just wrote lots of code around these models to get them to work, at least somewhat reliably.

そして、少なくともある程度は確実に機能するように、これらのモデルの周りにたくさんのコードを書いた。

And along the way, as models got smarter, this kind of had to delete more of that code.

そして、モデルが賢くなるにつれて、より多くのコードを削除しなければならなくなった。

And this ended up seeing a lot of patterns in what code needs to get deleted, how to build agents in what ways that will scale with more intelligence.

そして、どのコードを削除する必要があるのか、どのような方法でエージェントを構築すれば、より多くのインテリジェンスによって拡張できるのか、多くのパターンが見えてきた。

And clearly, we're going to continue to get a lot more intelligence.

そして明らかに、我々はこれからも多くの情報を入手し続けるだろう。

And I just wanted to maybe talk about a single idea throughout the talk through various examples.

そして、いろいろな例を通して、講演全体を通してひとつのアイデアについて話したかったんだ。

We'll do some setting, but I'll also have a bunch of demos to kind of drive home the point, and maybe I can convince you guys that there's a certain way of building agents that's slightly better than other ways.

セッティングもするつもりだが、デモもたくさん用意して、ポイントを強調し、エージェントの作り方には、他の方法よりも少し優れたものがあることを納得してもらえるかもしれない。

I also built a structure extraction library called JSONformer.

JSONformerという構造抽出ライブラリも作った。

I think it was the first one.

一番最初だったと思う。

I'm not fully sure, but timing-wise, it was before all the other major ones.

完全にはわからないが、タイミング的には他の主要なものよりも前だった。

And that was also scaffolding around a model.

それも、モデルを囲む足場だった。

Models were too stupid to output JSON, and we were just really begging and pleading it, and forcing it to act in ways that we want it to be.

モデルはJSONを出力するにはあまりに愚かで、私たちはただ本当に懇願し、懇願し、私たちが望むように行動するよう強制していた。

So as I said earlier, I just have one core agenda item here, which is I want to convey one idea.

だから、先ほども言ったように、ここには核となる議題がひとつだけある。

We'll start off, all of you probably read the essay a bit or less, and just quickly go through what it is.

まずは、おそらく皆さんも少しはエッセイを読んでいると思うが、その内容をざっと説明しよう。

We'll go through a production agent we have at Ramp, and how it works, and three different ways of architecting it.

ランプが持っているプロダクション・エージェントとその仕組み、そして3つの異なるアーキテクチャー方法について説明する。

And then I have a demo to really push maybe how we all think about how software and backends and things will work in the future.

そして、ソフトウェアやバックエンド、物事が将来どのように機能するかについて、私たち全員がどのように考えるかを本当に後押しするデモがあるんだ。

So very simply, the idea is just that systems that scale to compute beat systems that don't.

つまり、非常に単純に言えば、コンピュート・スケールが大きいシステムは、そうでないシステムに勝るということだ。

So there's two systems, and without any effort, one of the systems can just think more or use more compute in some way.

つまり、2つのシステムがあり、片方のシステムは何の努力もせずに、より多くのことを考えたり、より多くの計算量を使ったりすることができる。

That system tends to beat systems that are rigid and fixed and just deterministic.

そのシステムは、硬直的で固定的でただ決定論的なシステムに勝つ傾向がある。

So from that idea, it's pretty clear, like, if you're building systems, you might as well build systems that improve with more compute.

その考えからすると、システムを構築するのであれば、より多くのコンピュートによって向上するシステムを構築した方がいいというのは明らかだ。

And this seems pretty obvious, like, obvious conclusion from the bitter lesson.

そしてこれは、苦い教訓から明白な結論のように思える。

Taking it a step further, why is this true?

もう一歩踏み込んで、なぜそうなのか。

It's because exponentials are rare.

指数関数が珍しいからだ。

Like, they just don't exist, and most things in the world aren't exponential.

世の中のほとんどのことは指数関数的なものではない。

So when you find one, you just should hop on, strap on, and just take the free pass and go for the ride.

だから、見つけたら飛び乗り、ストラップをつけ、フリーパスで乗りに行くべきだ。

And you probably shouldn't try too hard.

それに、あまり頑張りすぎない方がいい。

And there's a lot of examples from history that kind of reflect this.

歴史上、これを反映した例はたくさんある。

So for chess and Go and computer vision, Atari games, like, people have tried to build lots of systems and written a lot of code.

チェスや囲碁、コンピュータ・ビジョン、アタリ・ゲームなどでは、人々はたくさんのシステムを構築し、たくさんのコードを書いてきた。

And my way of thinking about rigid systems is just, like, spending a lot of time writing weekends and writing very clever software, well-abstracted, maybe trying to synthesize human reasoning and thought process into features and then using them in clever ways and trying to approximate how a human would think.

私の硬直化したシステムについての考え方は、週末に多くの時間を費やして、非常に賢いソフトウェアを書くこと、よく抽象化すること、人間の推論や思考プロセスを機能に合成しようとすること、そしてそれらを賢い方法で使用し、人間がどのように考えるかを近似させようとすることだ。

And if you actually fix the amount of compute, that approach will win.

そして、実際に計算量を固定すれば、そのアプローチが勝つだろう。

But if it just turns out, if you end up scaling up how much search you're doing, the general method always ends up winning, even, like, in all these cases, so Atari, Go, and computer vision.

しかし、もしそれが判明した場合、検索する量をスケールアップすることになれば、アタリ、囲碁、コンピューター・ビジョンなど、すべてのケースにおいて、一般的な方法が常に勝利することになります。

A little bit about RAMP.

RAMPについて少し。

So RAMP is a finance platform that helps businesses manage expenses, payments, procurement, travel, bookkeeping more efficiently.

RAMPは、企業が経費、支払い、調達、出張、記帳をより効率的に管理できるよう支援する財務プラットフォームだ。

And we have a ton of AI across the product, so automate a lot of boring stuff the finance teams do and employees do with submitting expense reports and booking your flights and hotels and submitting reimbursements, all of that.

財務チームや従業員が経費報告書の提出や航空券やホテルの予約、経費精算書の提出など、退屈な作業を自動化することができます。

And so a lot of the work behind the scenes is just we're interacting with other systems and helping, like, legacy systems and helping employees get their work done faster.

裏方の仕事の多くは、他のシステムと相互作用し、レガシー・システムを支援し、従業員がより速く仕事をこなせるようにすることです。

So let's actually talk through one of the systems we have today at RAMP, and maybe some talk through, like, the different versions of the system and how it developed over time.

では実際に、現在RAMPで導入しているシステムの1つについて、また、システムのさまざまなバージョンや、時間の経過とともにどのように発展してきたかについてお話ししましょう。

So we're going to talk about something called a switching report.

そこで今回は、スイッチング・レポートと呼ばれるものについて話をしよう。

It's a very simple agent.

とてもシンプルなエージェントだ。

All it needs to do is take in a CSV, a CSV in arbitrary format, so the schema could be seriously anything from the internet.

必要なのはCSVを取り込むことだけで、CSVは任意のフォーマットなので、スキーマはインターネット上のどんなものでも構わない。

And we want these CSVs to come from third-party card providers.

そして、これらのCSVは、サードパーティーのカード・プロバイダーからのものであってほしい。

So when people onboard to RAMP, we want to give them a nice checklist and say, hey, here are all the transactions you have on other platforms, and we want to help you move them over.

ですから、RAMPに参加される方には、チェックリストをお渡しして、他のプラットフォームで行っている取引をすべてご紹介します。

And the more transactions come on RAMP, the more we can help you, and the more you'll use our software, and the more everyone benefits.

そして、RAMPを利用する取引が増えれば増えるほど、私たちはお客様を支援することができ、お客様が私たちのソフトウェアを利用すればするほど、誰もが利益を得ることができるのです。

And so the switching report is just really a checklist.

つまり、スイッチング・レポートは単なるチェックリストに過ぎないのだ。

But to read people's CSV transactions, we need to understand those, and other platforms have all these kinds of crazy schemas.

しかし、人々のCSVトランザクションを読むためには、それを理解する必要がある。

And so the description of the problem we have here is just for an arbitrary, arbitrary, like, CSV, how can we support parsing it and then into some format that we understand?

つまり、CSVのような任意のフォーマットに対して、どのように解析し、我々が理解できるフォーマットに変換できるかということだ。

So let's just start with the simple approach, right?

では、シンプルなアプローチから始めようか？

It's like, let's just take the 50 most common third-party card vendors, and let's just manually write code for all of them.

最も一般的な50のサードパーティカードベンダーを取り上げ、そのすべてに対応するコードを手作業で書いてみようという感じだ。

Now, obviously, like, this will just work.

今、明らかに、これはうまくいくだろう。

It is some work, not a lot of work, but you still have to maybe go to 50 different platforms and download their CSVs, see what schemas they have, and then write code.

でも、50の異なるプラットフォームに行き、CSVをダウンロードし、どのようなスキーマを持っているかを確認し、コードを書かなければならない。

Maybe if they decide one day they change their format, your thing will break, but that's okay, you'll get paged, and you can wake up and go fix it.

もし彼らがある日、フォーマットを変更すると決めたら、君のものは壊れるかもしれない。でも大丈夫だ。

So let's maybe introduce some LLMs in here.

では、ここにLLMを何人か紹介しよう。

So from the over-engineered code where you ended up writing 100,000 lines, maybe we want a more general system.

だから、10万行も書くことになるような過剰に設計されたコードから、もっと一般的なシステムが欲しいのかもしれない。

So let's introduce a little bit of LLMs, a little bit of AI in here.

では、ここでLLMとAIを少し紹介しよう。

And so in the deterministic flow, let's maybe add some, or just like scripting in classical scripting land, let's add some more calls to OpenAI, or you have an embedding model, you want to do somatic similarity or something like that.

決定論的なフローでは、OpenAIへの呼び出しを追加したり、古典的なスクリプティングのスクリプティングのように、OpenAIへの呼び出しを追加したりします。

So then let's just take every column in the CSV that comes in.

では、送られてきたCSVの列をすべて取り出してみよう。

Let's try to classify what kind of column it is.

どんなコラムか分類してみよう。

Is it a date?

デートですか？

Is it a transaction?

取引ですか？

Is it a transaction amount?

取引額ですか？

Is it a merchant name?

商人の名前ですか？

Or is it the user's name?

それともユーザー名ですか？

And then we map it on, and then we probably could end up in a schema that we're happy with.

そして、それをマッピングし、最終的に満足のいくスキーマに仕上げることができるだろう。

Again, most of the compute is running in classical land.

ここでも、計算のほとんどは古典的な土地で実行されている。

Some of it is running in fuzzy LLM land, but this is somewhat looking like a more general system.

その一部はファジーなLLMの土地で実行されているが、これはやや一般的なシステムのように見える。

Let's go maybe a different approach, and like we just go all the way through.

違うアプローチで、最後までやり通すような感じで行こう。

Let's just say we're just going to literally give the CSV to an LLM and say, you have a code interpreter, so you can write whatever code you want, pandas or all the faster Rust-based ones.

LLMにCSVを渡して、コード・インタプリタがあるから、pandasでもRustベースの高速なものでも、好きなコードを書いていいよ、と言うだけだ。

You have all these Python packages.

これらすべてのPythonパッケージがある。

You're allowed to look at the head of the CSV, the tail, whichever rows you want.

CSVの先頭、末尾、好きな行を見ることができる。

And then I just want you to give me a CSV with this specific format.

そして、この特定のフォーマットのCSVを渡してほしい。

Here's a unit test.

これがユニットテストだ。

Here's a verifier that you can use to tell if it's working or not.

これが、機能しているかどうかを確認するためのベリファイアだ。

Turns out this approach actually doesn't work.

このやり方は実はうまくいかないことがわかった。

Like, we tried it.

試してみたんだ。

If you only run it once.

一度しか実行しないのであれば。

But instead, if you run it 50 times in parallel, it's actually very likely that it works really well and generalizes across a ton of different formats.

しかし、その代わりに50回並行して実行すれば、実にうまく機能し、大量の異なるフォーマットで一般化できる可能性が高い。

The amount of compute here is actually probably like, what is that number?

ここでの計算量は、実際にはおそらく、その数字がいくつなのか？

10,000 times more than the first approach we came up with.

私たちが最初に思いついたアプローチの1万倍以上だ。

But again, like, what is truly scarce in the world is engineer time.

しかし、繰り返すが、世界で本当に不足しているのはエンジニアの時間だ。

Maybe not in a while, but at least today.

しばらくは無理かもしれないが、少なくとも今日は。

And we'd rather have a system that works really well, and even with the 10,000 times more compute, it will probably cost less than a dollar, and every transaction that's switched over, every failed CSV will cost RAMP way more money than whatever money we spend on this exact architecture.

1万倍の計算能力でも、おそらくコストは1ドル以下でしょう。トランザクションが切り替わるたびに、CSVが失敗するたびに、RAMPはこの正確なアーキテクチャにかけるコストよりもはるかに多くのコストをかけることになります。

So this is a very specific example.

だから、これは非常に具体的な例だ。

It's like, how does this apply to the agents that we all build, and maybe the systems we're all working on?

私たち全員が構築しているエージェントや、もしかしたら私たち全員が取り組んでいるシステムに、これがどのように適用されるのかということだ。

Turns out, something like this actually generalizes.

このようなことが実際に一般化することが判明した。

So if you look at the three approaches, and let's assume, like, the black arrow is just classical compute, and then the blue arrows are fuzzy land.

3つのアプローチを見て、黒い矢印が古典的な計算、青い矢印がファジーランドだとしよう。

So it goes into neural net, and all sort of weird matrix multiplication happens, and then we're in latent space, and it gets all alien intelligency, and then comes back to classical land.

それでニューラルネットに入り、奇妙な行列の掛け算が起こり、潜伏空間に入り、エイリアン的な知性を得て、古典的な土地に戻ってくる。

First approach, there was no AI.

最初のアプローチでは、AIは存在しなかった。

We just wrote code, and it just worked, mostly.

私たちはただコードを書いただけで、たいていはうまくいった。

The constrained agent, so the second approach, we broke into fuzzy land from classical land when we decided we wanted similarity scores or something like that.

制約条件付きエージェント、つまり2つ目のアプローチは、類似性スコアか何かが必要だと判断したときに、古典的な土地からファジーな土地に分かれたんだ。

And then the third approach is actually flipped, where the LLM decides it needs to go into classical land.

LLMは古典的な土地に行く必要があると判断する。

So it writes some code, it writes some pandas or Python code, and it decides to break in into this classical land when it needs to, but most of the compute is fuzzy.

パンダやPythonのコードを書いて、必要なときにこの古典的な土地に侵入することにするが、ほとんどの計算はファジーだ。

Actually, this is maybe not the most accurate graph, like, because it proposed that we run it 50 times.

実際、これは最も正確なグラフではないかもしれない。

It more so looks like this.

もっと言えば、こんな感じだ。

But if you look at a back end in general, they're all request response.

しかし、一般的にバックエンドを見れば、それらはすべてリクエスト・レスポンスだ。

So some sort of message is going in.

つまり、何らかのメッセージが入っているということだ。

It's like a POST request, or GET, or UPDATE, or READ, any sort of CRUD operation.

POSTリクエスト、GET、UPDATE、READなど、CRUD操作のようなものだ。

And we're really just asking the back end to take this piece of information, do whatever you must with it, run out whatever mutations you want, and return me a response.

バックエンドには、この情報を受け取って、必要なことを何でもして、好きな突然変異を起こし、私に返事を返すように頼んでいるだけなのだ。

And almost all systems we've built so far is like humanity, I guess, like, look like the first one.

そして、僕らがこれまで作ってきたシステムのほとんどは、人類が最初に作ったようなものなんだ。

But more people are using OpenAI.

しかし、より多くの人々がOpenAIを使っている。

OpenAI makes billions of dollars, and probably a lot of the systems that use them look like number two, where just regular programming languages are calling into OpenAI servers, and we're running some fuzzy compute.

OpenAIは数十億ドルを稼ぎ出し、おそらくそれを使っているシステムの多くは2番のように、通常のプログラミング言語がOpenAIのサーバーに呼び出され、ファジーな計算を実行している。

What we're seeing in, like, more and more parts of the RAM codebase, we're moving to the third approach, because it just tends to work well.

RAMのコードベースの多くの部分で見られるようになったのは、3番目のアプローチに移行していることだ。

Because all the blue arrows, if you did nothing, absolutely nothing, we all went to vacation for the next year, the big labs are still working and spending billions of dollars making those models better.

青い矢印は、もしあなたが何もしなければ、何もしなければ、私たちは翌年休暇に入る。

So the blue arrows will get better.

だから、青い矢印は良くなる。

And so how much blue arrow you're using in your codebase actually will help directly your company without much effort from your end.

そして、コードベースにどれだけ青い矢印を使っているかは、実際に、あなたの側がそれほど努力しなくても、あなたの会社を直接助けることになる。

So this is what I was saying is, like, the bitter lesson is just so powerful, and exponential trends are so powerful, that you can just hitch the ride.

つまり、私が言いたかったのは、苦い教訓はとても強力で、指数関数的なトレンドはとても強力だから、それに乗ればいいということだ。

Let's take this idea, like, further.

この考えを、もっと進めてみよう。

Let's actually, like, go all the way, like something crazy.

実際に、何かクレイジーなことをやってみよう。

On the left, you'll see a traditional web app.

左側には、従来のウェブアプリが表示されている。

So usually the way it works is you open gmail.com, and some static file server at Google is sending you a bunch of JavaScript and HTML and CSS.

通常、gmail.comを開くと、グーグルの静的ファイルサーバーがJavaScriptやHTML、CSSを大量に送ってくる。

The browser renders that and shows you some nice UI, nice HTML that's user-friendly.

ブラウザはそれをレンダリングし、ユーザーフレンドリーな素敵なUI、素敵なHTMLを表示する。

Maybe you see some emails, maybe you click on one of them.

もしかしたら、何通かのメールを目にし、そのうちの1通をクリックするかもしれない。

The frontend makes a request to the backend, the frontend asks the backend, give me the content for Gmail and whatever ID it is, and then the backend has a database and gives you the result.

フロントエンドはバックエンドにリクエストを出し、フロントエンドはバックエンドに、GmailのコンテンツとそれがどんなIDであるかを教えてくれ、と頼む。

And maybe they use CodeGen, maybe they use all the CodeGen tools available to make Gmail.

そして、彼らはCodeGenを使っているのかもしれないし、Gmailを作るために利用可能なすべてのCodeGenツールを使っているのかもしれない。

So that was probably, the LM only worked when the software engineer was writing the code, but once the code is written and it's, like, pushed to production, it's just classical compute.

LMが機能するのは、ソフトウェア・エンジニアがコードを書いているときだけで、コードが書かれ、本番稼動に移されると、それは単なる古典的なコンピュートになってしまう。

And on the right, I'm actually proposing a different model, which is the backend is the LM.

右側は、私が提案している別のモデルで、バックエンドはLMです。

It's not CodeGen, it's this LM is doing the execution, it is the backend.

実行するのはCodeGenではなく、このLMであり、バックエンドだ。

So the LM has access to tools like Coder Interpreter and potentially has access to, through that, making requests, network requests, and also has an access to DB.

LMはCoder Interpreterのようなツールにアクセスすることができ、それを通じてリクエストやネットワークリクエストにアクセスできる可能性がある。

So I have a mail client actually that works with this principle, and this is my test email.

だから、私はこの原則で動作するメールクライアントを持っている。

So if you all want to see any emails you send to me in a minute or so, you can send me an email.

だから、もしみなさんが私に送ったメールをすぐに見たいなら、メールを送ってください。

But please be nice.

でも、優しくしてください。

All right, I think it's probably enough time.

よし、もう十分だろう。

So I'm going to go over here.

だから、私はここに行くつもりだ。

So we have this email client.

だからこのメールクライアントがある。

I mean, we still have some regular JavaScript to hook into the LM, hook the LM into the browser, but when I do log in, I'm going to use my Okay, we're good, we're good.

つまり、LMにフックするための通常のJavaScriptや、LMをブラウザにフックするためのJavaScriptは残っている。

All right, we're saved, I think.

よし、助かった。

Thankfully, I have a room full of engineers.

ありがたいことに、私の部屋にはエンジニアがたくさんいる。

So there's a dot, but the reason it's so slow is because when I open this page and log into Gmail, the Gmail token is actually being sent to an LM.

ドットがあるわけだが、これほど遅いのは、このページを開いてGmailにログインすると、Gmailトークンが実際にLMに送信されるからだ。