- ChatGPTやローカルLLMは、熟練したプログラマにとって、コードを書くこと自体よりも、文書の探索、複雑なAPIの学習、すぐ捨てるプログラムの作成といった 消耗的な作業 を減らしてくれる道具になっている
- LLMは超自然的な知能ではなく、訓練データ空間の中で限定的に 補間 しているにすぎないが、プログラミングのように良質なデータが多い領域では「物知りなバカ」のように有用である
- PyTorchのテンソル変形、macOSのObjective-C BLEクライアント、ONNXモデルの入出力解釈、CSV分析スクリプトのように、結果を 検証できる問題 ではGPT-4が作業時間を大幅に短縮する
- Cベースのシステムプログラミングやアルゴリズム実装のように複雑な推論が必要な作業では、Bloom filterのハッシュ設計や llama.cpp のQ6_K量子化フォーマット解釈で限界が露呈する
- プログラミングの多くが既存パターンを少し変えて繰り返す仕事だとすれば、LLMをうまく使う能力と問題を明確に説明する能力がより重要になる
熟練したプログラマがLLMを使う理由
- LLM活用の目的は、単にコードをより速く書くことにとどまらない
- 変わった文書検索
- 過度に複雑なAPIの学習
- 数時間後に捨てるプログラムの作成
- 知的に面白くない細部の処理
- Googleがスパムの多い検索空間になったことで、LLMは必要な情報を素早く得るための 代替経路 になっている
- Pythonのような高水準コードではLLMの利用が増えたが、Cコードでははるかに少ない
- 重要な違いは、いつLLMを使えば速くなり、いつ逆に遅くなるのかを見分けることにある
- LLMはWikipediaやYouTube講義のように、意志・能力・規律のある人にとっては大きな助けになる一方、遅れている人には限界があるかもしれない
LLMは全知全能でも、単なるオウムでもない
- ニューラルネットワークとLLMの内部動作はいまだかなり 不透明 である
- 一部のAI専門家はLLMを高度なMarkov chainや訓練データの変形を吐き出すシステムとして過小評価していたが、そのような「オウム」観は証拠を前にして大半が撤回された
- 反対に、LLMに現実には存在しない超自然的能力を与える態度も不正確である
- LLMは訓練中に見たデータが構成する空間の中で、限定的に補間できる
- 正確には見たことのないプログラムも書ける
- 訓練データに頻出した複数のアイデアを混ぜられる
- 微妙な推論が必要になると大きく失敗することがある
- こうした限界にもかかわらず、LLMはAI史上最大級の成果と見なせる
「物知りなバカ」としてのプログラミング支援
- LLMは初歩的でしばしば不正確な推論、幻覚、存在しない事実の生成を起こしうる
- 同時に、プログラミングのように質の高いデータが多い領域では、膨大な知識を持つ savant のように働く
- 一緒にペアプログラミングする同僚としては不足かもしれないが、利用者が質問を投げ、答えを検証する構造では有用である
- 以前は、いくつかの言語、古典的アルゴリズム、主要ライブラリだけ知っていれば多くの仕事ができた
- 今ではフレームワーク・言語・ライブラリの爆発的増加で複雑性が大幅に高まり、この環境では「何でも知っているバカ」が役に立つ同僚になる
高水準コードとデータ解釈での成功例
- KerasからPyTorchへ移行する際、LLMはPyTorchの文書を最初から勉強しなくても、モデル構成に必要なコードを書く助けになった
- 利用者はembeddingやresidual networkのような概念をすでに理解していた
- 必要なモデル構造と質問を明確に示すやり方が効果的だった
- GPT-4はPyTorchモデルとbatch形式を見て、ニューラルネットワーク入力に合わせてtensorをreshapeするコードを書いた
- 利用者はPython CLIでtensorの次元とデータbatchが合っているかを確認した
- ESP32ベースのデバイス向けBLEクライアントを作る際、macOSネイティブAPIを使うためにObjective-Cコードを素早く書いた
- マルチプラットフォームBluetoothバインディングは概ね使えないと判断した
- Objective-C BLE APIと、昔使っていたObjective-Cの細部を再び扱う必要があった
- 最終コードは SerialBTE.m にある
- LLMがコードの大半を直接書いたわけではないが、問題の原因と解決方法を説明してくれることで、作成速度を大きく高めた
- この補助プログラムは、投入した労力に対する見返りが小さく、ChatGPTがなければそもそも試さなかった可能性が高い
ONNXモデル解釈と捨てるプログラム作成
- 文書が乏しいONNX形式のconvnetを使う際、LLMは入力・出力メタデータとテスト画像のraw output値をもとに動作方式を解釈した
- 当初は入力画像の形式とサイズが分からなかった
- 出力は単純な二値分類ではなく、数百の値で構成されていた
- ChatGPTは出力が画像内の潜在的な欠陥領域を示すnormalized boxと、欠陥の可能性を表しているのではないかと推定した
- 数回の対話の後、Python inferenceスクリプトと入力tensor変換コードができあがった
- 「捨てるプログラム」では、LLMにコード全体を書かせることもある
- 小さなニューラルネットワーク学習中のloss curveを可視化するために、GPT-4はCSV形式を見て plot.py を生成した
- 複数のCSVファイルをコマンドラインで渡すと、各実験のvalidation loss curveを比較するよう依頼した
- 作業全体は30秒で済んだ
- AirBnBのCSVレポートを読んで、アパートごとに月・年単位でまとめ、清掃費と宿泊日数を考慮して月ごとの平均賃料を計算するpandasプログラムも一発で動いた
- この種のプログラムは、書くこと自体が退屈で面白みに乏しいため、LLMに任せれば利用者は重要な作業に集中できる
Cとシステムプログラミングで露呈した限界
- Cプログラムを書くとき、LLMはほとんど常に、より便利な文書形式として使われるだけである
- システムプログラミングでは複雑な推論が必要であり、現在のLLMはこの点でしばしば失敗する
- Bloom filterの実装を依頼したとき、GPT-4は100,000個の要素と最大5%のfalse positive probabilityという条件を受け取ったが、良い実装を出せなかった
- 似たようなhash functionを2つしか使わなかった
- 同じ文字列からK個の十分にdecorrelatedなhashを作る抽象化が不足していた
- 明示的にN個のdecorrelated outputを作れと求めると、より良いhash functionを提案した
- GPT-4は小さな部分問題に分ければ、より適切なハッシュ関数を書けたが、Bloom filter全体設計ではそのアイデアを自力で適用できなかった
- こうした結果は、弱い推論能力、話題別資料の不足、低品質な資料が混ざった影響として見られる
ローカルモデルと大規模モデルの違い
- システムプログラミングの問題では、小さなモデルと大きなモデルの差がはっきりしている
- Mixtralは同じhash_id問題で、hash結果の末尾に
hash_id を足す方式を提案し、これは非常に悪い解決策と評価された
- deepseek-coder 34Bを4ビット量子化してMacBook M1 Maxで実行した結果は、より良好だった
- 利用者がhash_idを末尾に足すと分布が悪化するというヒントを与えた
- モデルは単純加算が問題の原因かもしれないと特定した
- XORなどのbitwise operationで
hash_id を混ぜる代案を提案した
- この事例は、文書やGoogle検索だけでは得にくい種類の問題原因の特定と解決提案に近い
- それでも、熟練したシステムプログラマにとって、LLMは概してまだ満足のいくソリューションをほとんど提供できていない
llama.cpp Q6_Kフォーマット解釈の事例
- ggufflibプロジェクトは、llama.cppが量子化モデルをロードするときに使うGGUF形式ファイルを読み書きするライブラリである
- 量子化エンコーディングでは、速度のために各quantのbitが複雑な方式で保存されている
- 最初はChatGPTでエンコーディングを理解しようとしたが、llama.cppのコードを直接リバースエンジニアリングする方がはるかに速かった
- GPT-4のcontextに入る程度に関数は小さかったにもかかわらず、構造体宣言とdecoding functionを見てデータフォーマット文書を再構成した結果は役に立たなかった
- Q6_Kフォーマットの説明を求めた場合でも、lower/upper bitがweight位置に応じて
ql と qh に保存される方式を明確に説明できなかった
- より単純な保存方式を説明する関数を求めたときも、インデックスが間違っていた
- 6-bitから8-bitへのsign extension処理も誤っていた
- この作業は最終的に、紙とペン、コードの読解、decoderが取り出すbitの追跡によって解決された
- この種の作業も、ブレークスルーなしでも少しのスケーリングだけで数か月以内に可能になる範囲だと予想される
プログラミング作業の性質とLLM活用能力
- 今日のプログラミングのかなりの部分は、同じものを少し違う形で繰り返す仕事であり、高度な推論を必要としない場合が多い
- LLMはこうした反復的プログラミングにはかなり強いが、contextサイズの制限は依然として大きな制約である
- LLMが一部を実行できる種類のプログラムだけを書くことが、5年後や10年後にも良い立ち位置なのか考える必要がある
- LLMの推論能力は弱く不完全だが、単なる単語の吐き直しだけでは観測される結果を説明しにくい
- 次token予測という学習目標は、何らかの 抽象モデル を作ることを強制しており、そのモデルは弱く、穴が多く、不完全である
なぜ今LLMを使うのか
- プログラミングでLLMを使わない理由は乏しい
- LLMに正しい質問を投げる能力は重要なスキルになる
- 問題を明確に説明する能力は、LLMだけでなく人とコミュニケーションするときにも有用である
- 多くのプログラマは特定分野では優れていても、コミュニケーションが不足していることがある
- Googleが使いにくくなった状況で、LLMは圧縮された文書のように使うのにも向いている
- 曖昧な通信プロトコルや複雑なライブラリ詳細のような「junk knowledge」を、あまり直接学ばずに済むようにしてくれる点がLLMの実用的価値である
1件のコメント
Hacker Newsの意見
核心はこの部分：「ChatGPTなしでもできただろうか？ もちろん可能だっただろうが、より時間がかかったという事実がいちばん興味深いわけではない。実際には、それだけの価値がないので、そもそも試しすらしなかっただろう」
コード支援におけるLLMの本当の可能性は、新しい作業を始めるハードルを下げ、将来のプロジェクトの山に無期限に残っていたはずのことを実際に手に取り、完了させる点にある
インターネットやオープンソースにも似た効果があり、関心はあるが自分ではやっていないプロジェクトも、時間がたつと誰かが似た問題を十分に解決して、再利用したり改変したりできるようになり、使えるアプリやライブラリが爆発的に増えた
LLMは単独ではそれほど有能ではないが、基本的なスキルと動機を持つ人にとっては増幅器になる、という著者の言葉に同意する
すると、予想よりはるかに少ない労力でできると気づく
適切な相手とアイデアをやり取りしても似た効果は得られるが、問題領域を完全に知っている必要はなくても、意味のある入力をくれる程度の人が24時間、クリック一つで待機しているわけではない
いくつかのことには役立ったが、たいてい自分が何をしているのか分からない地点に来ると、モデルも自分よりよく分かっているわけではない
それ以外では、単に自分でコードを書くより速くプロンプトを組み立てるのが難しい
自分がこれらのツールを使いこなせていないのか気になる
ow2 asmライブラリのことはかなり知っていたが、正確なディスクリプタ形式を思い出すために調べ回る時間を大きく節約してくれた
また、ほかの静的解析ライブラリが状態を扱う理由から、なぜ自分には十分でないのかを理解する助けにもなった
自分にとってChatGPTは二つのことをする：些細なStackOverflow検索やライブラリコードの探索を減らして特定の質問に答えさせてくれること、そして開始前のプロジェクト調査段階で、自分が取ろうとしているアプローチの実現可能性を把握させてくれること
重いADHDがあると、単純なことが最も難しく、ゴミを出すことや郵便物を開けることすらほとんど不可能になる
頭の中の会話は何時間もただその作業をしろと叫び続けるが、体が言うことを聞かない
これを実行機能障害と呼ぶが、自分の人生の悩みの種だ
LLMがその作業を始めさせてくれることだけでも、とてつもなく大きい
プログラミングに関しては完全に同意する
LLM利用の最適なポイントは、すでにそのテーマについて成果物を検証できるだけの知識があり、望むものを詳細に、できれば要点だけで説明できるほど理解している場合だ
より速く進められ、本来ならやらなかったこともやれるようにし、捨ててもよい小さく価値のあるプログラムを作るのに大いに役立つ
もう一つ非常に有用だった領域は、プログラミングかどうかにかかわらず、まったく新しいテーマの探索だ
自分はよく分かっていない、具体的な事項は必須ではないがこういう話をしたいし考えを整理するのを手伝ってほしい、と言えばよい
聞いた内容をもとに追加調査したり、さらに質問したりする意志のある人には特に有用だ
多くの分野への入口は、基本用語を理解し、人々がどのような区別をしているのか、そしてなぜそうなのかを聞き、そのテーマの権威が誰なのかを知ることにある
理解できない怪物を作り出すまで突き続け、ビルドだけ通すという状況が生まれる
学ぶ人には助けが必要だが、Copilot形式のLLMが与える助けは正しい形ではない
ジュニアの曖昧だったり誤って指定されたりした質問に何とかコードを生成しようとするのではなく、明確化の質問をし、一緒に解法を決める相棒として設計されたCopilotモデルを訓練すると面白そうだ
毎回、微妙に間違っているか、まったく幻覚による前提を出してきて、それが間違いだと気づくまで時間を無駄にした
間違った答えを不当に確信している態度さえなければ、自分の知っていることをつなぎ合わせたものより大きく悪いとは言えなかったかもしれないが、現状ではラバーダックやオートコンプリートの代替程度なら問題ない
新しい言語のウェブサイトに行って、そのドキュメントについて会話し質問しながら理解を助けてくれるLLMがあるとよい
その言語やフレームワークの実際のコード例で訓練されていて、その場で新しいプログラムや関数を書くのを助けてくれるならさらによい
オンラインREPLとつながってインラインで助けてくれるなら、さらに大きな利点になる
LLMで最も過小評価されている側面は、記事では触れられていたものの直接扱われてはいなかった、何でも知っている開発者のような役割だと思う。
どれほどシニアなプログラマーでも、結局はほとんど知らない技術に直面することがある。
誰もがどこかの領域ではジュニアである。
Win32、C++、COMの神であっても、ソフトウェアをパッケージングするときに難解なNSISスクリプトで詰まることはあり得る。
25年間Webアプリを作り、PHP言語委員会に参加していたとしても、クレジットカードネットワークと通信する難解なISO標準を実装する仕事を任されたら、そのレベルでクレジットカードネットワークと通信した経験はないかもしれない。
初代iPhoneの頃からiOSアプリを作り、その前はMacアプリを作っていて、Appleで何年も働き、iOS APIの大半を暗記し自ら設計までしていたとしても、アプリにCalDAV対応を実装する仕事を任されたら、CalDAVが何なのかすら知らないかもしれない。
こうした状況でLLMは助けになり、すべてのコードを書いてくれることはできなくても、少なくとも正しい方向へ導くことはできる。
頭の中を別の技術で満たしたあと、以前学んだものの新しい技術のせいで脇に追いやっていた内容を、再び思い出して復習しなければならない時が来る。
妙な感覚だ。
自然と自分の会社がやっている仕事の中央値に寄っていき、CSSを触ってから「しばらく経ったな」と感じる状況に置かれる。
Python dataclassの感覚を取り戻すために、週末に勉強が必要になるかもしれない。
Googleで見つけられるものなら、LLMのほうがより速く、よりうまく見つけて整理してくれる可能性が高い。
幸い、私はその頃にはすでに引退している可能性が高い。
「コードの大半はChatGPTから切り貼りして書いた」という流れに驚く。
こんな苦痛なワークフローを我慢している人が多いことに、ずっと衝撃を受けている。
元記事の著者は、GPTで自分の知識以上のコーディングをしている初心者ではなく、明らかに熟練したエンジニアである。
普通ならコーディングのワークフローやツールの使いやすさ、効率を気にする人のはずなのに、多くの人がGPTとローカルファイルの間でコードを延々とコピー＆ペーストすることに耐えている。
このもどかしいワークフローこそ、最初にaiderを作るきっかけだった。
aiderはローカルのgitリポジトリをGPTと共有し、新しいコードや修正がファイルに直接適用されるようにする。
関連するコードの文脈もGPTに共有するため、プロジェクトに統合されるコードを書ける。
そのため、コピー＆ペーストしやすい孤立したコードだけでなく、より精巧な貢献も可能になる。
結果として、会話しながら私とGPTが一緒にファイルを編集する、なめらかなペアプログラミングのワークフローになる。
https://github.com/paul-gauthier/aider
ただ、コードについて単に会話する用途で使う方法はあるのだろうか？
私は複数のアプローチの長所と短所を話し合ったり、問題をラバーダック的に解きほぐしたりするためにLLMを使っている。
そのためにはコードをコピーする必要があるが、aiderは変更の適用に重点があるので、この用途にはあまり合わなかった。
たいていは正しい方法について何度もやり取りした後で、変更を適用するかどうかを決める。
彼はRedisの創始者だ。
すでにサブスク料金を払っているなら、APIに追加費用を払うよりコピー＆ペーストするほうが理にかなっている。
さらに、効率向上が他人のプロジェクトに依存するほど価値があるかどうかの基準は人によって違うし、そうしたプロジェクトには有料化されたり放置されたりするリスクもある。
最初に実際のファイルで試したものは大きすぎて破綻し、2つ目の実ファイルもやはり大きすぎた。
aiderが大きなファイルをトークン制限に合わせて分割できないように見えたのは驚きだった。
GPTのトークン制限は、それほど大きなソースファイルを収められない。
自分で作業するファイルを選び、GPTが吐き出さないように手術までしなければならないなら、IDEのCopilotを使うより時間が節約できるのか分からない。
最初は「コードサイズ ≫ トークン制限」問題に対処することがaiderの核心的な貢献だと思っていたが、そうではなかったようだ。
もう一度試してみたい気持ちはあるが、aiderは「aiderが扱えるほど単純な問題とコードベースを見つけなければならない」という不利なカテゴリに入っている。
一方でCopilotとChatGPTは、実際の職場で実際のコードベースの欠点も含め、毎日こちらに来て助けてくれる。
現在の機能で、チャットと確認のユースケースを見事にカバーしていると思う。
ここのコメントが、ソフトウェア利用者の大多数の高い満足度を反映していない可能性もある。
Aiderは、antirezが記事で述べたユースケースを実際に実行できるよう助けてくれる。
特にantirezが言うように、LLMに正しい質問をする方法が上達するほど、なおさらそうだ。
ここ数日、クローズドソースのMacアプリのバグを直そうとしていた。
そのアプリは好きだが、このバグには何年も気が狂いそうにさせられてきた。
どのObjective-Cメソッドがおおよそそのバグを引き起こしているのかはかなり確信していたが、そのメソッドが何をしているのかは分からず、デコンパイルされた版は意味不明なごちゃごちゃだった。
壁にぶつかった気分だった。
そこで、デコンパイラが吐いたノイズをGPT-4に入れて、きれいな版に変えてほしいと頼んでみた。
結果は完璧ではなかったが、自分で整理できる程度にはなり、それをアプリにスウィズリングしたところ、バグは消えたようだ。
再現手順を見つけたことはないが、通常なら今頃は問題が発生している時期だ。
GPT-4なしでは絶対にできなかったことだ。
もちろん、コード片を完全に書き直せば、何をしているのか理解せずにLLMを使ったとしても、元の実装と同じバグが残る可能性は低い。
ただし別のバグが生まれる可能性はあるし、システム停止や顧客コストのようにバグの結果が重大なコードでは、誰にもこんなやり方をしてほしくない。
この記事は自分にとって完全に衝撃的だ
Salvatoreは、今日活動している最も有能なソフトウェアエンジニアの一人だ
彼は、このいわゆるツールが自分の専門領域ではまったく役に立たないことをはっきり見抜ける
それなのに、合わずに曲がったドライバーのように捨てる代わりに、何とか使い道を見つけなければならないという擁護者たちの前提を受け入れている
入門マクロ経済学の授業で学ぶように、ある島がウィジェットAの生産に優れていれば、別の島のBの生産能力がどれほどひどくても、A島がB島を活用する専門化が生まれる
だから、antirezのシステムプログラミングにおける相対的な能力が、LLMを別のプログラミング作業へ押しやるのは当然だ
しかし私たちは孤立して存在しているわけではない
周囲には、技術的な挑戦と食べ物を求める多くの人間がいる
その多くは、私たちと相補的なスキルを持っているか、得ることができる
一緒に働けば、協力の成果は部分の総和を超えうる
もしかするとLLMはantirezよりPyTorchコードをうまく書けるかもしれない
だがガレージに古くて曲がったドライバーがあるからといって、必ずそれを使わなければならないわけではない
今日、金物店へ行くほうがよいかもしれない
正確な構文やテンソルのreshapeは、私にとってそれほど重要ではないからだ
自分の画像向けにConvNetを作って学習させる個人的な用途なら、Torchの専門家を煩わせる必要はない
ConvNet自体は十分理解していて、Torchの構文やメソッドを十分知らない程度なら、自分でできる
代替案はTorchのマニュアルの細部を勉強することで、結果は同じだろう
この作業で重要なのはMLX、Keras、PyTorchの細部ではなく、機械学習の概念を制御することだ
今はある程度有用だが、本当にそうだとは言いにくいし、使わないからといって「遅れを取る」わけでもない
関係者全員がより有能にしようと全力を尽くしているのだから、その日が来たら望むことをプロンプトで指示すればよい
今の世代から無理に何かを絞り出そうと急ぐ必要はなく、現時点では生産性を上げるより下げる場合が多い
同じ記事を読んだのか疑問に思うほどだ
彼は、他の人たちが興味深いと感じた新しいツールを見て、自分に役立つ使い方を見つけ、同時に役に立たない点も認めている
役に立った例も十分に裏付けている
開発者にとって特に革命的な洞察ではない
私たちはプログラミング言語のようなさまざまなツールを常に使っており、それぞれのツールには強みと弱みがある
LLMだけがなぜそれほど違うべきなのか分からない
強みがまったくないと主張するのは愚かに見える
それを月20ドル未満でできるのか？
新しいプロジェクトを始めるときにはインピーダンスの問題がある
最初は作業が0%完了の状態で、hello worldであれCMakeListsファイルであれPythonスクリプトであれ、どこかから始めなければならないが、それがつらい
ChatGPT/LLM以前は、その労力を自分の中から指先へ引き出さなければならなかった
今はChatGPTに任せられる
実際には「座って自分でやった場合」より効率も低く、強力でもないが、「座って自分でやると決める」コストをなくしてくれる
それでもGitHubのコード検索、StackOverflow、ランダムなブログ記事、ドキュメント、Discordなどからコピーした断片を写してつぶしていくのと同じだ
何度か試行と再試行を重ねた末に、プロジェクトの5%分の出発点ができ、ようやく形が見えてくると本当に作業できる
結局、ChatGPTが吐き出した浅いゴミのような概念実証をコピー＆ペーストして素早く作り、十分な勢いがついたら自分で深掘りするやり方に切り替える
だから、より遅く非効率で、ChatGPTが私より得意なわけでもないが、より楽で、深く掘らなくてもよい
最終的に、プロジェクトの本当に重要な部分である中盤と終盤でずっと粘れるようになり、序盤で燃え尽きない
最初から正しい問いを立てていたのか、そうでなければその作業を効果的に救い出せるのか？
埋没費用は20ドルのサブスクリプション料金の中へ消えていく
「問題があり、LLMがでたらめを言った場合に自分で検証できる内容を素早く知る必要がある。そういう場合、私は知識が必要になる速度を上げるためにLLMを使う」という箇所が核心的な洞察だと思う
プログラミングがLLMに特によく合う理由の一つは、正解の検証がたいてい些細なことだからだ
LLMがその作業に合ったツールかどうかを評価する概念を試している
「出力が正確でなければならない重要度」と「出力が正確かどうかを検証しやすい度合い」をグラフにしてみるようなものだ
ChatGPTで、Emmyを受賞した女性アーティストが参加した曲の一覧を作る作業は、正確性の検証に時間がかかるが、重要度も低く、多少の誤りがあっても構わない
だからソフトウェアにはバグがまったくないのか？
解法を思いつくのは難しいが、あり得る解法を検証するのは簡単な問題だ
そして、その問題のクラスが何と呼ばれるかは皆知っている
世界はすでに無関係で不正確な駄文であふれており、私たちはその生産を加速するより減らすほうがよい
特定の例の話ではなく、アイデア全体についての話だ
ChatGPTをコード作成の思考パートナーとして使っている
毎日一日中対話しながら仕事を終えている
会社はCopilotを承認したが、Copilotのオートコンプリートはひどい体験だった
会社は私に必要なCopilot Chatは承認していなかった
それでも、自分のノートPC上で自分のコードを対象に、単体テストやコードコメントなどを生成してくれる似たようなツールがあるといいと思う
もちろん、私の入力と指示を前提として
同僚たちがかなり褒めていたので自分がおかしいのかと思ったが、ものすごく気が散り、数日後にオフにした
まだ話している途中なのに、誰かが文を終わらせようとしてくるような感じだった
合っている場合でもいら立ったし、流れが途切れたうえ、非常によく間違っていた
[0] https://continue.dev/
[1] https://ollama.ai/
数日前にCodeninjaを使ってみた
覚えている限り、Copilotのバックエンドを動かしている4にはまったく及ばないが、外部に出してはいけない機密データには実質的に唯一の選択肢だ
あるいはOpenAIで専用インスタンスを用意してもらう方法もあるだろう
この記事で最も重要な箇所かもしれず、2024年に起こることを考えると、いくら繰り返しても言い過ぎではない部分はこれだ
「では、LLMにはどの程度の推論能力があるのか、それともすべて見せかけなのか。記号学者が言うように、『シニフィアン』が実際には存在しない意味の印象を与えるため、ときに推論しているように見えるだけなのかもしれない。しかし、LLMを十分に扱ってきた人なら、その限界を受け入れつつも、それだけでは説明できないことを知っている。以前に見たものを混ぜ合わせる能力は、単語をランダムに吐き返すことをはるかに超えている。訓練の大半が事前学習中に次のトークンを予測する形で行われたとしても、この目標はモデルに何らかの形の抽象モデルを作ることを強制する。このモデルは弱く、穴だらけで、不完全だが、私たちが観察していることを観察するなら、必ず存在していなければならない。数学的な確信が疑わしく、最高の専門家たちでさえしばしば反対側に立つなら、自分の目で見たものを信じるのが賢明に思える」