AIの新スキルはプロンプトじゃない！次に必要なのはコンテキストエンジニアリング！
引用元：https://news.ycombinator.com/item?id=44427757
記事の『強力で信頼できるAI Agentは、魔法のプロンプト探しやモデル更新じゃなくなってきてる』は分かる。
でも『コンテキストをエンジニアリングして、適切な情報やツールを、適切なフォーマットで、適切なタイミングで提供することだ』って言うけど、その「適切」が未定義なら、結局まだ「魔法」を探してるのと同じじゃない？
「適切な」情報の定義が「言語モデルから十分正確な答えが得られる情報」ってことなら、プロンプトエンジニアリングと根本的に何が違うのか分からないね。
非決定的な機械なんだから、「試して見る」のと本質的に見分けがつかない信頼できるヒューリスティックなんてないと思うけど。
結局、全部マジカルシンキングだよ。
今「prompt」って呼んでるか「context」って呼んでるかの違いだけで、非決定的な空間で何か「うまくいく」のを見つけようとしてる、同じような試行錯誤なんだから。
＞プロンプトだろうがコンテキストだろうが、非決定空間で’うまくいく’のを探る点で同じ
ちょっと納得できないな。
PromptとContextは違うものだよ。
確かにPromptを使ってContextに何かを入れることはできるけど、だからって完全に同じってわけじゃない。
長時間にわたる会話で、Contextの中にたくさんの情報が入ってるとするよね。
あるPromptが、前はうまく機能したのに、コンテキストが変わったせいで今は全然ダメ、ってことがある。
この違いは単なる言葉遊びじゃないと思うんだ。
どうでもいいけど、「prompt engineering」って言葉は前から好きじゃなかったな。
「engineering」って言葉の使いすぎの典型例じゃない？
この時点では、非決定的な性質とHallucinationのせいで、Context engineeringはほぼ魔法みたいなもんだね。
でも、これが俺たちの知見だよ。
1 - LLMは、上位7～12行目に来るContextを拾い上げて理解する傾向がある。
特に最初の1k tokenがLLMsに一番よく理解されるね（Claudeといくつかのopensource modelsでテスト済み）。だから、Parsing rulesみたいな一番重要なContextはそこに置く必要がある。
2 - Contextは短く保つ必要がある。
奴らが主張するContext limitは真実じゃない。
1M tokenの長いContext windowを持つかもしれないけど、平均10k tokenまでしか正確さとRecall capabilitiesは良くない。
それ以上はゴミだ、無視していい。
Promptを書いて、Key informationを失わずに手動か、またはLLMを使って圧縮/要約してみるんだ。
3 - Agent-to-agent orchestrationを構築する場合、長いContextと複数のToolsを持つAgentを作るんじゃなくて、Toolsセットが違ういくつかのAgentに分割して、Handoverだけを行うPlanning agentを置くんだ。
4 - 他の全てが失敗したら、Agent handover logicはコードで書け。常にそうすべきだ。
autogen + Claudeを使って、様々な業界で5つ以上のAgent-to-agent orchestrationプロジェクトを構築した結果がこれだ。
最新のGeminiに本丸ごとアップロードしたことあるよ。
そしたら、複数の章の知識が必要な特定の質問にも、モデルは信頼できるレベルで正確に答えてくれたね。
そうだね、もし何か言うなら「art」って呼ぶべきだよ。
この文脈で「engineering」って言葉を使うのはあまり意味がないと思うけど、でも正直… QA Engineerとか、他のたくさんの仕事にその言葉を付けた時も、意味があったかな？
俺はそう思わないから、10年以上も言葉を誤用し続けてきた後で、今更議論してもしょうがない気もするね。
ContextもPromptも、同じInputの一部にすぎないんだよ。
モデルにとっては違いなんてない。
唯一の違いは、ユーザーがそのInputをモデルにどう与えるかっていう方法だけだね。
理論上は、Contextを巨大なPromptとしてモデルに与えることもできるんだ。
たまに、LLM支持者たちが自分たちの言ってるデタラメを理解してるのか疑問に思うことがあるよ。
全部Context window内のTokenなんだろ？
System promptsも、会話の先頭にずっと追加されるTokenにすぎないんじゃないのか？
奴らはこのことを六重にも七重にも飾り立て続けるだろうけど、結局いつだってStochastic token predictionなんだよ。
まあ、巨大なDatasetを扱ってる時に、Contextに「正しいもの」を入れるっていうのは、間違いなくEngineeringだよ。
Promptでできることには限界があるんだ。
それで達成できる70%の精度から、Claude Codeで見られる95%の精度に行くには、Contextが絶対的に最も重要だよ。
Claudeがまさに適切なContextを取得するために、どれだけの労力が費やされているかが目に見えるね。それが速度を犠牲にしていることも多いけど。
“non-deterministic machines”ってのは間違いだよ。静的なseedを使えばdeterministicになるんだから。
エンジニアリングは科学や数学を応用することだろ？非決定的なシステムの挙動を推測することに、そんな科学や数学があるか疑問だよ。
プロンプトとコンテキストをなんで区別するの？この記事はコンテキストの意味を勝手に変えてるだけの誇張っぽいね。「State/History」や「RAG」も結局プロンプトエンジニアリングの範囲でしょ。プロンプトエンジニアリングがいらなくなるのは、ツールが面倒を見てくれるから。AIが良くなったんじゃなくて、単にUIが良くなったってことだと思うな。
それは実際には違うね。浮動小数点演算は丸め誤差で非可換だし、並列処理はtemperature 0でも非決定性を生むんだ。
評価パイプラインを作ったり、実験で検証したりし始めたら、それはもう推測じゃなくなるよ。
「これらの機械は非決定論的だ」っていうのは、temperature設定でランダム性を許容した場合だけだよ。
コードの使い方を聞かれたら、全部読むより検索ツール使う方が正確だろ？そういうタスク（たくさんある！）なら、LLMの場合に根本的に違うものを期待する理由が分からないね。
なんで「プロンプト」と「コンテキスト」を区別するの？
違うものだからさ。プロンプトは動的に変わらないけど、コンテキストはいつも変わる。全部まとめて呼んでもいいけど、区別できた方が話すときに便利なんだよ。
そうだね、AIの呼び出しは基本的に次の単語予測さ。＜system＞〜＜user＞〜＜assistant＞…って繰り返すだけ。AIは＜user＞とか＜system＞を違うように見てるけど、物理的には同じ。全部プロンプトだし、全部エンジニアリングできる。Assistantの応答の最初を埋めるのも有効で、システムメッセージより効くことも。これもプロンプトエンジニアリングだよ。
え？ローカルモデルで一貫した出力は得られるよ。大きなネットワークだって決定的に訓練できる（CUBLASフラグ）。君の言ってることは実際には違うね。今すぐAnthropic APIで全く同じ結果だって出せるし。
API呼び出しの時は、全部同じテキストの塊として扱われるだけだよ。
なんで検索ツールを直接提供しないんだ？AIが不完全な仲介役になるよりマシでしょ。AIを間に挟む唯一の理由は、その人がコンテキストの知識があってツールをうまく使える場合だけだよ。それ以外は「このツール使って」って言うべき。
温度を0にしても、並列処理とか浮動小数点数の丸め誤差とかで、たいてい非決定的になるんだよ。
みんな「プロンプトエンジニアリング」が特別なスキルじゃないって気づいたから、AIに関わる人たちが言い訳してるだけじゃないの。
プロンプトとデータは、ずっと前から区別されてきたことだよ。
AIについて大げさに語る人がいる時、俺がAIを「オートコンプリート」って呼ぶのはこれが理由なんだ。だって、そこから来てて、まさにそれなんだから。
それはよくあることだけど、特に信頼性があるわけじゃないんだ。（個人的な経験では、今のGeminiはChatGPTより少し優秀かな。）
例えば、繰り返し作業で長いメールのやり取りやMarkdownのひどい表、ステークホルダーやプロジェクトの背景とか、色んな情報を全部LLMに食わせて、返信タイプ決めさせたり、メールのテンプレート選ばせたり、返信の下書き、ドキュメント作成、JSON出力とかさせてるんだ。
75%くらいは一発でうまくいくから、1日1時間以上は余裕で節約できてるよ。残念ながら、10%くらいは見た目完璧なのに根本的に間違えてる応答が出てくる。まあ、飽きさせないためかな。
情報集めには役立つけど、指示とかガイダンスにはそんなに向いてないと思うんだ。だから、標準的なアドバイスとして、指示は最初と最後に繰り返せって言われてるんだよ。
検証されてフィルタリングされてるけど、結局は推測がコアじゃない？「検証済み推測」って呼ぶべきかな？
多くの人が勘違いしてるけど、LLMの「非決定的」な性質は、モデル自体じゃなくてトークンの分布をサンプリングすることから来てるんだと思うよ。
もっとコメントを表示（1）
浮動小数点の誤差は決まってるし、並列処理が結果に影響するのもLLMに限った話じゃないでしょ。
この議論、WoWとかのゲーム攻略みたいに聞こえるわ。試行錯誤で見つけた戦略を身内だけで通じる言葉で話してるだけじゃん。
無知なマネジメントに売りつける、プログラミングのゲーミフィケーションの始まりだね。
これってオンライン広告のやり方と一緒だね。Facebook広告の仕組みが誰も分からないから、変なコンサルが費用を抑える方法とか言って稼いでるのとそっくり。
＞ 試行錯誤で見つけた戦略を身内だけで通じる言葉で話してるだけじゃん
これってまさにコンピュータサイエンスの超初期みたいだよね。
唯一違うのは、今はずっと人気があって、メールやBBSでヒントを共有してた一部のオタクだけじゃないってこと。
＞ これってまさにコンピュータサイエンスの超初期みたいだよね
でも実際のコンピュータサイエンスでは、試行錯誤で見つけた戦略が良いって証明できるんだよ。
ダイクストラみたいに、数学の言葉で分析して、それが最適かどうかも証明できる。
＞ でも実際のコンピュータサイエンスでは、試行錯誤で見つけた戦略が良いって証明できるんだよ
CSならそうかもね。でもここにいるほとんどの人はCSじゃなくてソフトウェアエンジニアリングをやってる。
SEは全然証明できないよ。言語論争とか、静的型付けか動的型付けかとか、FPかOOPかとか、何年も議論してるでしょ？
だからAIについて言ってること、SEにとっては全然新しい話じゃないんだよ。
コンテキストエンジニアリングに関する主張も、科学的な手法でテストできるんじゃないの？
理論上はね。でもめっちゃ複雑で変わり続けるシステム相手だから、「弱い」科学の心理学みたいなもんだよ。各要素の影響が小さいから再現が難しい。
それに、ちゃんとした科学的背景がない素人が多すぎて、ノイズが多すぎる。
AIにもある意味、再現性の危機がある。
でも、今のAIブームってまだ3年くらいでしょ？科学の進歩ペースからしたら、まだ始まったばかりだよ。
残念ながら、この分野は厳密さとか探求心が足りない人がめっちゃ多いし、何も疑わずに主張を信じるんだよね。
例えば、この超人気リポジトリ https://github.com/x1xhlol/system-prompts-and-models-of-ai-t… とかさ。
作者はプロンプトをどう手に入れたかとか、それが正しいってどう証明するのか説明してないじゃん。
あー、でも科学の種類が違うんだよね。
「ソフトウェアエンジニアリング」から「AIエンジニアリング」への移行って、まさにハードサイエンスからソフトサイエンスへのスイッチだよ。
精密な理論で予測して実験で検証する化学者や物理学者から、適当に変数いじってT検定して「何か変わった？」ってやる社会学者や心理学者になった感じ。
「モデル」と「理論」の違いって話だね。「理論」は「なぜ」を説明しようとするけど、「モデル」は「どうやって」を教えてくれる。エンジニアリングでは「なぜ」が大事、バグだって試行錯誤じゃなくて原因究明したいじゃん？＜br＞物理みたいなハードサイエンスには理論があるけど、ソフトサイエンスにはモデルがある。Computer Scienceは理論が基礎になってる（Turing MachineとかLambda CalcとかLogicね）。＜br＞AIモデルはまさに「モデル」って感じ。なんで動くか分かんないけど、とにかく動く。モデルってそういうもんだよ。
「Computer Scienceの最初期からそうだったみたいだね」って話だけど、Dijkstraは墓で回転してるよ。Computer Scienceは、あのTech Brosが出てきて色々ぶっ壊し始める前は、数学の厳密なサブ分野だったんだ。VCマネーが無限にあったせいで、この分野はダメになっちゃったんだよね。
「仲間内にしか通じない（だって他は誰も興味ないから）」って話だけど、それってだいたいどんな分野の専門用語にも当てはまるよね。WoWのレイドからCancer Research、Computer Science、それにOpenStreetMapとかまでさ。
Computer ScientistでWoWの熱心なプレイヤーだった俺としては、その意見は嫌だな。最高の戦略には、いつだってちゃんと根拠があるんだよ。
今どきWoWの戦略には、かなり科学的な要素が入ってるんだぜ。みんな頭使って、データ分析してるんだよ。
君の意見には賛成するところもあるよ。でも、君のコメントって過去のエンタープライズソフトウェア販売のサイクルを結構言い当ててるんだよね。ただ、今回はちょっと不快なぐらい、開発者っていうかbuilderの伝統的な領域、つまり影響力とかコントロール、ワークフローにまで踏み込んできてるってこと。今のdevの気持ちは、たぶん昔CSRとかQAとかSREの人たちが、マネージャーに流行りのツールや慣行を押し付けられた時の気持ちと同じなんだろうね、過去の”wave”でさ。
開発者には何年も前からこういうこと起きてるじゃん。25年前はObject Oriented Programmingだったよ。
あとはagileとかscrumsとかね。
うちの新しいCTOがさ、agileとscrumに移行することを決めたんだ。効率と士気を下げるためにね。そいつ、その責任すら取らないで、役員会に言われたって主張してるんだぜ。
それって「velocityを上げる」ためなんだろ？（皮肉）
これって30％のオーバーヘッドがかかるってこと？
OO（オブジェクト指向）との違いは、ちゃんと訓練されたプログラマーならどうにかできる希望が少なくともあったことだよね。今はAIのこと分かってる人なら、それがほぼ不可能だって知ってる。
JVMチューニング、コンパイラ最適化、デザインパターン、アジャイル手法、SEOとか、ちょっと考えただけでも色々あるよね。
この前これについてちょっと書いたよ：https://simonwillison.net/2025/Jun/27/context-engineering/
Drew Breunigもこの件で素晴らしい記事書いてるんだ。’Context Engineering’ってバズワードが出たのと偶然同時だけど、実はあのミームとは関係ないみたい。
How Long Contexts Fail - https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-ho… では、長いContextが問題起こす（Context Rotともいう）色々な方法を説明してる。
How to Fix Your Context - https://www.dbreunig.com/2025/06/26/how-to-fix-your-context…. は、Contextの対策技術に名前を付けてるんだ。Tool Loadout、Context Quarantine、Context Pruning、Context Summarization、Context Offloadingとかね。
ああいう問題は、学術界では今のLLMの一時的なものと見られてるよ。
既に何百万ものツールを同時に使えるLLMとか、安定した長いContextに関する研究があるんだ。これで、違うプロバイダーを繋ぐ以外はほとんどのユースケースでエージェントは一つになるかもね。
今のLLMをベースに将来のエージェントシステムを作る人は、LangChainの運命をたどるだろうな。GPT-3用に作って、GPT-3.5で時代遅れになったみたいに。
「1ヶ月で終わるスキル」だね。他のたくさんみたいに、そのうち消えるやつ。
Drew Breunigの記事は必読だよ。自分のエージェント作る時だけじゃなくて、今エージェント的なコーディング使う時もすごく大事。こういう限界や振る舞いはしばらく付き合うことになるだろうから。
彼の記事は良いかもしれないけど、Drewはいくつか重要な語源の間違いをしてるね。例えばLoadoutはゲーミングじゃなくて軍事用語だよ。KitとかGearと basically同じ意味。
ねぇ、3年前に見つけたLLMプロンプトのコツ、今もほとんど使えるんだよ。もう使わないやつだって、昔の知識があるからモデルの進化がなんとなくわかるの。役に立つよ！
ねぇ、「同時に何百万ものツールを呼ぶ」ってどうやるの？MCPみたいにHTTPベースだと、たとえ早くてもすごく並列な環境だと超時間かかりそうじゃない？
もっとコメントを表示（2）
君には同意だよ。でも正直、また新しいバズワードが出てきてマジうんざり。ShopifyのCEOがXeetして、Karpathyがそれに乗っかって、それが記事になって…って、根拠薄いのにインフルエンサーが言うから「あること」になっちゃうんでしょ？Jared Friedmanの「Founder Mode」みたいにすぐ消えるかもね。
まずね、プロの絵師に金払って自転車乗ってるペリカン描いてもらうじゃん。
で、それを「コンテキスト」として渡すの。
次に、モデルにプロンプト出す。
はい、完成！ってこと？
ねぇ、何百万もの単語や長いコンテキストを安定して扱えるって研究、リンク貼ってくれない？まだ見たことないんだ。
ビジュアルアートの分野だと、今のコンテキストエンジニアリングは全然足りないと思うんだ。AIは簡単なことは分かるけど、大事なこと（ネガティブシェイプとか色んなコントラストとか）は理解してない。
原因の一つは、アーティストに統一された専門用語がないこと。俺たちは自分で言葉作ったくらいだよ。誰かAI詳しい人と協力したいな。
MCPだけがLLMにツールを組み込む方法じゃないからね。
AnyTool（2024年の論文で16,000ツール）から最新研究をチェックするといいよ。ここ見て→https://arxiv.org/abs/2402.04253
長いコンテキストなら、Activation BeaconsとかRoPE scalingから調べ始めるのがおすすめ。
そうだね、でもそういうのってまだ出てないし、結局つなぎのコード（glue code）は必要になるんだよ。SOTAモデルの限界に合わせて、必要なglue codeをちゃんと作って、スケールできるようにしなきゃね。きっとみんな、モデルの限界を超える製品を作り続けると思うよ。
Drewさんが使ってた「loadout」って言葉、軍事用語じゃなくてゲーム用語だよ。自分でちゃんと定義してたもん。「レベルとかマッチが始まる前に選ぶアビリティとか武器、装備の組み合わせのこと」って。軍隊でレベル前にアビリティ選んだりしないしね。
バズワードってすぐ消えるのもあるけど、定着するものも多いよね。多くの人が内心考えてることを誰かが明確に言語化すると、バズワードは広まるんだ。この記事の例だと、エージェントやアプリ開発者がLLMで悩んでることは、chatbotユーザーとは根本的に違う（プログラミングに近い）。だからこの言葉（コンテキストエンジニアリング）は彼らに響くんだろうな。バズワードに関する昔の記事もあるよ: https://www.dbreunig.com/2020/02/28/how-to-build-a-buzzword….
＞アーティストやデザイナーは一貫した用語を持っていない
それは違うと思うな。完全に一貫してないかもしれないけど、どんなアートの本にも同じ概念が繰り返し説明されてるよ。人間を描くのでも、骨格、筋肉、平面、安定性、線画、遠近法なんかを強調してる。これらの概念は説明は難しくないけど、マスターが難しいんだ。それは判断力が必要だから。どの線をどう描くか、判断しないといけない。手と目の協調も必要だしね。
だから、スタイルを決める判断力を解決できない限り、望みは薄いよ。
追記
他の人の作品を学ぶとき、データをコピーしたり、色を抽出したり、ラベルを比較したりするんじゃないんだ…判断力を学んでるんだよ。基本となるやり方の完全な公式を知ってて、パラメータだけ知りたい感じ。機械学習は、全く違う変数で間違った公式を使ってる場合が多いね。
コンテキスト提供は理にかなってると思うけど、コンテキストを提供してAIに複雑なものを作らせた具体的な例って何かある？私はAIの支持者だけど、複雑な問題で significant results を出すのに苦労してるんだ。clone + memory bank とか使っても、AIにやらせようとして結局自分でやった方が早くて時間の無駄になることが多いんだよね。
私の見方では、「プロンプトエンジニアリング」って言葉が「チップとか死んだおばあちゃんの話みたいなくだらないハックを chatbot にタイプする」っていう意味に再定義されちゃったから、リブランディングしようとしてるんじゃないかな（例えばコンテキストエンジニアリングみたいにね）。
私の言いたいのは、新しいモデルではツールがコンテキストに焼き付けられてて、30個のツールでダメになる代わりに、コンテキストで定義された10,000個のツールを確実にサポートするようになるだろうってこと。それだけで、ほとんどの場合で複数のエージェントが必要なくなるよ。複数のエージェントに分けるのは、一つのエージェント内で多くのツールを reliably に実行できないことが多いからだしね。今はエージェントの状態に応じてツールをオンオフしたりして回避できるけど、将来はそんな面倒なことしなくても、全てのツールを長くて安定したコンテキストに dump して、パフォーマンスのためにキャッシュするだけで済むかもしれない。
フクロウの描き方。
1. 丸をいくつか描く。
2. AIにフクロウの残り全部を描くようにプロンプトする。
エージェント構築でこれをするだけのライブラリのエコシステムがまだないのが驚きだよ。エージェントを作る時って、自分で作るか、記事からアルゴリズムをコピペするしかないんだよね。
もっと plug and play で、LLM自体と同じくらい swappable になることを期待してるよ。オブザーバビリティ、A＼Bテスト、コストとレイテンシ分析（コンテキスト変えるとLLMのキャッシュが飛ぶから）のためのツールなんかも一緒にね。
アートの本にある程度共通認識があることには同意するよ。ただ、用語の不一致が多いのは確かだよね。例えば hue と color が混同されたり、lightness, brightness, tone, value なんかもそうだ。
それより気になるのは、本当に重要な内容があまり explicitly に扱われてないこと。例えば、多くのアートが依存するコントラストの強調は、違いを増やすか減らすかの二次元に存在する。このコントラスト＼affinity の適用はアート全体の一般原則だよ。生徒には韓国ドラマでの適用を見せて説明してるくらい。美術文献でこれに explicit に言及してるのは、200年近く前の Ruskin の仕事くらいしか見つけられない！
さらに悪いことに、すごく重要なのに全く扱われてない内容もある。例えば、画家がよく使う手法で、ある形の隣接する局所的なコントラストを、片方の縁で明るい背景に暗く、反対側の縁で暗い背景に明るくする、っていうのがある。人物画やクラシックなポートレート写真では almost ubiquitous な手法なのに、私が知る限り誰もそれに名前をつけたり書いたりしてないんだ。自分たちで名前をつけざるを得なかった（tone wrap）。
＞They are not difficult to explain, they are just difficult to master.
マスターが難しいってことには完全に同意。でも、それについて一貫した（あるいは存在する）用語がないと、 satisfactory に説明はできないよ。
＞So unless you can solve judgement (which styles derive from)
Nicely put だね。
記事が拙速で、なんか必死で自己中心的、上から無理やり押し付けられてる感じだよね。しかも筆者が2020年にバズワードの作り方についてブログ書いてたって？
それ知ると、この不自然で急かされてる感が余計に強調されて、なんか変だなってみんな思ってるのがわかるよ。
自分でエージェント作らないなら、この記事で言うコンテキストエンジニアリングのスキルは別にいらないんじゃないかな。
本当にそうかな？
これからAIが超普及したら、AIにどんな情報を与えるか理解するのは誰にでも必要なスキルになると思うよ。
これまで「プロンプトエンジニアリング」って呼ばれてたけど、うまい人たちは実際は「コンテキストエンジニアリング」をやってたってことなんだろうね。
＞例えば、画家がよく使うテクニックで、形の周りのコントラストを片側では明暗、反対側では暗明にする配置方法がある。
これ、正直よくわかんないんだけど、例えばこの絵の首と襟のコントラストのこと？
https://i.pinimg.com/originals/ea/70/0b/ea700b6a0b366c13187e…
https://fr.pinterest.com/pin/453596993695189968/
これ、「エッジコントロール」っていう概念じゃないかな？
https://www.youtube.com/watch?v=zpSlGmbUB08
現実には線なんてないから、スケッチでは使うけど crud なんだよね。一番良いのはエッジ、つまり対照的な2つの領域の境界。グレーなら簡単だけど、色が入ると難しい。James Gurney の『Color and Light』って本が詳しいよ。簡単に説明できるけど、できるようになるのは大変なことだね。
最初のリンクに「十分なコンテキストを読んで必要なものを得る」って書いてるけど、これって具体的にどうやるの？
どうすればプロンプトがもっと良くなるの？
この説明、『draw the rest of the fucking owl』ってミームみたいで、全然具体的じゃないよ。
新しいスキルはプログラミングだよ、昔から変わらない。
こういうものを理解するには、プログラムを書くのが一番。訓練するプログラム、推論するプログラム、挙動を分析するプログラムとかね。
LLM はどう動くか詳しく知ってると最大限に活用できる。
自分で LLM を色々訓練したり、関連する作業をやってみたりしたら、考え方や結果が変わったんだ。後者の方がずっと良い。
みんな違う答えを期待してるのはわかるけど、プログラミングツールをマスターするには、ある程度自分で実装するしかないんだよ。
俺も ML プログラミングは中程度の経験しかないから理解もそれなりだけど、コンパイラと同じで、中程度の経験があるだけで、複雑なものから良い結果を得られるか、ただ勘でやるかの違いが出る。
LLM を訓練してみなよ！
Karpathy がどうやって理解したと思う？
答えは彼のブログにあるよ！
LLM を理解する一番良い方法は自分でビルドすることだ、って言うのは、コンパイラを理解する一番良い方法は自分で書くことだ、って言うのと似てるね。
技術的には正しいけど、そこまで深く知りたい人って多くないんじゃないかな。
いや、そのミーム（自分で作るのが一番良いけど、みんなやらない）は聞いたことあるけど、GitHub とか HN のフロントページ見てると、クールなコンパイラプロジェクトが結構あるから、それほど当てはまらないかも。
LLM の話はもっと新しいけど、「個人が週末にこれやって、全体像を根本的に理解できる」みたいな、役に立つ面白いものがいっぱいあるよ。
「この一つの簡単なトリックで72時間以内に XYZ をマスター！」みたいなコースを求める層はいつだっているし、そういう市場に応える人たちもいるだろうね。
でも、ほとんどの人？
特に HN みたいな場所では？
ほとんどの人は、筋トレするにはジムに行くしかない、って分かってると思うよ。
俺は一般的な人に対して結構高い評価を持ってるんだ。
「多くの人はバカ」ってミームに惹かれがちだけど、それは悪いやり取りが記憶に残るからで、多くの人がバカとか怠け者とかじゃないんだ。
ほとんどの人は、真剣に取り組めばすごく賢いし、報酬が reasonably clear なら、一生懸命頑張ると思うよ。
https://www.youtube.com/shorts/IQmOGlbdn8g
車を理解する一番良い方法は車をビルドすることだ、っていうのは、誰もやらないけどみんな日常で車をかなりうまく使えてるのと似てるよ。
それは大部分、作る会社が努力して使いやすく、複雑さを取り除いてくれてるから。
F1 ドライバーになりたいなら、車のほとんど全ての部品を理解するのは役に立つだろうね。
でも、配達員なら、たとえ週40時間以上使ってても、そこまで理解する必要はないだろうね。
