  |
はてなキーワード: 構文解析とは
Q.
生成AIにソフトウェア開発を支援してもらう場合、ソースコードの作成を依頼する形式が多いと思いますが、実行ファイルを直接出力してもらうことも技術的には可能なのでしょうか？
A.
生成AIによる実行ファイルの直接出力は、技術的には極めて困難です。現在のLLM（大規模言語モデル）ベースの生成AIは、ソースコードの生成には向いていますが、実行可能なバイナリファイルを直接出力することには根本的な制約があります。
技術的な制約
LLMはテキストベースのトークン処理を基本とする設計であり、バイナリデータを直接扱うことができません。実行ファイルは0と1の連続したバイナリコードですが、LLMはこの形式でデータを生成するようには訓練されていないため、バイナリファイルを直接出力することは現在のアーキテクチャでは実現が困難です。
従来のソフトウェア開発では、ソースコード→コンパイル→アセンブル→リンクという複数段階のプロセスを経て実行ファイルが生成されます。各段階で最適化や機械語への変換が行われるため、この過程を完全に省略してAIが直接バイナリを生成することは技術的に非常に複雑です。
研究レベルでは、バイナリデータを扱う試みも存在します。例えば、LLM4Decompileのような研究プロジェクトでは、バイナリコードを逆コンパイルする際にバイナリを一度アセンブリ言語に変換してからLLMで処理しています。逆に言えば、生成時も同様の変換プロセスが必要になると考えられます。
実務では、生成AIにソースコードを作成してもらい、それを従来のコンパイラやビルドツールで実行ファイルに変換する方式が標準的です。この方法であれば、デバッグやテストも容易で、生成されたコードの品質を確認しながら開発を進められます。
なお、フォントファイルのようなバイナリ形式でもオープンソースとして扱われる例はありますが、これはフォントという特定用途の場合であり、汎用的な実行ファイル生成とは異なります。
Q.
A.
おっしゃる通り、画像生成AIもバイナリを出力しているという点では共通していますが、実は根本的に異なる仕組みで動作しています。
アーキテクチャの違い
画像生成AIは拡散モデル（Diffusion Model）やGANなど、視覚データに最適化された専用のアーキテクチャを使用しています。一方、LLMはTransformerベースのテキスト処理に特化した構造を持っています。画像生成では、ノイズから段階的に画像を生成するプロセスを経て、最終的にピクセル値という数値データ（バイナリ）を出力します。
画像ファイルのバイナリは連続的な数値（ピクセル値）の集合であり、各ピクセルが色情報を持つという規則的な構造です。最近の研究では、画像をビットプレーン（bit-plane）として扱い、XOR演算でノイズを加えるBinary Diffusion Probabilistic Model（BDPM）のような手法も開発されています。
対して、実行ファイルのバイナリは機械語命令の複雑な配列であり、CPUが直接実行できる命令コード、データセクション、リンク情報などが厳密な形式で配置されています。わずかなビット誤りでもプログラムが動作しなくなるため、画像のような連続値とは性質が大きく異なります。
画像生成AIは、ImageNetやLAIONなどの大量の画像データセットで訓練されており、ピクセルパターンを学習します。一方、実行ファイルを生成するには、コンパイルプロセス全体（構文解析、最適化、機械語変換、リンク）を学習する必要がありますが、これは単純なパターン学習では実現できません。
したがって、画像生成AIが成功しているのは、画像という特定のドメインに特化した設計と、規則的なデータ構造があるためであり、同じ手法を実行ファイル生成に適用することは技術的に非常に困難です。
読点を明示しないと理解できない残念なやつ。
どのミチ(副詞)ガイジ(名詞)という構文解析が正しい解釈なｗ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250617182322 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaFE0CwAKCRBwMdsubs4+ SAX7AP91H8W5YkxfcYJNyKVnDTLMFpRpM2jD6U5ibKZX699r3QEA5W3dCMLwSaWI n9Tn+GGw62EDLAooPYG9jVMexEBFmQQ= =Lt/V -----END PGP SIGNATURE-----
javascriptの結合性について
a=b=1;のような場合、この文に使われている演算子はどちらも同じ=という種類であり、優先順位に差が無いので、左側から解析し、もう一つ同じ演算子があるので演算子の実行を保留し、右側の=を見つけて、右から代入するというのはわかります。
では()すなわちグループ化のような場合はどうなのでしょうか？さいわいこれには結合性はないようですが、あったとしたらどう考えればいいのでしょうか？
=のように右と左をオペランドに挟まれた形ではないので、左側とか右側とかいってもよくわかりませんし、(...)+2の)+のように演算子同士が隣接する場合も考えるとますますどういうアルゴリズムなのかよくわかりません。
それともだからこそ、()には結合性を設けないとしたのでしょうか？
dot dot dotさん
2024/2/25 15:38
a = b = 1
は
a = (b = 1)
調べましょうでもいいんですが、知ってるならそのあなたが同じ疑問にあたったときに調べて解決につながった情報だけを一通り書いてくれるのが一番ありがたいのですが。
論旨
無断で数千人の声優を学習したというのは、恐らくMoeGoeのことを指していると思われますが、アクセントも不安定で「演技泥棒」には程遠いです。
最新のモデルをもってしてもアニメの演技のような抑揚の大きい音声を学習させることは難しいことであって、実用レベルに押し上げるようなブレイクスルーもまだ起きていないのが現状です。
音声合成の学習には、データセットとして音声とそれに対応する文章を合わせた音声コーパスと呼ばれるものを用います。
演技というものは台本でいうところのト書きであって、文章に直接的に含まれている情報ではないことからも、文章から生成する音声に演技を付与させることの難しさが理解できると思います。
文章と音声があれば、即座にデータセットとして使えるかと言えばそうではありません。
文章で想定している（文章を構文解析することによって得られる）読み方と、音声における実際の発音が異なる場合があります。
音声合成は結局のところ文章の音素と音声を対応付けているだけなので、音声コーパスの文章と実際の音声に乖離がある場合には学習の精度が下がる恐れがあります。
加えて、現在の音声合成ではアクセントなどの情報を用いることが多いですが、アクセント辞書から得られた情報と実際のアクセントが異なる場合も演技音声では散見されるでしょう。
上に述べた抑揚の問題や、音声にBGMなどのノイズが混ざっている場合など、音声自体がデータに適さない場合もあるため、それらの選別も必要です。
音声合成用に収録された音声コーパスであれば、読み方やアクセント、ノイズ等に細心の注意を払って録音されていますが、一般の音声は必ずしもそうではないのです。
このような読み方やアクセント等の修正は、残念ながら人力に頼らざるを得ません。そもそも台本がない場合は一から書き起こす必要があります。
AIイラストの成功には、イラストへの人力でのタグ付けが寄与していることはよく知られていますが、果たしてAI音声という分野において人力による音声コーパスの整備が進むでしょうか？
AI音声合成ソフトの代表例とも言えるVOICEVOXはいまや多くの人気を集めており、多くのキャラクターが参加しています。
また、COEIROINKのように音声コーパスを用意することで自らの声を学習させた機械学習モデルを共有できるような音声合成ソフトも登場しています。
AIイラスト界隈における絵師との軋轢が援用されていますが、音声合成の分野においては多くの場合、データの提供者たる声優と相互理解のある関係を保ちつつ発展してきたことを強調しておきます。
もともとナレーションの分野においては、既に十分な品質の音声合成ソフトが存在します。
AIイラストと異なり、倫理的問題のある音声合成に手を出す動機付けが乏しいことが現時点において関心が集まらない要因となっています。
そもそもASMRには、バイノーラルという特色があるわけで、AIが生成したモノラル音声がAIイラストほどの脚光を浴びるとは考えづらいです。
いわゆる”後で読む”系のサービスでPocketを愛用してたんだけど、
Instapaperに本格的に切り替えることにした。
①いちいちウェブ画面に切り替えがいらない
PocketではデイリーポータルZとか某2chまとめブログとかはいちいち、
ウェブ画面にして読まないといけなくて、圏外中結構ストレスになってたけど、
Instapaperだと構文解析があってるらしく全ページ記事ビューで読めるのがいい。
これで圏外中でも読めないストレスがかなり減った。
IFTTTを使って、pocketでFAVしたの→Tumblrでポストして記録をしてたんだけど、
タイトルとリンクとれてなくて、せっかくのがともやもやしてたんだけど、
Instapaperを使ってみたら、アプリ上でお気に入り→Tumblr でできようになって、
記事内容がそのまま飛ぶようになっている。
ーーー
いまのところpocket でできて Instapaperが不便な所は見当たらないので、そのまま本格移行するつもり。
弊学では、2年生の時に必修のプログラミングの授業でC言語を習う。
中学生の頃からパソコン大先生でスクリプト言語を軽く触ってた自分としては、わざわざ面倒な書き方で面倒なコンパイルをして動かす事に疑問を感じていた。
ちなみに、試験は紙ベースで、手書きでプログラミングをさせられる。つらい。
スクリプト言語で良いと思ってた自分は、C言語を覚えることに疑問を感じていた。
結局、授業以外で全く勉強せずに試験結果は散々だったが、なんとか単位が取れたので良しとしよう。
プログラミング初学者である人は苦労して書き方を覚えていたように思う。
脱落していった人を何人も見たが、人間やれば出来ないと思っていたことが出来るのである。
今学期、PHPを書く授業とPythonを書く授業を履修してみた。
PHPは、某テキストをもくもくと写経して動かしてみる授業で、独学でテキストのコードを動かす気力のない自分にとっては最高の授業だ。
Pythonは、MeCabなどで形態素解析や構文解析をする授業で、サンプルコードを自分で考えてカスタマイズして毎回レポートで提出する。
Pythonの書き方に慣れないからか、かなりハードであるが、やりがいがあっていい感じだ。
書いたらすぐに目に見える成果が出るところが大きい。
自分は、プログラミングを授業で教えるのならスクリプト言語に限るはずだと思う。
そう思っていた矢先に事件が起こった。
最近、研究室に入ったところ先生が手当たり次第Javaを教え始めたのである。
せめてJavaScriptでいいからスクリプト言語を教えてほしいところなのに、なんでJavaなんだと発狂した。
それでも、30億のデバイスで動くハイブリッドさとオブジェクト指向を理解する上での分かりやすさという面ではJavaが手軽なのかもしれない。
ところで、最近になってプログラミング教育義務化とか叫ばれてるが、Scratchでパーツを並べてプログラミングをするなんてただの積み木に過ぎないと思う。
絶対にツマラナイだろう。
自分は、プログラミングの授業で数字を足し算して黒い画面に表示させるとかツマラナイと感じてしまった。
こんな複雑なことをしても、これしか成果が出ないならやってられないと思うのは自分だけなのだろうか。
お願いだから、プログラミングを教えるのならツマラナイ授業をしないで欲しい。
生徒に分かるように、生徒は楽しんでプログラミングをするべきだ。
別にどんな言語でもいいと思うが、プログラミング言語は人それぞれ好き嫌いが激しいだろう。
自分は、分かりやすくて直感的なRubyというプログラミング言語が学校の授業で採用されるべき言語に間違いないと思う。
別にRubyにこだわる必要はなくて、スクリプト言語であればなんでも良いと思う。
CやJavaなどのコンパイル言語は複雑で分かりにくいし、教えにくいはずだ。
スクリプト言語を教えた後に、コンパイル言語、オブジェクト指向の概念を教えていくのがいいのではないだろうか。
みんなの意見を知りたい。
現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、
ひとまずこの記事については、下記URLにある、京都大学の専門家であらせられる記事について、一人歩きしてる感があるので、
もう少し彼のような上流側（という表現で良いかどうかは不明だが）の専門家ではなく、
下流でプログラムをガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。
https://srad.jp/~yasuoka/journal/611343/
Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性と安全性について』(2017年4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。
Orarioの特性と安全性について、本当にスクレイピング技術をクライアント端末側で行っているのであれば、
この部分は間違いではないと私(匿名で失礼)は考えている。
この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。
KULASISにずっと不正アクセスを繰り返していて
上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である。
逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である。
何せ、開発者が勝手にアカウントを使って入り込んで様々な検証を行う必要があるため、
KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、
あくまで大学側が定める規約規則から若干外れた使われ方がされているという意味の不正アクセスである。
（そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない
開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大の規約によれば、不正アクセスにあたるのかもしれない。
個人的には当たらないと感じるが。
京大の規定に定められたユーザが「特定のブラウジングツール（Orario）」により、
KULASISにアクセスしているのだからアクセスとしては不正ではない。
本当にスマートなWebスクレイピングで行われているのであれば、Webブラウザと全く同じ動きをするはずで、
それを不正アクセスと断罪してOrarioは不正というのは表現が汚いと考える。
これはコメント欄にもあるが、
https://srad.jp/comment/3196554
また、ChromeやSafari（及びその他マイナーなWebブラウザ）なども御校のWebサーバーよりコンテンツデータを取得し、HTMLを構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか？
ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。
それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、
Webブラウザの一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう
京大のユーザが開発に携わったかを証明できない以上、彼にとっては不正なのかもしれないが、
ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。
他にもこの部分
Orarioアプリでは「Webオートメーション(Webスクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン（にインストールされているOrarioアプリ）に学生アカウント（大学ID・パスワード）を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要な情報のみを取得し、Orarioアプリの時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています。
全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ。
Webスクレイピング技術に関して、なぜアクセスパターンが問題になるかが一つ疑問である。
下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング（切り貼り）している。
それをアクセスパターンを解析で一体何が取れるのか？という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。
もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティの観点上公開すべきではないだろうか、
逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである。
ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから、
アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、
学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である。
学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。
そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、
現在すでにスクレイピングが確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。
（ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……
（もちろん、アクセスログを見て、ログインページからWebスクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。
たとえKULASISが京都大学がオリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。
同様に日立や富士通も同じような大学教務事務パッケージがあるが、
基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、
本当だろうか？嘘を書くのもいい加減にしろ？ と思う。
UIが糞（システムのスマートフォン対応がノロい）だからアプリが流行るということに気づくべき。
富士通、日立にしてもそうだが、APIを提供したほうがいいのではなかろうか。
とくにKULASISだったか何だったは、京都大学謹製と聞いている（違ったら失礼
少なくとも他の大学教務事務パッケージではなかったと記憶している。
であれば、京都大学がAPIを提供し大学側で専門家を集めてOrarioを超えるものを作ってはどうか？
実際大学でこういうことをやろうにも、問題になってくるのは予算で。
教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。
これが実に糞で。
一つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。
ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。
大学がアホ → 学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ
教授がアホ → 曖昧な表現で、素人を先導しようとするのが見え見えで気に入らない
Orarioアホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ
以上です
