Analytics

AIモデルの性能評価や、新しいアルゴリズム（例えば以前取り上げたSVG: Support Vector Generationなど）の実験において、適切なデータセットの選定は極めて重要です。今回は、私がソフトウェアエンジニアリング領域の自然言語処理（NLP）タスクでベンチマークとして愛用している「PROMISE Dataset」について、その構造とAIモデルでの活用実験の経験を交えて紹介します。 PROMISE Datasetとは 私がよく利用しているのは、Software-Requirements-Classification リポジトリに含まれている PROMISE.CSV です。 元々は PROMISE Software Engineering Repository で公開されていたもので、ソフトウェア要件定義書のテキストデータと、それが「機能要件」か「非機能要件」か、さらに細かい分類ラベルが付与されたデータセットです。 データの構造とクラス定義 このデータセットは主に以下の構成になっています。 Project ID: プロジェクトの識別子 Requirement Text: 要件のテキスト（例: “The system shall refresh the display every 60 seconds."） Class: 要件の分類クラス クラス分類は以下の4つが主要なラベルとして使用されています。これらは要件エンジニアリングにおける古典的な分類に基づいています。 F (Functional Requirement): 機能要件。システムが「何を」するか。 PE (Performance): 性能要件。非機能要件の一種。 LF (Look-and-Feel): 外観・操作感。UI/UXに関わる非機能要件。 US (Usability): 使用性。使いやすさに関わる非機能要件。 graph TD Req[Software Requirement] Req --> F[Functional (F)] Req --> NF[Non-Functional] NF --> PE[Performance (PE)] NF --> LF[Look-and-Feel (LF)] NF --> US[Usability (US)] NF --> Other[Other NFRs...] AIモデルによる実験：LLM vs SVG 私はこのデータセットを用いて、いくつかのAIモデルのアプローチを試みてきました。 ...

2023年にリリースされた書籍「実践Julia入門」は、科学技術計算の領域で注目を集めるプログラミング言語 Julia の包括的な解説書です。本記事では、この書籍のレビューを通じて、Juliaがなぜ「 貪欲な言語 」と称されるのか、その魅力と強力な機能について探っていきます。 なぜ今、Juliaなのか？ Pythonの 手軽さ とC言語のような 実行速度 を両立させることを目指して開発されたJuliaは、特にデータサイエンス、機械学習、数値計算の分野でその真価を発揮します。動的言語でありながら、JIT (Just-In-Time) コンパイラによって高いパフォーマンスを実現。それでいて、数学的な記法に近い直感的な構文は、研究者やエンジニアがアイデアを素早くコードに落とし込むことを可能にします。 本書は、そんなJuliaのポテンシャルを最大限に引き出すための知識が凝縮された一冊です。 書籍「実践Julia入門」の概要 本書は「入門編」「基本編」「実践編」の3部構成となっており、初学者から実務でJuliaを活用したい中〜上級者まで、幅広い層を対象としています。以下にその広範な内容を示す目次を掲載します。 【入門編】 第1章 Juliaのインストールと開発: Juliaの基本的な特徴から、REPL、JupyterLab、各種エディタでの開発環境構築までをカバーします。 第2章 Juliaの基本文法: 変数、演算子、関数、制御構文といったプログラミングの基礎を学びます。 【基本編】 第3章 Juliaの標準ライブラリ関数: 豊富な標準関数やライブラリの使い方を解説します。 第4章 型システム: Juliaの柔軟かつ強力な型システムの概要、パラメトリック型、ユーザ定義型などを掘り下げます。 第5章 多重ディスパッチ: Juliaの最たる特徴である多重ディスパッチの概念と、ポリモーフィズムや演算子オーバーロードといった実用例を詳解します。 第6章 イテレーション: Juliaにおけるイテレーションの仕組みと、カスタムイテレータの実装方法を学びます。 第7章 ブロードキャスティング: . 構文を用いた効率的な要素ごとの演算（ブロードキャスティング）の仕組みと応用を解説します。 第8章 メタプログラミング: マクロや生成関数など、コードを生成するコードを書くための高度なテクニックを紹介します。 第9章 並行・並列処理: タスク、スレッド、マルチプロセスを活用したハイパフォーマンスコンピューティングへの道筋を示します。 第10章 パッケージマネージャ: 依存関係の管理や環境の再現性を保つためのパッケージマネージャの利用法を解説します。 【実践編】 第11章 数値計算: NLsolve.jl や DifferentialEquations.jl を用いた、非線形方程式や常微分方程式の解法を実践します。 第12章 データ解析: CSVやDataFrames.jlを使ったデータの読み込みから、基本的な統計処理までの一連の流れを追体験します。 第13章 機械学習: MLJ.jl や Flux.jl といったフレームワークを使い、Juliaでの機械学習パイプライン構築を学びます。 Juliaの”貪欲さ”を支える核心機能 本書の白眉は、単なる文法解説に留まらず、Juliaを特徴づける核心的な概念に深く踏み込んでいる点です。特に「基本編」で解説される以下の機能は、Juliaの”貪欲さ”、すなわち 表現力とパフォーマンスの両立 を理解する上で欠かせません。 ...

「日本企業が、わずか32個のパラメータで大規模言語モデル（LLM）に匹敵する性能を持つ生成AIを開発。GPUは不要で、汎用CPUで動作する」――。先日、I.Y.P Consulting社から発表されたこのニュースは、多くのAI関係者に衝撃を与えました。 これまでAI業界では、モデルの性能はパラメータ数と計算資源に比例するという「スケール則」が常識とされてきました。しかし、そのスケール則も実用上の壁に突き当たりつつあります。一説には、かつて存在した超巨大モデル「GPT-4.5」は、そのあまりのサイズと高額な利用価格から、ごく短期間でサービス終了に追い込まれたとも言われています。実際、その価格は入力が100万トークンあたり75ドル、出力が150ドル以上と、従来のモデルとは比較にならないほど高コストなものでした。また、GPT-5をはじめとする最新モデルが、単純な巨大化ではなく、複数の専門モデルを連携させる効率的なMoE（Mixture-of-Experts）アーキテクチャを採用していることも、この流れを裏付けていると言えるでしょう。 このような「巨大化路線の限界」が見え始めた今、SVGの登場はどのような意味を持つのでしょうか。本稿では、プレスリリースの見出しの先にある学術論文の真実に迫り、話題のAI「SVG」の驚くべき真相と、ビジネスにおける本当の価値を解き明かしていきます。 衝撃の発表：GPU不要の「LLM」が日本から登場？ I.Y.P Consulting社のプレスリリースや各種ニュース記事で報じられた「SVG（Support Vector Generation）」の性能は、まさに革命的でした。その主張の要点は以下の通りです。 パラメータ数はわずか32個 でありながら、LLMに匹敵する性能を持つ。 高価な GPUを一切必要とせず 、一般的なCPUでリアルタイムに稼働する。 応答速度は 1ミリ秒 と非常に高速。 言語理解能力の国際的な指標であるGLUEベンチマークにおいて、GPTを上回る精度を達成。 これらの特徴は、AI導入の障壁となっていた高コストなインフラ問題を解決する可能性を示唆し、大きな注目を集めました。しかし、この発表の根拠として提示された、国際会議へ投稿された論文を精査すると、話はより複雑で、ある意味ではさらに興味深いものになります。 まず、SVGの主なターゲットタスクは、ChatGPTのような自由な文章を生成することではなく、与えられた文章を特定のカテゴリに分類する テキスト分類 (text classification) です。例えば、「この映画は素晴らしかった」というレビューを「ポジティブ」に分類するのがテキスト分類であり、「この映画のレビューを書いてください」という指示に応えて新しい文章を作成するのがテキスト生成です。両者は根本的に異なるタスクなのです。 次に、最もセンセーショナルな「パラメータ数はわずか32個」という主張。これは従来のニューラルネットワークにおけるパラメータとは意味が異なります。論文を読み解くと、この数字はLLMのモデルサイズを示す「重み」の数ではなく、分類の境界線を定義するために使われる最も重要なサンプル文（ サポートベクトル (support vectors) ）の数を指している可能性が極めて高いです。これはモデルの規模ではなく、特定の分類問題の「複雑さ」を示す指標と言えます。 そして、「GPTを上回る精度」という点も、より正確な理解が必要です。論文の実験結果（Table 2）によれば、SVGが上回ったのは、ファインチューニングされた最新のGPTモデルではなく、特定のゼロショット学習手法（ プロンプティング (prompting) ）というベースラインです。これは大きな成果ですが、あらゆる面でGPTを超えたと解釈するのは早計です。 SVGの核心技術：「言語をカーネルとして使う」という新発想 では、SVGはどのようにしてこれほど軽量でありながら高い分類性能を実現しているのでしょうか。その核心は、論文タイトルでもある「Language as Kernels（カーネルとしての言語）」という革新的なアプローチにあります。SVGはLLMを代替するのではなく、いわば巨大なLLMの『脳』の一部を借りてくる、共生関係にも似た新しいアプローチなのです。 この仕組みを具体的に見てみましょう。まず、SVGに「ポジティブなレビュー」と「ネガティブなレビュー」の例を少数与えます。するとSVGは、GPT-4.1のような強力なLLMを、新しいレビューを書かせるためではなく、「類似性判定の審判」として利用します。新しい文章が入力されると、LLMに「この文章は、私が知っているポジティブな例とどれくらい似ていますか？ネガティブな例とはどうですか？」と問いかけ、その類似度スコアを テキスト埋め込み (text embeddings)という形で受け取ります。最後に、この類似度マップを、古くから知られる超高効率なアルゴリズムであるサポートベクターマシン (Support Vector Machine) に入力し、最も効果的な分類の境界線を引かせるのです。 しかし、SVGの真の独創性はここからさらに一歩進みます。その名の「Generation（生成）」が示す通り、SVGは単に既存のサンプルを使うだけではありません。論文で述べられているように、マルコフ連鎖モンテカルロ（MCMC）法という手法を用いて、分類の境界線をより明確にするための新しい、高品質なサンプル文（サポートベクトル）を 自動的に生成 するのです。これは、選挙の情勢調査員が、既存の有権者の意見を使うだけでなく、両党の支持を分ける境界線を正確に見つけるために、絶妙な特徴を持つ「仮想の有権者プロフィール」を巧みに作り出すようなものです。SVGはこれを言語で行い、わずかな初期データから極めて精度の高い分類器を構築することを可能にしています。 論文では、このアプローチの理論的正当性について次のように述べられています。 本研究では、このパラドックスを解決すべく、カーネルマシンという機敏で洗練されたパラダイムを導入します。本稿では、ゼロショット学習とカーネルマシンが数学的に等価であることを示す、説得力のある証明を提示します。 査読プロセスで明らかになった課題 この有望に見えるSVGですが、その根拠となった論文「Language as Kernels」は、トップレベルのAI国際会議であるICLR 2024において 不採択（Reject） となっています。査読プロセスにおいて、複数の専門家からいくつかの重要な懸念が示されました。 新規性と貢献の不明確さ: 既存研究との比較が不十分で、このアプローチが持つ独自の貢献が何であるかが明確ではない。 実験評価の限定性: 実験が小規模なデータセットに限定されており、より大規模で多様なタスクにおいてその有効性が実証されていない。 主張の妥当性への疑問: 「CPUで動作する」と主張しながら、実験ではOpenAIのAPI（外部のGPUリソースを多用する）が利用されており、主張と実態に乖離がある。 これらの指摘は、SVGがまだ研究開発の途上にある技術であり、その性能や実用性については、プレスリリースが示唆するほど確立されたものではないことを意味します。 SVGが持つ「本当の強み」：速度、コスト、そして説明可能性 では、SVGは単なる誇大広告なのでしょうか。論文が発展途上であるという事実は、その価値を損なうものではありません。むしろ、SVGが「ChatGPTの代替ではない」からこそ、特定のビジネス用途においてLLMを凌駕する強力なメリットをもたらす可能性を秘めています。 圧倒的なスピードと低コスト (Overwhelming Speed and Low Cost) 最終的な意思決定を担うSVMのアーキテクチャが非常にシンプルであるため、CPU上でも驚異的な速度で動作します。これにより、高価なGPUインフラへの投資が不要となり、運用コストを劇的に削減できます。 ...

AIでSNS等の情報を集約すればそれが「民意」なのか？ なか2656氏が"AIでSNS等の情報を集約すればそれが「民意」なのか？“で纏めているので、考えてみる。結論を先に言ってしまうと、それは民意らしき何かであっても、民意ではない。私は法的ではなく技術的な側面から見て行こう。 AIによる集約 AIによる、要約と言うのは単純なText-to-textのタスクである。つまり、SNSからExtractされたテキストの羅列からそれに続く何らかのテキストを作る行為だ。 問題は、モデルの傾向は適正なのかと、seedの影響と言う二つの側面があり、そのアウトプットは民意なるものを適正にアウトプットしたものとは到底言えないと言える。 民意とは何か そもそも、民意とは何だろうか、数だろうか密度だろうか、おそらく、何れでもない。民主主義における合意は多数決とイコールではない。民主主義における多数決とは合意できないときのフォールバックルートに過ぎない。 従って、少数の意見でも、細大漏らさず、拾い上げなくては民意たりえないのは明白である。そして、そんなことは現状のAIモデルでは不可能だ。そもそも、何が拾われて、何が拾われないかはブラックボックスであり決定すらもない。つまり、透明性が絶対的にない。 従って、少なくとも、民意なるものの抽出には適正とは言い難い。 透明性のある抽出 従って、現実問題を言えば、旧来型のテキストマイニングの方がまだ、この場合はマシである。問題はあっても、透明性がある。つまり、単純にテキストを形態素解析して単語レベルでカウントする。全部を列挙すれば失われる情報はないはずである。共起分析もいいだろう。 AIと異なり、従来型のテキストマイニングは文脈の理解ができるわけではなく、感情の理解もできないが、民意」のように、透明性と説明責任が求められる領域においては、単なる効率性だけでなく、手法の妥当性や信頼性も考慮する必要がある。つまり、なぜ、そのアウトプットが出たのか説明できないようでは有用性を有害性は上回るリスクが否定できない。 まとめ AIによるSNS情報の集約は、世の中のトレンドや大まかな意見の傾向を把握するには有用かもしれませんが、それを「民意」と呼ぶには、ご指摘の通り、技術的な側面から見て多くの課題が残る。 Appendix なか2656氏の記事が2050東京戦略（案）のブロードリスニングを参照しているので、これを解析する。なお、この解析は東京都の公開しているコードを参照してのものである。 分析の概略 この分析は図示すると以下のような流れになっている。 graph TD A[1. データ取得] --> B(2. 埋め込みベクトルへの変換) B --> C[3. 次元削減] C --> D[4. クラスタリング] データ取得で何らかの方法で、SNSからポストを取得し、それをOpenAIのGPT系の何れかの埋め込みモデルで埋め込みベクトルに変換する。これにより、例えば、 2050年代の東京では、中学生や高校生の始業時間を遅らせてほしいです。思春期の子供たちは夜型の脳になるため、朝早くからの授業では頭がついていけないそうです。 のようなコメントは、\( [1,2,3,4] \)のような多次元のベクトルに変換される。これを次元削減して、2次元のベクトルに縮約する。これは二次元の平面上に表示するためだ。この分析ではアルゴリズムとしてUMAPが使用されている。 これを、クラスタリング手法によって、幾つかのグループにまとめる。東京都のコードではスペクトラルクラスタリングとHDBSCANが併用されている。 正確には HDBSCANによって、密度の高い領域を、クラスターとして抽出して、スペクトラルクラスタリングで最終的なクラスタを作成している。そして、クラス数はコードを読む限り6とハードコードされている。 モジュール 方法 Embedding GPT系埋め込みモデル ベクトル縮約 UMAP クラスタリング HDBSCAN クラスタリング Spectral Clustering ラベリング CountVectorizer 分析の問題 あるべき分析の戦略 データ分析の代表的なフレームワークである、CRISP-DMによれば、以下のような流れで分析は進めるべきとされている。 graph TD A[1. ビジネス理解] --> B(2. データの理解) B --> C[3. データ準備] C --> D[4. モデリング] D --> E[5. 評価] E --> F[6. 実装] プロンプトはどこから来たのか この分析で作成に使ったと思われるプロンプトが開示されている。 ...

鳴り物入りで登場したGPT-5が、一部のユーザーから「退化した」との厳しい評価を受けている。最高峰の性能を期待されたはずの次世代モデルは、なぜこのような事態を招いたのか。その謎を解く鍵は、GPT-5が採用した MoE（Mixture of Experts） アーキテクチャと、OpenAIが近年辿ってきた戦略的な変遷、そして外部からもたらされたある「衝撃」にある。 「おバカな博士」はなぜ生まれたか 多くの指摘が、GPT-5に新たに搭載された「自動ルーティング機能」の問題に集約される。東洋経済オンラインの記事は、この問題の本質を的確に捉えている。 この問題の本質は、ChatGPTに新しく組み込まれた自動ルーティングにある。この機能は質問の複雑さや期待精度を推定し、内部で最適な“脳”を選択し、どの程度、深く考えるべきかを判別する仕組みだ。…（中略）…ところが発表直後、このルーターは軽い脳を選びすぎていた。…（中略）…速度や省電力、コスト効率を重視した最適化の結果、深く考えるべき問いにも浅い処理で応じてしまい、結果として間抜けなおバカ博士が生まれたのだ。 この「自動ルーティング」の正体が、MoEアーキテクチャの中核をなす ゲーティングネットワーク（Gating Network） だ。 MoE（Mixture of Experts）アーキテクチャの光と影 MoEは、単一の巨大なAIが全問題を解くのではなく、特定分野を得意とする複数の小規模な「専門家（Expert）」モデルを連携させる仕組みだ。入力された質問をルーターが分析し、最適な専門家のみを活性化させる**スパース活性化（Sparse Activation）**により、計算コストを劇的に抑えつつ高い性能を引き出すことを目的としている。 しかし、この先進的なアーキテクチャには固有の課題が存在する。 ルーティングの複雑性: 質問の意図を正確に汲み取り、最適な専門家へ割り振るルーターの学習は極めて難しい。GPT-5の初期バージョンでは、このルーターがコスト効率を過度に重視した結果、複雑な問題にも低能力な専門家を割り当て、「浅い回答」を連発してしまった。 負荷の不均衡: 処理が特定の専門家に集中し、モデル全体のポテンシャルを活かせない問題。 膨大なメモリ消費: 計算は効率的でも、全専門家をメモリ上に展開する必要があるため、推論時のメモリ消費量は巨大になる。 GPT-5の「退化」騒動は、このMoEという理想的なアーキテクチャの、実装の難しさという現実が露呈した結果と言える。OpenAIが「効率化」の切り札として採用した技術は、諸刃の剣でもあったのだ。 この諸刃の剣は厄介で、簡単にユーザに脳梁切断術のような印象を与えることになる。特に初期のユーザのレビューにあった、ロボトミー手術を受けたかのようだという、コメントの正体はこのMoEの宿命により、キャラクターが破綻したためではないかと考えている。 GPT-5へ至る道：巨大モデルの行き詰まり なぜOpenAIは、このようなリスクを冒してまでMoEを採用したのか。その背景を理解するには、GPT-5に至るまでのOpenAIの戦略的な模索を振り返る必要がある。 GPT-4o (Omni): 2024年5月、テキスト・音声・画像を統合処理する初の本格的なマルチモーダルモデルとして登場。性能はGPT-4 Turbo級を維持しつつ、コストと速度を劇的に改善し、「効率化」時代の幕開けを告げた。 o1 / o3 (推論モデル): 2024年9月以降、即時応答よりも「思考時間」をかけて論理的思考を深める推論特化モデルをリリース。AIの能力を「知識の広さ」から「思考の深さ」へとシフトさせる試みだった。 OpenAIは「効率化（GPT-4o）」と「高度な推論（o1, o3）」という二つの路線を並行して追求していた。そして、この二つの路線を統合せざるを得ない決定的な出来事が、あるモデルの商業的な失敗である。 一つの時代の終わり：GPT-4.5 (Orion) の教訓 2025年2月、OpenAIは GPT-4.5（コードネーム: Orion） をリリースした。これは、巨大な単一モデル（Denseモデル）の性能的な到達点と目されたが、その圧倒的な性能と引き換えに、商業的には容認しがたいほどの高コストという問題を抱えていた。 API料金は100万入力トークンあたり75ドルと、GPT-4oの実に30倍。この「目が飛び出るような」コストは、多くのユーザーを遠ざけた。ニューヨーク・タイムズが「一つの時代の終わり」と評したように、このモデルは商業的に成功せず、リリースからわずか数ヶ月でサービス終了に追い込まれる。 GPT-4.5の失敗は、AIの進化が「単にパラメータを増やせば性能が上がる」という “フリーランチの時代”の終わり を象徴していた。ベンチマーク上の性能は高くとも、コストに見合わなければ市場は受け入れない。この手痛い教訓が、OpenAIをGPT-5でのMoE採用へと突き動かしたのだ。 AI業界の「スプートニク・ショック」 OpenAIの戦略転換を後押ししたもう一つの要因が、外部からもたらされた「DeepSeekショック」だ。 1957年のスプートニク・ショックが米国に宇宙開発への危機感を抱かせたように、中国のスタートアップDeepSeekが開発したオープンソースのMoEモデル「DeepSeek-R1」は、西側のAI業界に衝撃を与えた。 巨大企業ではない組織が、GPT-4に匹敵する高性能モデルを、はるかに優れたコスト効率で実現できることを証明したからだ。これは、AI開発の競争軸が、もはや巨大資本による物量作戦だけではないことを示唆していた。 GPT-4.5の失敗で高コストな巨大モデル路線に見切りをつけつつあったOpenAIにとって、DeepSeekの成功は、MoEこそが進むべき道であると確信させる決定的な一撃となっただろう。 これからの展望：賢いルーターとユーザーの協調 GPT-5の初期のつまずきは、AI開発が新たな段階に入ったことの証左である。問題は山積みだが、解決策もまた模索されている。 ユーザー側では、プロンプトに「ステップバイステップで深く考えて」といった指示を加えることで、ルーターを高性能な専門家へ誘導する「ルーターハッキング」が当面の対策となる。 しかし、本質的な解決は、ルーター自体の進化にかかっている。よりユーザーの意図を正確に汲み取るアルゴリズムの開発や、ユーザーが「速度優先」「品質優先」といったモードを選択できる機能、そしてどの専門家が選択されたかを可視化する透明性の向上が、今後の重要な開発目標となるだろう。 GPT-5の苦いデビューは、「効率化」という名のフリーランチは存在しないことを示した。しかしこの失敗は、AIが単一の巨大な知能を目指す時代から、多様な専門家が協調し、それを賢く使いこなすアーキテクチャの時代へと移行するための、避けては通れない重要なステップなのである。 そして、これは、AIの評価が単に、ベンチマークで測れる賢さからユーザの受ける印象と言うもっと高度なところにシフトしつつある現実を表していると思う。