1 ポイント 投稿者 GN⁺ 2025-07-06 | 1件のコメント | WhatsAppで共有
  • LLMツールの成功談では、プロジェクトの条件、ユーザーの専門性、後続作業量といった比較基準が抜け落ちていることが多く、実際の有用性を判断しにくい
  • MCP、ツール利用、エージェントに関する議論で、批判者を「深く見ていない人」と決めつける態度は、過去のcrypto論争に似ている
  • LLMとエージェントは非決定的であるため、同じ問題でも、今うまくいった方法が1分後にもそのまま通用するとは考えにくい
  • Claude Codeが「レガシーなバグを処理する」という有名な発言も、コードベースの規模、バグの種類、管理方法が欠けたまま1.8千いいねと204リポストを得た
  • 複数のツールを実際に使ってきた立場から見ても、LLMは非決定的な統計機械に近く、動作するときは魔法のように感じられても、魔法や工学だと断定するのは難しい

LLM体験談を相互に比較しにくい理由

  • LLMツールに対する賛否の体験は、たいてい切り離された断片として共有されるため、同じ条件について話しているのか確認しにくい
  • プロジェクトやコードベースの性質が抜け落ちていることが多い
    • greenfieldなのか、成熟したコードベースなのか、プロプライエタリなコードベースなのかが不明確
  • ユーザーの専門性も単純には比較しにくい
    • その専門性が同じドメイン、同じコードベース、同じ言語に適用されたものなのか分からない
  • レビュー、修正、デプロイ、仕上げといった追加作業量がどれほど必要だったかも、判断に大きく影響する
  • たとえ1人が上記の情報をすべて提供したとしても、他の人々の条件が分からなければ、体験間の比較は依然として限定的になる
  • そこにLLMシステムとエージェントの非決定性が加わる
    • 同じ問題でも、今通用していた方法が1分後にも通用するとは見なせない
    • Reactのgreenfieldプロジェクトにおけるシニアエンジニアの体験と、OCamlのプロプライエタリなコードベースにおける非開発者デザイナーの体験は、モデルやエージェントが変わるとさらに比較しにくくなる
    • 同じモデルとエージェントでも実行ごとに結果が変わり得るため、単純な比較は難しい

過熱した言説と実際のツール利用の間のギャップ

  • LLM批判者を「MCPとツールを十分に見ていない人」と扱う反応は、AI論争の過熱を示している
  • 「industry leaders」の事例として、Steve YeggeのClaude Codeに関する発言が登場する
    • Claude Codeが古いコードベースのレガシーなバグを数日にわたって強力に処理したという内容
    • コンテキストを自分で選ばなくてもClaude Codeが進める、というような表現が含まれている
    • 承認さえ続ければ、バグ修正が本番環境へのデプロイまで進み、ユーザーログを確認するという内容も含まれている
  • この事例でも、判断に必要な情報は抜け落ちている
    • コードベースの規模が分からない
    • どのようなバグなのか分からない
    • 追加の管理があったのか不明確
    • プログラミング言語やフレームワークも明らかではない
  • それにもかかわらず、この発言は1.8千いいねと204リポストを得ている
  • 懐疑論者や批判者もツールを使っていないわけではない
    • Vercelのv0で全面的に設計したサイドプロジェクトがある
    • Swiftを知らない状態でClaude Codeを使い、SwiftUIの監視アプリを作った
    • Midjourneyでイベントポスターを作った
    • ElixirでMCP serverをvibe-codingしたが、phoenix.newは使わなかった
  • 実際の使用経験は「50%の時間で50%だけ動作する」といった形で要約される
  • LLMは非決定的な統計機械であり、動作するときは魔法のように感じられることがあっても、魔法そのものでも工学そのものでもない
  • LLMをめぐる言説は、それを魔法か工学のどちらか一方としてのみ扱おうとする傾向がある

1件のコメント

 
GN⁺ 2025-07-06
Hacker News の意見
  • 職場の経営陣が 生産性が10倍向上 といった話を聞いていて、もどかしい。そうした主張の一部は社内のアーリーアダプターからも出ている。
    しかし期待値が高くなりすぎている。理由の一つは アムダールの法則 で、実際にはコーディングよりも考えることや、自分のコードの顧客である他の人たちとコミュニケーションすることに、はるかに多くの時間を使っているからだ。コーディングが10倍速くなったとしても、ほとんどの部分はそうならず、全体の生産性は10〜15%ほど良くなる程度だ。無視できるほどではないが、10倍ではない

    • 今の仕事が研究開発寄りだからかもしれないが、自分の場合、LLM はコーディングと同じくらい 考える部分 でも生産性を上げてくれる。コミュニケーションは今のところ自分でうまく処理できている。
      LLM で思考作業をする感覚は、20年ほど前にウェブ検索を身につけたときに似ている。検索エンジンは何を探しているか分かっているときに情報へのアクセスを可能にしたが、今や LLM はそもそも何を探すべきかを見つける手助けをし、検索までしてくれる。以前なら労力と不確実性のために難しいと分類していた作業が、些細なものになった。
      今ではウェブ検索の約1/3を ChatGPT o3 で行っており、もう手放しにくい。
      未成熟な考えを整理し、ラバーダックのように受け止めてくれる心理的効果もあるので、多くの作業がずっと負担に感じにくくなり、それだけでも大きな違いがある
    • うちの会社も似たような状況で、これまで見てきた社内アーリーアダプターの生産性に関する主張はすべて、非常に狭い生産性の測定方法 と、控えめに言っても怪しい計算に基づいている
    • それは、LLM がジュニア開発者よりも シニア開発者 にとって、はるかに大きなアクセラレーターになるからかもしれない。ジュニアは何が良くて何が悪いのかをよく分かっていない。
      シニア1人にうまくチューニングされた LLM のワークフローを与えれば、LLM 以前のジュニア10人分の生産性があっても驚かない。しかも悪い開発者はシニアの時間を奪って生産性をマイナスにすることがあるので、その場合はほぼ無限倍に近い。
      まともなジュニアでも、たいていは低レベルの反復作業に縛られるが、LLM はすでにそうした仕事をよりうまくこなせる。
      だから雇用が実際に消える可能性があるという話は理解できる
    • LLM ツールのコストのせいで雇用コストが10〜15%余計にかかるなら、10〜15%の生産性向上 は無視できないのではなく、検討すべき問題だ。スループットだけでなく、全体の生産コストを常に見るべきだ
    • また一つの 技術ハイプ の波にすぎない。現実は完全な破滅と無限のユートピアの間のどこかだろうが、おそらくそのどちらでもない。
      AI の流れは、2000年代初頭にソフトウェアエンジニアを大規模に海外アウトソーシングしようとした動きを思い出させる。経営陣の間では大きな期待があり、机上ではもっともらしかったが、ほとんどは大失敗に終わり、ほぼすべての仕事が米国に戻ってきた。
      ソフトウェアエンジニアが全体をつなぎ止める無数の細かな仕事をしている点を、多くの人が見落としている。AI にはそうした部分がかなり欠けている。外国人にそれがないという意味ではないが、言語の壁、タイムゾーンの違い、文化の違いなどによって似たような問題が生じた。コード品質と保守性は急落し、アウトソーシング業者が作った多くの成果物は捨てざるを得なかった。
      すでに私が扱うコードベースにも AI の残骸 が積もりつつある。コードレビューを通過したこうしたものを見つけ出すのは非常に難しい。diff で見ると妥当に見えるからだ。問題は、目に見えない重複コードと、高いレベルで見るとまったく筋が通らない奇妙な抽象化だ
  • 私は、筆者が不満を述べているまさにそのタイプに属している。ChatGPTしかなく、性能も大したことがなかった頃から、些細ではないグリーンフィールド製品をリリースしてきた。最初はClaudeを使い、WebチャットとXCodeの間でコピー&ペーストしていたが、その後Cursorを見つけた
    Cursorは厄介なビルドエラーを大量に残したものの、生産性はそれでも少なくとも3倍だった。今ではエージェントがさらに良くなり、Claude 4が出てからは、ほとんど自分でコードを書いておらず、それを嫌だとも思っていない。アーキテクト/マネージャー寄りの役割になり、必要なら専門知識でエージェントを指揮している
    要求の厳しいスタートアップに入って数カ月になるが、まだ手でコードを1行も書いていない。PRを作る前にすべて自分で監査し、徹底的にテストしているが、Cursor + Sonnetはそのコードベースでは本当にとんでもなく強力だ。コード行数のような無意味な指標ではなく、そのコードベースの専門家たちが変わったバグを持ってきても、そのドメインに新しく入った私が5〜30分以内に絞り込めるという点で、自分が最も生産的な社員だと確信している
    もともとキャリアを通じて避けてきたフロントエンド開発者の仕事にまで、Claudeのおかげで目につく小さな問題を直しているうちに踏み込んでしまい、手を引かなければならなかった。これはバイブコーディングではなく、調査、計画、慎重な探索の手順があり、エージェントが成功するようにセットアップするプロセスだ。ドメイン知識も必要になる。なのに、どうして同じ効用を引き出せない人がいるのか本当に不思議で、こういう記事が毎週2本ずつ出ているように感じる

    • でも、今のコメントはブログ記事が主張していたことを全部裏付けてしまっている
      信じがたい話をしているのに、証拠は一つも共有していない。それどころか、身元確認と主張の検証を不可能にするために使い捨てアカウントまで作っている
      だから冗談のように感じる
    • 私も似た経験をしているが、作業のやり方は少し違うと思う。私は博士課程の学生だ。LLMには極めて懐疑的だったが、Claude Codeが作業のやり方を完全に変えてしまった
      だからといってキュレーションの必要がなくなるわけではない。それは依然として私の役目であり、博士課程で教えるべきことの一部でもある。なぜXをするのか、Yで何を示したいのかを正確かつ内省的に扱い、すべてのステップを分解して他人に説明する能力は、非常に大きなソフトスキルだ。エージェントには持続的な世界モデルがなく、賢い圧縮を使っても対話の目的をすぐ忘れてしまうため、今はさらに重要になっている
      私が正確にコミュニケーションできている状態なら、以前は不可能だった方法でClaude Codeを使って計算作業を整理できる
      品質を気にするならプログラミングより簡単というわけではないが、別物であり、別のイディオムを必要とする
    • LLMが出すコード品質はかなり悪いと思う。何度も反復して直していると、自分でやったほうが速いことが多い
      エージェントが本当に役立つのは、大規模で機械的なリファクタリングだ。完璧なvimマクロやAST書き換えスクリプトを考える代わりに、エージェントに任せている
    • PRを作る前にすべて自分で監査し、徹底的にテストしているとのことだが、LLMはプロジェクト全体を頭に入れているわけではなく、幻覚もよく起こすのに、信頼できない出所のコードをどうやってそんなに速く監査しているのか?
      平均してプロンプトはどれくらい長く、ユニットテストもLLMが書いているのか?
    • Claude Codeを毎日何時間も使っているが、こいつは嘘つきだ。信じて使うのは各自のリスクでやるべきだ
      個人的には、経験をあまりにも良く包装しすぎていると思う
  • 個人的には、これがよく理解できない
    世界中のサービス産業における膨大な量の仕事は、実質的には人があるExcelシートから別のExcelシートへ、あるいはCRM/メールからExcelへと手作業でデータを移すことに近い。ほとんどすべての大企業には、こうした仕事を毎日している正社員が数百人から数千人おり、その多くは外注でもある。ソフトウェアエンジニア1人につき、こうした手作業のデータパイプライン業務をしている人が100人はいると思う
    したがって、LLMが大きな価値を生み出すためにOCamlを非常にうまく扱える必要はない。Excelで人間より少しうまくできればいい。MCPが本当に役立つのは、こうしたシステム同士を簡単につなげられる点だ。こうした作業で起きる多くのエラーは、作業全体を一度にコンテキストに入れようとすることで生じる。MCPでメールを取得してデータを抽出し、またMCPでCRMに1行ずつ入れられるなら、私の経験上、幻覚率は非常に低い。少なくとも過労気味のジュニア社員レベルにはなる
    もしかすると記事の要旨もこれだったのかもしれないが、こうしたユースケースでは非決定性は問題ではない。関わっている人間たちも決定的ではないからだ。非決定的なシステム、たとえば人間のシステムの品質を強制する仕組みやプロセスは作れる
    最後に、私は暗号資産もLLMもかなり追ってきたが、効用と採用という面で両者が似ているようには見えない。最も近いのはスマートフォンの普及だ。iPhoneが最初に出たとき、非技術系の友人の多くはスマートフォンは不要だと言っていたが、数年のうちに全員が持つようになった。LLMも似ている。今では、非技術系の友人のほぼ全員が非常にさまざまな用途で使っている

    • 暗号資産と比較するのは怠惰な批判だ。検証する価値もあまりない。暗号資産の否定的な雰囲気を持ってきて再利用しようとしているだけだ。2つの技術は互いに関係がなく、したがって技術的に比較評価する明確な理由もない
      ただし社会的反応はテクノロジー崇拝の流れであり、長く経験してきた多くのエンジニアが疲れるのも無理はない。非現実的な主張はいくらでも見つかるし、最悪なのはAI企業のCEOたちから出てくる
      同時に、本当に多くの人が事実上コンピュータ音痴だ。基本的な自動化にすらほとんど触れたことのない人たちには、どれほど興奮する出来事に見えるか想像できる。SFでおなじみの「話すコンピュータ」が、ほとんど現実になりつつある
      数年前、AI以前に機械学習と自然言語処理をやっていたが、最も際立っているのは、この分野で起きたどんな出来事よりもはるかに主流になったという点だ。その分、統計的推論を前提に設計する経験が乏しい人も増えた。当面は、意見、成功した実装、現実的なプロジェクト案を学ぶあらゆる面で西部開拓時代になるだろう
      こう考えればいい。今では、小説のようなアプリのアイデアを持ってくる友人に、自分で作ってみろと言える。それは少なくとも誰にとっても利益になる
    • その手作業のデータパイプライン業務をしている各正社員は、同時にその仕事を検証してもいる。そして、期限どおりに正確に行うというコンプライアンス上の責任もある
      解雇されないための生存本能、よりよくやろうとする野心、変な管理者を別ルートで報告する倫理観や判断力のように、会社に感情的に投資している部分もあり得る
      LLMは、文脈外の理由で値がおかしいと見たときに、組織内の別のノードに電話して確認したりはしない。たとえば、昨日は一回限りの銀行休業日だったので値は0であるべきだ、というような状況だ。これらの数字が正確であることを保証するのには、正社員の年収に見合う価値があるかもしれない。そして正確でなかったときに責めたり、解雇したり、刑務所に送ったりできる人間がいることにも価値がある
    • ソフトウェアエンジニア1人につき手作業のデータパイプライン要員が100人というのが、どの会社で事実なのか気になる。誰かがホワイトカラー職500種を全数調査して分類してくれればいいのに
      本当に自動化可能なものはすでに自動化されている。AIが大きな混乱を引き起こすとは思うが、ホワイトカラー職の大半が「メール職」やデータ入力だという見方には非常に懐疑的だ。自分の経験とは合わないし、ここの人たちが過去に取り残されていると言いそうな大規模な官僚的企業でも働いたことがある
    • こうした種類の職務の複雑さを大きく過小評価している
  • 引退したプログラマーです。確率で生成されたコードをミッションクリティカルなシステムで信頼するというのは想像しにくいです。ほぼ正しくて小さな修正だけで済むなら理解できますが、直接の経験はありません。
    主に言いたいのは、LLM はコーディング以外の領域、たとえばブレインストーミング、自由な発想、調査の細部を埋めること、自分を振り返らせる質問を投げかけることでは驚くほど有用だということです。LLM を思考のパートナーのように扱っています。間違いはしますが、別の出典で確認したり、別の LLM に結論を検討させたりすれば簡単に見つけられます。

    • 特定の経験を代弁することはできませんが、私は何事にもかなり懐疑的なほうなのに、あらゆる面で期待を上回っています。
      24時間もかからずに何かを作れましたが、これを始めるだけでも数か月はかかったはずで、今のように磨き込まれたバージョンにたどり着くにはさらに時間がかかったでしょう。最も印象的なのは、自分にもできることをより速くやってくれる点です。さらに印象的なのは、自分には到底できず採用するか外注するしかなかったことまで、はるかに少ないお金と時間で、他人とやり取りするより速い反復速度でやってくれる点です。
      完璧ではなく、ときには非常に苛立たしいです。明示的にやるなと言ったのに値をハードコードしたり、特定の修正をしたと嘘をつきながら実際にはまったく関係のない別のものを変えたりもします。それでも私の考えではゲームチェンジャーです。
    • しばらく「思考のパートナー」というアプローチを試して、少しの間はうまくいっているように思えましたが、ある時点でほころびが見え始め、見せかけに気づきました。LLM は、自分が知っていて推論できるかのように見せることには極めて優れていますが、知的な対話を発展させることはあまり得意ではありません。
      特に新しく触れる分野で知識を引き出そうとすると、LLM に誤導されやすく危険です。通常の検索エンジンを使えば、出典サイトを見て信頼性を判断できますが、LLM にはそれがありません。出力は実質的に何でもあり得るし、誤りを必ず簡単に見つけられるという点には同意しません。
    • 40年間プログラミングしてきて、数か月前から LLM を使い始めましたが、作業の仕方が本当に変わりました。コード片を書かせたり、ログのエラーメッセージを貼り付けるとたいてい1分以内に修正案を出してくれたり、アーキテクチャや新しい解決策のブレインストーミングにも使っています。
      もちろん書かれたコードは確認しますが、その知能と正確さにはほぼ毎日驚かされています。暗号資産とはまったく違います。
    • LLM 懐疑派として言うと、熟練した開発者が書くコードを含め、あらゆるコードは本質的に確率的です。だから重要なプロジェクトにはコードレビュー、単体テスト、ペアプログラミング、ガイドラインと安全策があります。
      LLM の出力を無批判に使っているなら、それは使い方を間違えていますが、人間の出力も無批判に使えば同じく間違いです。
      ただし LLM は魔法ではなく、人々が copilot やエージェントモデルなどで悪いエンジニアリング慣行を覆い隠し、長期的に重要な効率性・安全性・再設計の代わりにボイラープレートをさらに積み上げるのではないかと心配しています。
    • LLM が極めて得意な領域が一つあり、それがデータサイエンスです。入出力が明確に定義されていれば、結果が正しいかどうかは簡単に検証できます。データの特定の性質を知っているなら、テストを書いてもらうこともできます。
      問題は、LLM に自分が何をしているのかという文脈を与える必要がある点ですが、ChatGPT 式のチャットではその文脈を与えなかったり、面倒で与えられなかったりします。ここで Claude Code が流れを変えます。
      たとえば、各 UDP パケットに複数のメッセージが入っている PCAP ファイルがあるとしましょう。IP、ポート、プロトコル、時刻をどうフィルタリングするか。LLM を使って出力を確認すればよいのです。パターン A、AB、AAB、ABB などを持つパケット数をどう見つけるか。LLM を使って出力を確認すればよいのです。テスト用にそうしたパケットだけが入った PCAP をどう作るか。LLM を使って出力を確認すればよいのです。
      コードも読めるので、率直に言ってあなたの仕事が特別なわけではないため、何をしようとしているのかをはるかによく推論できます。いずれにせよ、「上の関数すべてに対する単体テストを書いて」と言えるという事実だけでも、自分で検証する助けになります。
  • 「ほとんどの懐疑派や批判者と同じく、私もこれらのツールを毎日使っている。そして50%の場合に50%くらい動く」という言い方がありますが、私は約1年前から仕事でほぼ毎日 LLM を使っており、自分の問題の約**90%**を解決してくれます。
    こうした AI/LLM への不満を真剣に受け止めるべきなのか、それとも一部ユーザーの非合理的な利用パターンと見るべきなのか、判断が非常に難しいです。たとえば私は、LLM にコードベースを食わせて魔法のように動くことを期待したことはありません。自分の理解の範囲内で直接的かつ具体的な質問をし、解決策を意図的にテスト可能な形で適用しています。
    それとは別のやり方で臨みながら LLM に不満を言っているなら、使い方を間違えていると見るほうに近いです。そして、小さく有用で、かなり一貫した本物の魔法を見逃しているのです。

    • 「60%の場合、常に機能する」という The Weatherman のセリフを実質的に引用した形です。
      私も Cursor 経由で gpt と Claude を毎日使っています。gpt o3 は一般知識の検索にはかなり良いです。Claude はよく崩れますが、トークンを浪費しながら自己顕示をしている間に、実際の問題に関係するポイントに触れることがかなりあるのも見てきました。
      モデルは愚かで、天才的な馬鹿というより単なる馬鹿に近いです。それでも、ときどき関係のある項目を当てます。自分が何が起こるべきかをおおよそ分かっていて、LLM を農場の野原にいるネズミ捕りのテリアのように扱えば、うまく活用できます。
    • この発言も、筆者が問題視したコメントよりましとは言えません。
      90% という数字も少し怪しく見えます。
  • この記事は、言説の不正確さに腹を立てているように読めますが、その不正確さは正直なところ、支持者より反対者側により蔓延しています。支持者はたいてい、欠陥や限界に毎日向き合わなければならないからです。
    LLM 周辺のすべてが魔術的思考だという結論は、かなり傲慢に見えます。過去5年で、翻訳、文字起こし、一定規模までのコード生成のように、以前はほとんど扱いにくかった問題が完全に、またはほぼ解決されたからです。

    • 反対者はたいてい実際の欠陥を指摘します。支持者はたいてい具体的な詳細なしに、LLM をどんな問題でも一発で解決できる奇跡のように無批判に持ち上げます。
    • 翻訳、文字起こし、一定規模までのコード生成がほとんど扱いにくい問題だったって?
      Google TranslateWhisper、コード生成器は、LLM なしでもかなり前から存在していました。
  • 「暗号通貨がまた戻ってきた」という話について言うと、暗号通貨は私にとって命綱です。私が住む国では、自分では制御も解決もできない理由で銀行口座を開けないからです
    だから暗号通貨があなたにとって役に立たないなら、それは幸いです。私や私のような数百万人にとっては生死に関わる問題です
    LLMも同じように、ある人にとっては魔法であり、別の人にとっては信頼できる決定論的なツールであり、同時に魔法でもあります。たった今、数百枚の請求書を分類して整理しました。そう、魔法です

    • これは実質的に暗号通貨の唯一のユースケースであり、明示的に設計された目的でもある検閲耐性です
      だから合法経済の中で暗号通貨が役立つことを見つけるのが難しいのです。政府が望まない、あるいは促進できない取引を可能にするよう設計されているからです。場合によっては人道的な応用があり、違法な応用も多くあります
    • どんな状況なのか、もう少し説明してもらえますか?どの国にいて、そこで暗号通貨をどう使っているのですか?
    • 「暗号通貨の本当の意味を信じないなら愚か者だ」というような馬鹿げた誇大宣伝の中で、これは有効なユースケースです
      「その場にいなければ信じられない」 https://x.com/0xbags/status/1940774543553146956
      AIブームも今、似たような時期を通過しています。どんな批判も、何も知らない愚か者の言うこととして片付けられます
    • 実のところ、投稿者の冗談と反対のことを言っているわけではないと思います。あなたは暗号通貨を通貨として使いたいのに対し、元の投稿はおそらく投資対象としての暗号通貨周辺の詐欺を指していた可能性が高いです
      通貨として使うなら、コインをパンプ&ダンプして金儲けの手段にしようとする人たちはあなたの敵です。暴騰と暴落のジェットコースターではなく、安定しているほどあなたにとっては良いのです
    • 暗号通貨が抱えているのと同じ問題です。ほとんど全員が技術について嘘を広めており、その多くは自分が嘘をついていると分かるほど理解していないだけです。無邪気さと悪意の違いです
      暗号通貨のほうには意図的な嘘がより多く、得られる価値はより少ないと見ていますが、どちらの場合も、実際に利益を得られる人たちが、不誠実さと歪曲のせいで入り口に立つ前に引き返しています。そしてどちらの場合にも、今日実際に価値を得ている例は存在します
  • 少し関連した話ですが、最近のAGIという用語、時にはAIという用語の使われ方にいら立ちます。特に科学論文では、すべてがきちんと定義されていると期待しますし、少なくともその論文内での使い方はそうであるべきです
    なぜAGIとは何かという定義を作れないのでしょうか?そうすれば、どのAIがその定義に当てはまるのかを論理的に証明することもできます。実用的には大して役に立たないように見えても、意味もなく用語を使うより理論的にはずっと有用です
    今は一種の逃げ道のように感じます。Wikipediaには「ほぼすべての認知課題において人間の能力と同等か、それを上回るAIの一種」とあります。これをどう測るのでしょうか?あるシステムがこの性質を持つと証明できないなら、何の意味があるのでしょう?
    少し愚痴ですが、それでもある程度読まれてほしいです

    • 全体的な合意が必ず必要なわけではありません。私は何がAGIなのかについて、より寛容な自分なりのマイルストーンを持っていますが、他の人が共有してくれるとは期待していません
      私にとって「crypto」が今でも暗号通貨ではなく暗号技術を意味するのと似ています。時には主流派がただ別の意見を持っているだけです
    • 定義はすでにあります
      AIとは、まだできていないことである」[1]
      1. https://en.wikipedia.org/wiki/AI_effect
  • 最近、会社でLLMを使い始め、最初の作業は顧客通話2万件を文字起こししたうえで、次の情報を抽出することでした

    1. 当社の製品が通常どの製品と比較されているか
    2. ユーザーが当社のソフトウェアでどんな問題を経験しているか
    3. ユーザーが最も頻繁に言及するユースケースは何か
      以前なら数週間かかっていた調査が、数時間で終わりました。新しい戦略を立てる助けになり、実際のビジネス価値を生みました
      LLMは単なる自然言語処理エンジンだと見ており、その用途には優れています。誰かが誇張しているのは確かですが、私たちの事例で本当に役に立ったという事実は変わりません。「LLMは悪い」という記事がなぜこんなに多いのか分かりません。自分に合わないなら、そのまま通り過ぎればいいのです。なぜ誰かが誰かに何かを証明しなければならないのでしょう?単なるツールです
    • 誇大宣伝が生み出す悪影響を過小評価しています。市場を歪め、過剰投資を呼び込み、部門を先回りして縮小させ、決して満たされない期待を作ります
      こうした記事は期待を冷ますうえで重要です。人々がLLMを売るとき、たいてい顧客サポート通話の要約を語っているのではなく、顧客サポート担当者を解雇できるという考えを売ろうとしているのです
    • 本当にその通りです。LLMに実際の使い道はないと言う人たちは、大量のデータをかなり安定した方法で処理しなければならない問題に直面したことがありません
      長年、ウェブ上の翻訳の大半には文脈がありませんでした。今では文脈を持てるようになっています
  • 慎重な見解で知られる、信頼できて合理的な技術界の人物たちが、さまざまな形の生成AIを使ってプログラミング作業で大きな改善を得たと報告しています
    ここで大きいとはどの程度でしょうか?5%から100%の間、つまり無視できない水準です
    少なくとも、生成AIがかなりの数の人にとってかなり有益なツールである、あるいはそうなり得ると言うのは安全です
    この程度の判断が合理的であるために、CPU数、コード行数、処理したバイト数のような詳細をすべて公開しなければならないわけではありません

    • 「人々が、私が作った適当な数字と、もう一つの適当な数字の間のどこかの生産性向上を主張している。私たちはこの主張を無批判に信じるべきだ」と言っているのと変わりません