Levix's zone

最近、私は生成 AI に関する私の立場を明文化するための個人的な倫理声明を作成する作業に取り組んでいます。私は現代の生成 AI のいくつかの 側面について非常に批判的でありながら、その中に参加しています。その声明に取り組む中で、私は自分自身がどのように大型言語モデルを利用しているかを内省してきました。これは、BuzzFeedのシニアデータサイエンティストとしての職業的な仕事や、個人的なブログ執筆やオープンソースソフトウェアの開発においてです。約 10 年間、私は文字生成に関するツールの研究と開発に取り組んできました。これは、GPT-2 の微調整能力から、GPT-3 との実験や、ChatGPT とのさらなる実験や他の LLM API にまで及びます。私は現代の LLM の最良のユーザーを自称するわけではありませんが、次のトークン予測モデルの欠点に対抗する経験を豊富に持ち、その利点を見つけるのが非常に得意になりました。
出乎我意料的是，我使用它们的频率远低于人们想象中工程师应有的水平，但这并不意味着 LLMs 对我毫无用处。这是一个需要具体情况具体分析的讨论。

私が LLMs とどのようにインターフェースを持つか
我如何与 LLMs 交互#

これまでの数年間、私は LLMs から最高の結果を得るためのすべてのトリックを利用してきました。最も有名なトリックはプロンプトエンジニアリングであり、特定の方法でプロンプトを表現してモデルに特定の制約のある出力を生成させる技術です。プロンプトにLLM に対して金銭的インセンティブを提供することや、単にLLM に出力を改善するように指示することを追加することは、元のプロンプトへの遵守と出力テキストの質を改善する上で定量的にポジティブな影響を持ちます。私の同僚がなぜ彼らの LLM 出力が期待通りでないのか尋ねると、私は彼らにもっとプロンプトエンジニアリングを適用することを提案し、ほぼ常に彼らの問題を解決します。
多年来，我运用了各种技巧从 LLMs 中获取最佳结果。最著名的技巧莫过于提示工程，即通过特定方式措辞提示，引导模型生成特定约束下的输出。在提示中添加诸如向 LLM 提供经济激励或直接要求 LLM 优化其输出等内容，确实能在提高对原始提示的遵循度和输出文本质量上产生可量化的积极影响。每当同事问我为何他们的 LLM 输出不如预期时，我建议他们加强提示工程，这几乎总能解决问题。

AI 分野の誰もがプロンプトエンジニアリングに満足しているわけではありません、特に私自身がそうです。より堅牢なRLHFパラダイムでプロンプトエンジニアリングの必要性を排除しようとする試みは、LLM 開発者がより良いプロンプト遵守を利用できるようにすることで、_さらに報酬を増やす_ことになりました。確かに、「プロンプトエンジニア」という職業名はミームになったが、それは主にプロンプトエンジニアリングが LLMs を真剣に使用する人にとって期待されるスキルとなったからです。プロンプトエンジニアリングは機能し、プロフェッショナルであることの一部は、たとえそれが馬鹿げていても、機能するものを使用することです。
在 AI 领域，没有人对提示工程感到满意，尤其是我自己。试图通过更强大的 RLHF 范式消除对提示工程的需求，反而因其能让 LLM 开发者利用更好的提示遵循性而使其回报更高。诚然，“提示工程师” 这一职位头衔最终成了一个梗，但这主要是因为提示工程如今已成为任何认真使用 LLMs 的人必备的技能。提示工程确实有效，而作为专业人士的一部分，就是使用行之有效的方法，即便它看起来有些可笑。

そのため、私は ChatGPT.comや他の一般向けのフロントエンドを使用して LLMs にアクセスすることは決してありません。なぜなら、それらは制御が難しいからです。代わりに、私は通常、各 LLM サービスが提供するバックエンド UI にアクセスします。これは API 機能の軽量ラッパーとして機能し、必要に応じてコードに移植しやすくなっています。ChatGPT API のような LLM API に直接アクセスすることで、生成の「ルール」を制御するシステムプロンプトを設定できます。生成されたテキストの具体的な制約を指定すること、たとえば「30 語以内に抑える」や「‘delve’という単語を使用しない」といったことは、ChatGPT.com のようにユーザープロンプトに入れるよりもシステムプロンプトで指定する方が効果的です。システムプロンプトを明示的に設定できない現代の LLM インターフェースは、ほとんどの場合、制御できない独自のシステムプロンプトを使用しています。たとえば、ChatGPT.com がユーザーに対して過度にお世辞を言うという問題を抱えていたとき、OpenAI は ChatGPT に「根拠のないお世辞を避けるように」と指示するためにシステムプロンプトを変更しました。私はAnthropicの Claude の API、特に Claude Sonnet を ChatGPT のバリエーションよりも多く使用しています。なぜなら、Claude は経験的に「ロボット的」でなく、コーディングの質問にもはるかに正確に対応できるからです。
为此，我从不使用 ChatGPT.com 或其他面向普通用户的前端来访问 LLMs，因为它们更难控制。相反，我通常使用各 LLM 服务提供的后端 UI，它们作为 API 功能的轻量级封装，同时也便于在必要时移植到代码中。直接访问像 ChatGPT API 这样的 LLM API，允许你设置系统提示，这些提示控制着生成内容的 “规则”，可以非常细致入微。在系统提示中指定生成文本的具体约束条件，如 “不超过 30 字” 或 “避免使用‘delve’一词”，通常比在用户提示中设置更有效（类似 ChatGPT.com 的操作方式）。任何不允许显式设置系统提示的现代 LLM 界面，很可能使用了无法自定义的系统提示：例如，当 ChatGPT.com 出现对用户过度奉承的问题时，OpenAI 通过修改系统提示要求其 “避免无根据或谄媚的恭维”。我个人更常使用 Anthropic Claude 的 API（特别是 Claude Sonnet），因为据反馈 Claude 显得不那么 “机械”，且在编程问题上的回答准确度更高。

また、API を使用すると、生成の「温度」を制御できます。これは高レベルで生成の創造性を制御します。LLMs はデフォルトで次のトークンを最も高い確率で選択せず、各生成に対して異なる出力を提供できるようにしているため、私は出力が主に決定論的になるように温度を0.0に設定することを好みます。あるいは、軽い変動が必要な場合は0.2 - 0.3に設定します。現代の LLMs は現在デフォルトの温度を1.0に設定しており、私は高い値がLLM の幻覚の問題を強調していると考えています。つまり、テキスト出力は内部的には一貫しているが、事実としては間違っているのです。
此外，通过 API，你可以控制生成的 “温度”，这从高层次上决定了生成内容的创造性。默认情况下，LLMs 不会选择概率最高的下一个令牌，以便每次生成都能产生不同的输出。因此，我倾向于将温度设置为 0.0 以使输出基本确定，或在需要轻微变化时设为 0.2 - 0.3 。现代 LLMs 现在默认使用 1.0 的温度值，我推测较高的值会加剧 LLM 的幻觉问题，即文本输出内部一致但事实错误。

LLMs による専門的な問題解決！
LLMs 助力专业问题解决！#

この前提をもとに、私は BuzzFeed での過去数年間に生成的 LLMs をどのように使用してきたかについて話すことができます。以下は、LLMs を使用して問題を迅速に解決するために取り組んだ（多くの中のいくつかの）プロジェクトの概要です。
基于上述背景，现在我可以谈谈过去几年在 BuzzFeed 是如何使用生成式 LLMs 的。以下列举了一些（众多中的）我利用 LLMs 快速成功解决问题的项目概要：

• BuzzFeed のサイトキュレーターは、数千の記事を特定のカテゴリとサブカテゴリに整理するための新しい階層的分類法を開発しました。既存のラベル付き記事がなかったため、従来の多クラス分類モデルをトレーニングしてこれらの新しいラベルを予測することができなかったため、私は Claude Sonnet API を呼び出すスクリプトを書きました。システムプロンプトは「次のものは分類法です：ユーザーが提供する記事に最も適したカテゴリとサブカテゴリを返します。」という内容で、JSON 形式の階層的分類法を加え、記事のメタデータをユーザープロンプトとして提供しました。すべての操作は最も正確な結果を得るために温度0.0で実行しました。このスクリプトをすべての記事に対してループで実行した結果、適切なラベルが得られました。
  BuzzFeed 网站的内容策划团队开发了一套新的层级分类法，用于将数千篇文章归类到特定的类别和子类别中。由于我们缺乏已标记的文章来训练传统的多类别分类模型以预测这些新标签，我编写了一个脚本调用 Claude Sonnet API，系统提示设置为 The following is a taxonomy: return the category and subcategory that best matches the article the user provides. 加上 JSON 格式的层级分类法，然后将文章元数据作为用户提示输入，所有操作均以温度为 0.0 运行以获得最精确的结果。通过循环处理所有文章，最终得到了恰当的标签。
• BuzzFeed の記事の数百の異なる意味的クラスターをデータサイエンスの手法を用いて特定した後、各クラスターにユニークなラベルを付ける簡単な方法がないことが明らかになりました。私は別のスクリプトを書き、Claude Sonnet API を呼び出しました。システムプロンプトは「ユーザーが提供するすべての記事に適用される JSON 形式のタイトルと説明を返します。」という内容で、ユーザープロンプトにはそのクラスターからの 5 つの記事を含めました。同様に、すべてのクラスターに対してスクリプトをループで実行した結果、素晴らしい結果が得られました。
  在运用数据科学技巧识别出 BuzzFeed 文章数百个不同的语义聚类后，我们发现难以简单地为每个聚类赋予独特的标签。为此，我又编写了一个脚本调用 Claude Sonnet API，系统提示设置为 Return a JSON-formatted title and description that applies to all the articles the user provides. ，用户提示则包含来自该聚类的五篇文章：同样地，通过循环运行脚本处理所有聚类，获得了极佳的效果。
• ある BuzzFeed のライターが、「ここでエムダッシュを使うべきか？」といった文法の質問を BuzzFeed スタイルガイドに照らして確認する方法があるかどうか尋ねました。再び私は Claude Sonnet API を呼び出しました。今回は、システムプロンプトにスタイルガイドの_完全な_テキストをコピー＆ペーストし、「ユーザーの質問に答えるために提供されたスタイルガイドを参照し、質問に答えるために使用した正確なルールを引用してください。」という指示を加えました。テストでは、引用は正確で、元の入力に存在し、推論も一貫していました。
  一位 BuzzFeed 撰稿人询问是否有办法使用 LLM 来对照 BuzzFeed 风格指南检查语法问题，比如 “这里该用破折号吗？”。我再次调用了 Claude Sonnet API，这次将完整的风格指南复制粘贴到系统提示中，并附加了一条指令 Reference the provided style guide to answer the user's question, and cite the exact rules used to answer the question. 。测试中，引证准确且存在于源输入中，推理过程也保持一致。

これらのプロジェクトはすべて、朝のスタンドアップや Slack の DM で提案されたアイデアでありながら、各プロジェクトは概念実証を完成させ、関連する利害関係者に評価のために引き渡すのに 1〜2 時間しかかかりませんでした。階層的ラベリングのようなプロジェクトでは、LLMs がなければ、より高度な研究開発を行う必要があり、手動でラベル付けを通じてトレーニングデータセットを構築するのに数日かかる可能性があり、これは知的に満足のいくものではありませんでした。ここで、LLMs は確かにパレートの法則に従い、作業ソリューションの 80% を達成しましたが、残りの 20% の作業は反復、テスト、フィードバックの収集に時間がかかりました。モデルの出力がより信頼性を増しても、LLM の幻覚は依然として懸念事項であり、そのため私は同僚にも注意を促し、LLM の出力が奇妙な場合は人間に再確認するように勧めています。
这些项目最初都只是晨会或 Slack 私聊中随口提出的想法，但每个项目仅用一两个小时就完成了概念验证（包括测试）并移交给相关利益方评估。以层级标签项目为例，若没有 LLMs，我需要进行更复杂的研发工作，可能耗时数日 —— 包括通过人工标注构建训练数据集，这种工作毫无智力成就感。而 LLMs 确实遵循了帕累托原则，帮我完成了解决方案 80% 的工作，但剩余的 20% 迭代、测试和收集反馈环节耗时更久。即便模型输出逐渐可靠，LLM 幻觉仍是隐患，因此我也建议同事对异常输出保持警惕，必须人工复核。

LLMs には、私の専門的な仕事において非常に役立つテキスト生成以外の使用例もあります：テキスト埋め込みです。現代のテキスト埋め込みモデルは技術的には LLMs ですが、次のトークンのロジットを出力するのではなく、高次元空間で入力テキストを一意に識別する数値ベクトルを出力します。ChatGPT 革命がもたらした LLMs へのすべての改善、たとえばより長いコンテキストウィンドウやより良いトレーニングレジメンは、これらのテキスト埋め込みモデルにも適用され、nomic-embed-textやgte-modernbert-baseのようなモデルで時間とともに大幅に改善されました。テキスト埋め込みは、BuzzFeed で類似の記事を特定したり、推薦モデルを構築したりするのに大いに役立ちましたが、このブログ記事は生成的 LLMs についてのものなので、これらの使用例は別の機会に取っておきます。
LLMs 还有一个不涉及文本生成的用途，在我的专业工作中同样实用：文本嵌入。现代文本嵌入模型在技术上属于 LLMs，只不过它的输出不是预测下一个词元的对数几率，而是一个在高维空间中唯一标识输入文本的数字向量。ChatGPT 革命带来的所有 LLMs 改进，如更长的上下文窗口和更优质的训练方案，同样适用于这些文本嵌入模型，并促使它们随时间显著提升，例如 nomic-embed-text 和 gte-modernbert-base 等模型。在 BuzzFeed，文本嵌入从识别相似文章到构建推荐模型都发挥了巨大作用，但本篇博文主要讨论生成式 LLMs，这些应用场景就留待下次再谈。

LLMs を使った執筆？
LLMs 用于写作？#

いいえ、私はこのブログのテキストを書くために LLMs を使用していません。これは、経験豊富な LLM ユーザーが書いた記事を読む人々にとって、デフォルトの仮定になっていると疑っています。私のブログは、LLM が適切に模倣するにはあまりにも奇妙です。私の文体は率直で、無礼で、時には気まずいものです。プロンプトエンジニアリングと少数ショットプロンプトを用いて、私の既存のブログ投稿の例を与え、モデルに同じ文学スタイルを正確に従うように指示しても、LLMs はマーベル映画の対話に近いものを出力します。しかし、たとえ LLMs が私の声で記事を書くことができたとしても、私は著作権の誤表現の倫理的な理由から、それを使用することはありません。さらに、私はテクノロジー / コーディングの世界で非常に最近の出来事について書く傾向があり、これらは LLM のトレーニングデータには強く表現されていないため、幻覚の可能性が高まります。
不，我并没有用 LLMs 来撰写这个博客上的文字，尽管我怀疑对于阅读一位资深 LLM 用户所写文章的人来说，这已成为默认假设。我的博客风格太过怪异，LLM 难以准确模仿。我的文风直率、不羁，偶尔令人尴尬：即便通过提示工程加上少量示例提示 —— 给它看我已有的博文并严格要求模型精确遵循同样的文学风格，LLMs 输出的内容也更接近漫威电影对白。但即便 LLMs 能以我的口吻写文章，出于伦理考虑 —— 即大部分作品并非出自本人之手的署名问题 —— 我仍不会使用它们。此外，我常撰写科技 / 编程领域的最新动态，这些内容在 LLM 的训练数据中要么鲜有体现，要么完全缺失，从而增加了幻觉生成的可能性。

LLMs を使って私の執筆を改善するための一つの馬鹿げた技術を発見しました。それは、ほぼ完成したブログ投稿のテキストを LLM に提供し、LLM に皮肉なHacker Newsのコメント者になりきってブログ投稿に基づいて 5 つの異なるコメントを書くように頼むことです。これにより、潜在的な批判のための弱い議論を特定するだけでなく、私がその否定的なフィードバックに事前に対処するために投稿に何を書くべきかを教えてくれないので、私は有機的にそれを解決する必要があります。このブログ投稿のラフドラフトと Hacker News のシステムプロンプトを Claude API を通じて実行したところ、BuzzFeed での LLM 使用の例が単純すぎて、従来の自然言語処理技術よりも革新性がないことが指摘されました。そのため、私は NLP が効率的または効果的でない理由を詳述するように修正しました。
我发现了一个巧妙的方法，能让 LLM 在不代笔的情况下提升我的写作水平：将基本完成的博文内容输入 LLM，要求它扮演一个尖刻的 Hacker News 评论者，基于博文撰写五条截然不同的评论。这种方法不仅能暴露出可能招致批评的薄弱论点，还不会直接告诉我该如何修改内容来预先应对负面反馈，迫使我自主寻找解决方案。当我将这篇博文的草稿和 Hacker News 系统提示通过 Claude API 运行时（聊天记录），它指出我在 BuzzFeed 提到的 LLM 应用案例过于简单，与传统自然语言处理技术相比缺乏创新性，于是我修改内容，详细说明了自然语言处理技术在效率和效果上的不足。

LLMs を使った友情？
LLMs 用于陪伴？#

いいえ、私は LLMs を友好的なチャットボットとしても使用していません。character.aiやReplikaのような LLM パーソナルコンパニオンスタートアップの成功は、LLMs が役立つことの十分な証拠です。たとえその用途が単なるエンターテインメントやセラピーであっても、より実用的なものではなくても。
不，我也不把 LLMs 当作友好的聊天机器人。像 character.ai 和 Replika 这样的 LLM 个人伴侣初创公司的巨大成功，本身就足以证明 LLMs 有其用途，即便这些用途仅限于娱乐 / 治疗而非更实用的功能。

私は、LLMs を友人として扱うことが最も一般的な使用例であるため、私は異端者であることを認めます。私自身が内向的であることを除けば、できるだけ友好的に振る舞うように訓練されている存在と友達になるのは難しいです。しかし、私は LLM に対して私の無駄話を指摘させるようにプロンプトエンジニアリングを行うことができますが、嘘をつくことに対する解決策はありません。
我承认自己是个异类，因为将 LLMs 视为朋友是最常见的用例。撇开我性格内向不谈，很难与一个被训练得尽可能友好、却又因幻觉而习惯性撒谎的实体成为朋友。我可以通过提示工程让某个 LLM 揭穿我的胡言乱语，而非仅仅给予积极肯定，但对于撒谎问题却无计可施。

LLMs を使ったコーディング？？？
LLMs 用于编程？？？#

はい、私はコーディングのために LLMs を使用しますが、彼らが私の生産性を向上させると合理的に確信しているときだけです。元の ChatGPT の登場以来、私は LLMs に正規表現を書く手助けを頼んでいます。それだけで数時間を節約できることを恥ずかしく思います。しかし、現在の LLMs のコーディングにおける役割はそれを超えており、コーディングは LLM の支援を最も効果的に利用する方法について、さらに微妙で物議を醸すものになっています。
是的，我在编码时会使用 LLMs，但仅在我确信它们能提高我的生产力时。自最初的 ChatGPT 问世以来，我就开始让 LLMs 帮我编写正则表达式，单这一项就节省了我数小时的时间，说来有些惭愧。然而，如今 LLMs 在编码中的作用已远不止于此，关于如何最有效地利用 LLM 辅助，编码变得更加微妙且更具争议性。

ほとんどのコーダーと同様に、私はコーディングの質問を Google で検索し、関連性がありそうな最初のStack Overflowの結果をクリックしていましたが、Claude Sonnet に同じコーディングの質問をして、はるかに詳細でカスタマイズされた結果を得ることにしました。これは、特定の機能的制約やソフトウェアフレームワークを必要とする質問において、Stack Overflow の回答には存在しない可能性が高い組み合わせに対して特に顕著でした。最近、別のブログ投稿を書く際に Claude Sonnet に尋ねた一つの言い換えた例は、Write Python code using the Pillow library to composite five images into a single image: the left half consists of one image, the right half consists of the remaining four images.です。(チャットログ)。Pillow を使用して複数の画像を合成することはそれほど難しくなく、Stack Overflowにはそれに関する十分な質問 / 解決策がありますが、合成の具体的な方法はユニークであり、最初の試みで失敗する可能性が高い位置決めのトリックが必要です。しかし、Claude Sonnet のコードはほぼ正確であり、テストも簡単だったため、面倒なデバッグにかかる時間を節約できました。
和大多数程序员一样，我曾通过谷歌搜索编码问题并点击第一个看似相关的 Stack Overflow 结果，直到我决定开始向 Claude Sonnet 提出相同的编码问题，并获得了更详细且量身定制的答案。对于需要特定功能约束和软件框架组合的问题，这种优势更为明显 —— 这类组合在 Stack Overflow 的答案中通常难以找到。最近我在撰写另一篇博客文章时向 Claude Sonnet 提出的一个转述示例是 Write Python code using the Pillow library to composite five images into a single image: the left half consists of one image, the right half consists of the remaining four images. （聊天记录）。使用 Pillow 合成多张图像并不算太难，Stack Overflow 上也有足够多相关问题 / 解决方案，但具体的合成方式很独特，需要一些定位技巧，我初次尝试时很可能会搞砸。而 Claude Sonnet 生成的代码基本正确且易于测试，这省去了我进行枯燥调试的时间。

しかし、特にあまり人気のないライブラリに関するより複雑なコードの質問については、LLM の出力にはより慎重になります。私が直面した実際の問題の一つは、モデルをトレーニングしながら詳細なメトリックをデータベースに記録する方法が必要であることです。これには、Hugging Face transformersのTrainer クラスを使用しています。後で視覚化して分析できるようにするためです。私は Claude Sonnet にWrite a Callback class in Python for the Trainer class in the Hugging Face transformers Python library such that it logs model training metadata for each step to a local SQLite database, such as current epoch, time for step, step loss, etc.と尋ねました。(チャットログ)。これはあまり楽観的ではありませんでした。なぜなら、カスタムコールバックを作成するためのコードがあまりないからです。しかし、Claude が生成したコードは、私が尋ねたときには思いつかなかったいくつかの役立つアイデアを実装していました。たとえば、ブロッキング I/O を制限するためのバッファ、SQLite の設定の高速化、バッチ挿入、接続処理などです。「コードを改善する」と Claude に 2 回頼むと（なぜそうしないのか？）、SQLite 接続のキャッシュや、任意のメトリックを保存するために JSON 列タイプを使用する単一の列の使用など、いくつかの予期しないアイデアが得られ、コードもはるかに Pythonic になりました。これは、実際のトレーニングループの完全なコンテキストでテストしない限り、すぐに動作することは難しいほどのコード量です。しかし、たとえコードに欠陥があったとしても、アイデア自体は非常に役立ちます。この場合、生成されたコードをハックする方が、自分の SQLite ロガーをゼロから書くよりもはるかに速く、質の高いコードになる可能性が高いです。
然而，对于涉及较冷门库的更复杂代码问题 —— 这些库从 Stack Overflow 和 GitHub 抓取的代码示例较少 —— 我对 LLM 的输出持更谨慎态度。一个实际案例是，我需要在模型训练时记录详细指标到数据库（使用 Hugging Face transformers 的 Trainer 类）以便后续可视化分析。我让 Claude Sonnet Write a Callback class in Python for the Trainer class in the Hugging Face transformers Python library such that it logs model training metadata for each step to a local SQLite database, such as current epoch, time for step, step loss, etc. （聊天记录）。由于自定义回调的公开代码很少，我原本预期不高，但 Claude 生成的代码提出了些我提问时未想到的实用方案：比如限制阻塞 I/O 的缓冲区、SQLite 配置加速、批量插入和连接处理。两次要求 Claude"优化代码"（何乐不为？）又带来了意外收获 ——SQLite 连接缓存和使用 JSON 列类型存储任意指标，同时让代码更符合 Python 风格。不过这些代码仍需在实际训练循环中测试，不太可能直接开箱即用。 然而，即使代码存在缺陷，这些想法本身极具价值，在此情况下，基于生成的代码进行修改，而非从头编写自己的 SQLite 日志器，整体上会更快且可能产生更高质量的代码。

私の日常業務での実際のデータサイエンスにおいて、私は LLMs からのコード生成があまり役に立たないことを発見しました。LLMs は数学的操作のテキスト結果を信頼性高く出力できず、一部の API はコードインタープリターを使用してデータ ETL と分析を実行することでその問題を回避していますが、私が通常扱うデータの規模を考えると、そのようなワークフローを行うことはコスト的に実現可能ではありません。pandasは Python での表形式データ操作の標準であり、2008 年から存在していますが、私は比較的新しいpolarsライブラリを専ら使用しており、LLMs は pandas 関数のように polars 関数を幻覚する傾向があるため、確認のためにドキュメントを深く掘り下げる必要があり、これは煩わしいことです。データ可視化については、私は Python を全く使用せず、代わりにRとggplot2を使用しているため、LLM に相談する誘惑は本当にありません。また、LLMs がこれらのフレームワークの両方を知っているかどうかについても懐疑的です。私がデータ可視化に使用する技術は2017 年から変わっていません。チャートを作成する際に最も時間がかかる問題は、データポイントが人間が簡単に読むのに対して大きすぎるか小さすぎるかを判断することであり、これは LLM が助けることができるものではありません。
在我日常工作中占据大部分时间的实际数据科学领域，我发现 LLMs 的代码生成功能用处不大。LLM 无法可靠地输出数学运算的文本结果，某些 API 通过允许代码解释器执行数据 ETL 和分析来规避这个问题，但考虑到我通常处理的数据规模，这种工作流在成本上并不可行。尽管 pandas 是 Python 中处理表格数据的标准库且自 2008 年就已存在，但我一直专用于相对较新的 polars 库，并注意到 LLMs 往往会将 polars 函数幻觉为 pandas 函数，这需要通过深入文档查阅来确认，变得相当烦人。至于数据可视化，我完全不使用 Python 而改用 R 和 ggplot2，我确实没有咨询 LLM 的冲动，此外我也怀疑 LLMs 是否能同时精通这两个框架。 自 2017 年以来，我使用的数据可视化技术一直未变，制作图表时最耗时的问题在于判断数据点大小是否适合人类轻松阅读，而这一点 LLM 无法提供帮助。

LLMs にコーディングの質問をすることは、コーディング支援の一側面に過ぎません。他の主要な側面の一つは、GitHub Copilotのようなインラインコード提案を持つコーディングアシスタントを使用することです。私は一度限りのコーディングの質問に LLMs を使用することに成功しましたが、実は予期しない理由でコーディングアシスタントを使用するのが嫌いです。それは気が散るからです。Copilot からコード提案がポップアップするのを見るたびに、私はコードを書くことからコードをレビューすることにメンタルコンテキストを切り替えなければならず、それが私の集中力を破壊します。全体としては、生産性の純粋な向上は中立的でしたが、Copilot は LLM に対してその場で質問するよりもはるかに高価です。
向 LLMs 提出编程问题仅是编码辅助的一个方面。另一个主要用途是使用如 GitHub Copilot 这类提供内联代码建议的编程助手。尽管我在利用 LLMs 解决一次性编程问题上取得了成功，但出于一个意想不到的原因，我实际上并不喜欢使用编程助手：它会分散注意力。每当 Copilot 弹出代码建议时，我不得不从编写代码的心理状态切换到审查代码，然后再切换回来，这严重破坏了我的专注力。总体而言，虽然生产力有所提升，但净收益却为中性，因为 Copilot 的成本远高于通过网页界面直接向 LLM 提问。

さて、部屋の中の象について話しましょう — エージェント、MCP、そしてバイブコーディング — そして私の見解は刺激的です。エージェントと MCP は、高レベルでは、LLMs がユーザー入力に応じてツールが必要かどうかを判断し、ツールを実行するために渡す関連メタデータを抽出し、結果を返すことができるというReAct 論文によって普及したツールパラダイムのリブランディングです。それ以来、コンテキストウィンドウのサイズやプロンプト遵守に関する LLM の急速な進展により、エージェントワークフローはより信頼性が高くなり、MCP の標準化は通常のツールに対する客観的な改善です。私はこれを支持します。しかし、それらは新しいユースケースを開かない、LangChainが数年前に登場したときにすでに利用可能だったユースケースはありません。そして、今やシンプルな MCPワークフローの実装は、当時よりもさらに複雑で混乱しています。私は個人的に、エージェントに新しいユースケースを見つけることができませんでした。
现在我们可以谈谈房间里的大象 ——agents、MCP 和 vibe coding—— 我的观点很犀利。从高层次看，agents 和 MCP 是对 2022 年 ReAct 论文推广的 Tools 范式的重新包装，即 LLMs 能判断是否需要工具来响应用户输入，提取相关元数据传递给工具执行，然后返回结果。此后，LLM 在上下文窗口大小和提示遵循方面的快速进步，使得 Agent 工作流更加可靠，而 MCP 的标准化相比普通 Tools 确实是一种改进，我对此表示支持。然而，它们并未开启任何在 LangChain 几年前刚出现时尚未实现的新用例，如今简单的 MCP 工作流实现甚至比那时更加复杂和混乱。就我个人而言，无论是过去还是现在，都未能发现 agents 有任何新颖的用例。

コーディングエージェントのようなClaude CodeやCursorを使ったバイブコーディングは、私が試してみたいと思うことはほとんどありません。理論的には、コーディングエージェントは、コードプロジェクト全体のコンテキストを組み込むことができるため、LLM 生成コードの信頼性に関する私の不満を解決できるはずです。しかし、私は、何百ドルも無駄にしてしまった人々の恐ろしい話を聞いたことがありますが、彼らはコーディングの問題を解決するものを得られませんでした。コード生成を試すことと、コード生成で_ギャンブル_をすることの間には微妙な境界があります。バイブコーディングは私を 80% のところまで連れて行ってくれるかもしれませんが、私はそれが公開されないか、または「現状のままリリースされる」という免責事項を伴ってリリースされる個人的なアプリを迅速に構築するために価値があることに同意します。しかし、重要なプロジェクトに対して、意図的に標準以下のコードを出荷するための防御としてバイブコーディングを使用するのはプロフェッショナルではなく、私が支持できるのは、実装に完全に自信を持っているコードだけです。
与 Claude Code 或 Cursor 这样的编码代理进行 Vibe coding，我甚至没有尝试的欲望。理论上，编码代理应该能解决我对 LLM 生成代码可靠性的担忧，因为它会自我双重检查，并能整合整个代码项目的上下文。然而，我也听过那些因意外花费数百美元却未能解决任何编码问题的恐怖故事。在试验代码生成与赌博式代码生成之间，界限非常微妙。Vibe coding 或许能帮我完成 80% 的工作，我承认这对于快速构建个人应用 —— 那些要么从未公开发布，要么发布时附带 “按现状提供” 免责声明的应用 —— 是有价值的。但若以 Vibe coding 为借口，在重要项目中交付明知不合格的代码，则显得极不专业。唯有对实现完全有信心的代码，才是我愿意支持的代码。

もちろん、コーディングの風景は常に変化しており、私が上で述べたすべては、私が現在 LLMs を使用する方法です。Hacker News でバイブコーディングや他の AI コーディングワークフローに関する投稿を見て、私の見解が完全に変わる可能性は十分にありますが、私は現在のコーディング生産性に満足しており、すべてのコーディングタスクを迅速かつ正確に完了することができています。
当然，编程领域总是在不断变化，我上面所说的一切只是我目前使用 LLMs 的方式。完全有可能我在 Hacker News 上看到一篇文章，彻底改变我对氛围编程或其他 AI 编程工作流的看法，但我对当前的编程效率感到满意，能够快速且正确地完成所有编码任务。

LLM ユーザーの次のステップは？
LLM 用户的下一步是什么？#

LLMs とその社会における役割についての議論は、非常に二分化されており、LLMs にはいくつかの用途があるという非常に中立的な声明を出すだけで、攻撃の嵐を正当化するのに十分です。私は AI 批評家の Ed Zitron が彼の主張に強く反対します。つまり、LLM 業界が破綻する理由は、OpenAI や他の LLM プロバイダーが巨額のコストを相殺するために十分な収益を得られないからであり、LLMs には現実世界での実際の用途がないというものです。二つのことは同時に真実であり得ます：（a）LLM プロバイダーのコスト経済は投資家に正の ROI をもたらすにはあまりにもネガティブであり、（b）LLMs は意味があり高い影響を持つ問題を解決するのに役立つが、(a) を正当化するような AGI の誇大広告には至らない。この特定の組み合わせは、イデオロギー的に分裂したソーシャルメディアが優雅にサポートできなくなった微妙な灰色の領域を生み出します。仮に OpenAI と他のすべての LLM プロバイダーが突然崩壊し、より良い LLM モデルが訓練されてリリースされることが決してないとしたら、Qwen3やDeepSeek R1のようなオープンソースおよび許可されたライセンスのモデルは、ChatGPT に匹敵する性能を持つ有効な代替品であり、CerebrasやGroqのような専用の LLM ホスティングプロバイダーでホストできます。これらのプロバイダーは、各ユーザーの推論クエリから実際に利益を上げることができます。OpenAI の崩壊は LLMs の終わりを引き起こすことはありません。なぜなら、LLMs は_今日_役立ち、常に非ゼロの市場需要が存在するからです。それは鳴らされたベルのように戻すことができません。
关于 LLMs 及其在社会中角色的讨论已经两极分化到如此程度，以至于仅仅做出 “LLMs 有一定用途” 这样极其中立的声明，就足以招致一连串的骚扰。我强烈反对 AI 评论家 Ed Zitron 的观点，他认为 LLM 行业注定失败的原因是 OpenAI 和其他 LLM 提供商无法通过 LLMs 获得足够收入来抵消其巨额成本，因为 LLMs 在现实世界中并无实际用途。两件事可以同时成立：(a) LLM 提供商的成本经济学过于负面，无法为投资者带来正向投资回报；(b) LLMs 在解决有意义且影响重大的问题上是有用的，尽管这还达不到能证明 (a) 点合理性的通用人工智能（AGI）炒作水平。这种特殊的组合创造了一个令人沮丧的灰色地带，需要一种社交媒体因意识形态分裂而无法优雅支持的微妙理解。 假设 OpenAI 及其他所有 LLM 提供商突然倒闭，且未来不再有更优的 LLM 模型被训练和发布，性能与 ChatGPT 相当的开源及宽松许可模型如 Qwen3 和 DeepSeek R1 将成为有效的替代品，它们可由 Cerebras、Groq 等专业 LLM 托管服务商部署 —— 这些服务商实际上能从每项用户推理请求中盈利。OpenAI 的倒闭不会导致 LLMs 的终结，因为 LLMs 如今已证明其价值，市场对它们的需求永远存在：这是不可逆转的技术趋势。

ソフトウェアエンジニアとして、特にデータサイエンティストとして、私がこれまでの年月で学んだことの一つは、適切なツールを適切な時に使用するのが常に最善であり、LLMs はそのツールボックスの中のもう一つのツールに過ぎないということです。LLMs は、使用する場所や時期によって生産的であったり逆効果であったりしますが、決して無用ではありません。LLMs は、四角いペグを丸い穴に押し込むことに似ています（その過程でペグまたは穴のいずれかを損傷するリスクがあります）。LLM の支援なしで物事を行うことは、事故なく丸い穴を通過するために丸いペグを慎重に定義することに相当します。しかし、時には、迅速に反復する必要がある場合、四角いペグを押し込んで後で質問する方が理にかなっていることもありますし、時には、ペグと穴の両方をより正確にする必要があり、どちらも損傷しないようにしなければなりません。そうでなければ、ペグや穴を修理するために余分な時間とお金を費やさなければならなくなります。
作为一名软件工程师 —— 尤其是数据科学家 —— 多年来我学到的一点是，适时使用合适的工具总是最佳选择，而 LLMs 不过是工具箱中的又一件工具。根据使用场景和时机，LLMs 既可能提升效率也可能适得其反，但它们绝非无用之物。LLMs 更像是强行将方钉打入圆孔（过程中可能损坏钉或孔），而不借助 LLM 辅助则相当于精心设计圆钉使其顺利通过圆孔。但对于某些圆孔，在需要快速迭代时，先强行塞入方钉再解决问题可能更合理；而有时则需对钉和孔都更加精确，以避免损坏，否则将额外耗费时间和成本修复钉或孔。

… もしかしたら、今後は LLM に私の比喩を作成する手助けを頼むのも悪くないかもしれません。
… 也许以后我可以让 LLM 帮我写比喻句。