AIプログラミングの正直なレビュー

最近ではLLMを避けるのが難しくなっています。ソーシャルメディアを避け（あるいはスラムファクトリーの大部分を避けるようにフォローリストをキュレーションし）、ニュースで額面通りに受け取られるような大げさなマーケティング声明を無視したとしても、職場でそれに出くわす可能性が高いでしょう。過去のシルバーバレット（マイクロサービスやNoSQLなど）とは異なり、AIの採用は多くの場所で経営層から指示されているようで、エンジニアリングの仕事をしたことがある、あるいは学んだことがある人がどれだけいるかに関わらず、導入が進んでいます。 確かに、このアプローチはすぐに私の反骨精神を刺激し、あらゆるAIツールに対して非常に断固たる態度をとらせました。人生で一度もコードを書いたことのない人が、私のエンジニアリングの仕事に何を使うべきかを指示してくることを、私は信じられません。これはマイクロマネジメントの最も末期的なケースのように聞こえますし、それは決して良いことではありません（個人的に侮辱的であることに加えて）。 いずれにせよ、過去3ヶ月間、仕事でClaudeとその仲間たちを使ってみて、ある程度役立つことを見出したことを認めざるを得ません。ただし、コードを書かせるのはやめてください。コードを書かせるのはやめてください。しかし、話が先走っています。 人工「知能」 おそらくあなたはこれを百万回聞いているでしょうが、人工知能はそれほど賢くはありません。すべてはマーケティングとバズワードです。私たちが本当に持っているのは、（非常に）大規模なニューラルネットワークで、自然言語処理に特化したものです。 人間がコンピューター上で行うことの多くは、テキストを使って双方向でコミュニケーションすることであることが判明しました。そのモデルは、クエリを解析したり、確率的ヒューリスティックに基づいてテキスト応答を生成したり、コマンドラインを出力してそれを古いやり方で実行し、その結果をモデルにフィードバックして、ある終了条件に達するまでループさせたりするために使用できます。 これが本質的に悪いということではありません。しかし、魔法でもありません。「エージェントワークフロー」（あなたがこの記事を読んでいる時点で彼らがそう呼んでいるものかもしれません）は、あらゆるソフトウェア問題は別のレベルの間接性を追加することで解決できるという認識に過ぎず、LLMも例外ではありません。ニューラルネットワークの出力が、より多くの入力を提供することで改善されるなら、より多くの入力を接続してください。そして、どの入力が最適かを判断する最良の方法は、モデルにコマンドを生成させてから、それをsystem()経由でパイプすることであるなら、それもまたよしとしましょう。 しかし、この記事の残りの部分では、ユーザーの視点に焦点を当てましょう。 家庭にあるGoogle... インターネット上には非常に価値のあるものがたくさんあります。既存の記録を適切に維持していると仮定すると、公開知識の総量は増加する一方です（しかし、ネタバレ注意、ただし注意点があります）。問題はその発見にあります。これは新しいことではありません。私が最初に新しい「Google」というものを試すように勧められた時代を覚えているほど年をとっています。しかし残念ながら、2000年代の黄金時代以降、状況はかなり悪化しています。彼らはしばらくの間、SEOとの戦いを繰り広げており、勝っているようには見えません2。 AIの登場は、助けと妨害の両方です。検索ツールとしては、自然言語で表現された的確な質問に答えるのに役立つことが多いと感じています。特に、会話能力により、回答を洗練させたり、現在のコンテキストを考慮してフォローアップの質問を提起したりできます。実際には、これは一連の検索を実行し、上位N個のリンクをざっと見て、理解したと思うまで繰り返すことに相当します。長いテキストの短い要約を書くことは、LLMが最も得意とすることのようです。そのため、このプロセスを自動化するために使用するのは理にかなっています。さらに、複数の検索をクロールして要約することは、本質的に並列処理可能なジョブなので、プロセスを自動化することで得られる効率を理解するのは難しくありません。ただし、十分なコンピューティングリソースがあり、要約をハルシネーションしないと仮定した場合です。これらの両方の点については、後で詳しく説明します。なぜなら、それらは非常に重要だからです。 妨害の反対側は、もちろん、LLMが単語のサラダをインターネットに氾濫させるコストを削減したことです。これは、すでに不安定な情報海を希釈します。Freya Holmérは、SEOの終わりのない競争でAI生成コンテンツでウェブを汚染することの影響とトピックに関する非常に良いビデオを公開しました。手で情報を検索することは、今日でも選択肢として残っています。特に、特定のトピックに関する評判の良いソースをすでに知っている場合はそうです。しかし、そうでない場合は、スラッジと実際のデータを仕分けるために細心の注意を払う必要があり、どのソースを保持し、どのソースを破棄するかを指示できない場合、LLMループで自動化しても役立たない可能性があります。ハルシネーションについて話す前にさえ、LLMが生成した要約は、それが取り込んだソースと同じくらいしか良くありません。 ...そして今、職場にもGoogleがあります LLMループが検索に役立つと感じた特定の分野で、これまであまり議論されてこなかったのは、社内のナレッジベースです。どこで働いていても、ウィキ、Slackの会話、Googleドライブ、Confluenceのページなどの組み合わせがあり、多くの良い情報がそこにありますが、誰も見つけられないようです。私は、それらの「エンタープライズソリューション」の中には、1週間前に閲覧したページでさえ、検索バーにタイトル（またはタイトルを覚えていること）を入力しても見つけられないほど悪いものさえ経験しました。私は、自分が書いた社内技術記事のいくつかは、技術グループチャットで最初にリンクしたときからブックマークを保持していない限り、誰も見つけなかったに違いないと確信しています。 過去数ヶ月間、そして会社に新しく入ったにもかかわらず、私は自分の時代より前に書かれた多くの答えを見つけることができました。なぜなら、「AI Google検索」が複数のクエリを並列実行して回答を要約するのと同じように、Claudeとその仲間たちは私の自然言語の質問を、おそらく同義語の検索クエリのセットに変換し、何かが見つかるまで続けます。エンジンで特定の例外的なケースに遭遇したときに非常に便利であることが証明され、誰かがそれを報告したかどうか、回避策を提供したかどうか、またはなぜそれがそのように動作しなければならなかったのかを議論したかどうかを迅速に検索できました。テクノロジーで問題に遭遇するたびに、それが以前に議論された可能性が高く、その会話を見つけることができれば、はるかに良いスタートを切ることができます。 これは技術的には新しい技術ではありません。Googleとその仲間たちが長年効率的であった理由の1つは、ページのキーワードメタデータを構築する際に同義語を自動生成することです。あなたの会社のウィキやチャットの検索機能はおそらくそうではありません3。私は、LLMが検索しない限り、またはより経験豊富な同僚がそれを覚えていてあなたに指摘できない限り、アクセスするのが非常に難しい、古いSlack会話ログに多くの価値があるのではないかと疑っています。 数十年も前の基本的な検索エンジンの技術を実装できるのに、高価なLLMを実行して会社のウィキを検索するのは、技術的な観点から効率的でしょうか？いいえ、私はそれがそうではないと確信しています。Googleが20年前にやったようにコンテンツをインデックス化することは、コンピューティング能力の観点からは間違いなくより効率的なソリューションになるでしょう。しかし、ユーザーの視点からは、ページに「User Interface」と書かれているために「UI」を検索しても結果が得られない状況よりもはるかに望ましいです。 ハルシネーションと偽陽性 LLMが回答を見つけたら、一次情報源を確認するのが通常良い習慣です。その記事、ドキュメント、またはチャットログを読むと、回答がハルシネーションされていないことを確認するのに役立ちます。 ハルシネーションは、LLMの動作方法の本質的な特性です。トークン生成は論理や真実に基づいているのではなく、統計に基づいています。私の理解では、それらを完全に回避する方法はありません。私は、安価で（そしてかなり悪い）Bingに付属するCopilotの無料バージョンから、Claudeの最も派手な有料モデルまで、すべてのモデルでハルシネーションを経験しました。 CMakeやVulkan、Xcodeの特定のニッチな機能について尋ねるなど、非常に具体的な質問をした場合に最も一般的でした。「できません」と答える代わりに、最も確率的な回答を得ました。