自然言語処理スレッド　その５

**Mr.Moto** · 2018/09/17(月) 11:48:10.55

このスレッドでは、おもに日本語の構文解析・談話理解・情報検索・
文章生成などの、実装とそれに付帯する技術および理論について
扱いたいと思っています。

**ことのは** · 2020/03/13(金) 19:53:58.87

>>806
＞アルファ碁は入力情報は棋譜
＞入力情報は１９×１９の画像情報

たしかに言語（棋譜）とも言えるし画像とも言えるね

究極的にはコンピュータが扱うデータは
1と0のバイナリだからみんな同じとも見なせる

じっさい機械学習では単語をベクトルにしたりするよね？

**ことのは** · 2020/03/13(金) 19:55:32.58

>>807
はたしてどうかな？

チェスや将棋でプロ棋士に勝った時もよく言われたけど
自動車の方が人間より早いけど陸上競技はなくならない

ゲームが残るかどうかは人間が面白いかどうかじゃない？
ただプロの世界が消えてしまうことは想定できるかもね

**デフォルトの名無しさん** · 2020/03/13(金) 19:56:27.57

>>810
意味が分からない
あなたはプログラミングの経験がないのでは？

仕様が確定すればプログラミングは可能になる　という前提なんだけど　ここを否定するの？
ビジネスアプリでも同じだよ

**ことのは** · 2020/03/13(金) 20:08:11.39

>>808
＞組合せ爆発が起こるので
＞スーパーコンピュータでも到底解けない
総当たりだとそうなるだろうね

だから局所的なパターンを学習することで
組み合わせ爆発を避けるのがAIの基本になる

しかも自然言語の場合は19×19どころではなく
五十音（漢字を入れれば数千）×文字数
になるのだから、なおさら組み合わせ数は多い

そしてそのすべての文字の組み合わせで
文脈が決まるから文脈解析が難しいのも自然

その上で人間同士の会話では文字以外の情報も
参照してマルチモーダルな学習になっている

株価が株価だけで決まらないのと似たようなもの

で、難しいからどうするかだけど
一番シンプルな解決法としては
最初に文脈を限定してしまうのが早い

たとえば問い合わせのテキストマイニングなんかは
もっぱら特定の商品やサービスに
文脈が限定されているから解析しやすい

最初の話に戻ると囲碁だって棋譜っていう制限された文法で
自然言語処理ではなく人工言語処理だから解析できた訳でしょ？

**ことのは** · 2020/03/13(金) 20:11:08.50

>>809
レスがコピペにしか感じないならあなたが
オリジナル性のあるレスをすればいいでしょ？

そういうレスこそ生産的だから待ち望んでいるよ

**ことのは** · 2020/03/13(金) 20:17:59.09

>>813
＞あなたはプログラミングの経験がないのでは？
決めつけはよくないな
「あなたは要件定義の経験がないのでは？」
とでも返そうか？

業務は流動的なので確定していないことが多い
RPA（の導入）なんかでもツール自体よりも
業務フローの把握や整理とかが難しいことが多い

＞仕様が確定すればプログラミングは可能になる
もちろん仕様が確定してた方が作りやすいけど
本当は長期的には不確定な部分は必ず残るんだよね

たとえば消費税や年号のように変化する部分がある
機能の拡張や修正なども当然出てくるだろうし

それでプログラムを抽象化するのは未来への投資で
抽象化や間接化で不確定性に対応できるようにする
逆に変化しないならハードコーディングでいいけど

**デフォルトの名無しさん** · 2020/03/13(金) 20:19:38.63

>>811
＞＞たしかに言語（棋譜）とも言えるし画像とも言えるね

アルファ碁に関しては専門の論文や解説書があるので、ここでは深く言及しないが

将棋でも囲碁もある局面（例えば１０手進んだ局面）では画像データになる

１９×１９の碁盤に白石と黒石が配置された１枚の絵になるので
Googleは画像処理技術を応用したんですよ

猫の画像を入力する代わりに、ある瞬間の棋譜の画像を入力する
猫か猫でないかを判別する代わりに、その局面が優勢か劣勢かを判別する

**ことのは** · 2020/03/13(金) 20:29:08.90

>>817
＞Googleは画像処理技術を応用した
グーグルだから有名な話だと思うけど
じつは他にも同様の例があるんだよ？

たとえば株式市場はチャートで表現できるから
グラフの画像にして画像認識させて
それで株価が上がるか下がるかを出力させようと

でもここで囲碁と大きな違いがあってそれはやはり
囲碁は完全情報だけど株式市場は不完全情報なので
株価を予測できるとは限らない（できない場合が多い）

**デフォルトの名無しさん** · 2020/03/13(金) 20:29:25.88

>>816
あなたとけんかするつもりはないですが、

要件定義はプログラミングとは呼ばない　　（呼ぶべきではない）
基本設計も同じ

一般に自動化プログラミングと呼ばれるものが過去にもあったけど、
自動化プログラミングとAIとは違いますよね

入力情報と出力結果は自動化プログラミングでもAIでも同じです
自動化プログラミングは仕様書を機械的にプログラム言語に置き換えただけ

AIは別のアプローチでプログラムを作る（探索とか学習とかで）

自動化プログラミングで仕様書からプログラムを作れるのならこれは完全情報ゲームですよ

**デフォルトの名無しさん** · 2020/03/13(金) 20:39:23.40

>>818
意味がわからない

株価予測と株価データからチャートを作成する問題は別

株価チャートを作るプログラミングは完全情報ゲームとして扱わないとプログラムなんか作れませんよね
例えば１カ月分の日足データと、グラフィックライブラリがあれば基本的に作成できるはず

サイズとか期間とか目盛とかいろいろあるんでしょうけど、全部事前に決めてあげるもので
全部決まったら完全情報ゲームですよ

**デフォルトの名無しさん** · 2020/03/13(金) 20:49:38.40

明地文男、3点チャージ投資法
http://3-charge.b.la9.jp/

日経平均大幅続落で、日経225は、198銘柄が３点チャージ！
「トヨタ」「ホンダ」「キャノン」」などがレア・チャージ！

底値に針を仕掛ければ、一瞬で、数% は上がる！

**デフォルトの名無しさん** · 2020/03/13(金) 20:50:09.00

そもそも生データがあるのにわざわざチャート画像化して学習する意味あるの？

**ことのは** · 2020/03/13(金) 20:51:14.93

>>819
株価予測AIが作れても予測が上手くいかないのは
不完全情報ゲームが対象だから、不完全なものになるから

「情報が完全でなければプログラミングは不可能」というよりも
「情報が不完全なら不完全なプログラム」になるということです

つまりプログラムの作成は可能だが機能は不完全だということ
要件定義を通して現実世界とのズレが埋まってないとも言えます

＞自動化プログラミングで仕様書から
＞プログラムを作れるのならこれは完全情報ゲーム

でもそれは仕様書レベルからの自動化であって
要件レベルから直接的に自動化できるプログラムはまだない
（もしあればプログラマは皆失業する）

たいていの場合は要件というか
自然言語で表現される対象の現実が不完全なので
人工言語の仕様書に落として
人工言語のプログラムに翻訳するという形になる

これはコンパイラ（やインタプリタ）が高級言語を
アセンブラや機械語に翻訳するのと同じ構図でしょう？
だからふり返って昔にはコンパイラの研究が人工知能と
分類されていたのもそんなにおかしくないんだけれど……

それで色んな事をガーッと言ってきたけど、とくに私が言いたい
さしあたりの結論としてはビジネスでは現実とのズレはなくらないということ
または、もしプログラミングは完全でもソフト開発としては不完全ということ

**ことのは** · 2020/03/13(金) 20:53:13.98

>>820
プログラミングが仕様に対して完全でも
最初の要求は株価を予測することなので
要求に対しては不完全ということですね

**ことのは** · 2020/03/13(金) 20:57:53.52

>>822
えーっともちろんべつに画像化しなくても
独自のデータ構造で解析してもいいんだろうけど……

画像化することで画像認識のライブラリが使えるから
少なくとも一から作る手間が省けるとか
一つの試みとしてメリットは存在するでしょうと

**デフォルトの名無しさん** · 2020/03/13(金) 21:04:03.31

cnnから入った人は
時系列データとか
分からない

**ことのは** · 2020/03/13(金) 21:10:47.88

もちろん画像と違って
株式市場は時系列データだから
そういう処理をしようという考え方もあるよ

言語も時系列データ（音声言語はとくにそうだし）
として扱うのも有効な手法でしょう

囲碁の局面を画像化するという話題が出たから
それの応用が利くような例を挙げただけ

**デフォルトの名無しさん** · 2020/03/13(金) 21:15:53.75

>>823
話が発散していて会話が成立しません

まず私が「AIプログラミング」と呼んでいるのは「AIが仕様書に基づいて完全なプログラムを作成すること」です

仕様書が不完全なら当然プログラムは欠陥になります
完全な仕様書を作成するのにもAI分野の技術手法は使えるかもしれませんが
それはここではAIプログラミングとは呼びません　（話が発散してしまうので）

基本的なアプローチとして、機械に近い部分から解決していくか、人間に近い部分から解決していくか
というスタンスがあります

いろいろ考え方はあると思いますが、
機械に近い部分から解決されていくだろう…と私は思っています

機械に近い部分は規則や前提条件が明確だからです

詳細仕様書からAIがプログラムを作れるようになれば、次は
基本設計書から詳細仕様書を作る方法は？といった具合に
より曖昧でてこずる領域に進んでいくのだと思います
多分、何十年もかけてね

**デフォルトの名無しさん** · 2020/03/13(金) 21:22:12.36

>>824
意味がわかりません

株価予測プログラムならそんなのは無理ですよ

経済学を駆使してでも物理学を駆使しても理論的基盤がないのだからね

せいぜい統計学と確率論でルールを決めうちしてプログラムを作ることになるのでしょう

ルールを決め打ちしてしまったなら、そこから先は「完全情報ゲーム」の世界に移行するのでは？

**デフォルトの名無しさん** · 2020/03/13(金) 21:30:38.42

>>822
目的次第でしょうね

この会話ではそこがぶれてるのでなかなか一致点を見つけるのがむずかしい

株価予測が目的なら、多分、過去の株価データからパターンを見つけ出して…
というところに学習の意味があるのでは

私が学習と言っているのはAIにプロｸﾞﾗﾑを作らせたい…というのが念頭にあるので、
プログラマが過去に作った大量のプログラムを学習して…というイメージで話しています

**デフォルトの名無しさん** · 2020/03/13(金) 21:53:18.76

完ぺきな株価予測プログラムは存在しないが、
トレーダーの代わりに株の売買が出来るAIは存在するし既に稼働している。

金融工学を極めた高給取りのファンドだって損をしながらギリギリで利益を出してる。
AIに求められる精度は連中と同等で全然オケ

**ことのは** · 2020/03/13(金) 22:16:05.53

>>828
＞話が発散していて会話が成立しません
ではイメージできるよう
具体的なストーリーにしましょう

＞「AIプログラミング」と呼んでいるのは
＞「AIが仕様書に基づいて完全なプログラムを作成すること」

――という前提なら、「AIプログラミング」の定義上
AIプログラミング自体は完全な仕様書を作成できないので
仕様書は人間（プログラマ）が作ることになるでしょう

プログラムはAIが仕様書から完全に作れるのだから
プログラマには仕様書を書くのが残された仕事になると

するとプログラマのプログラミングとは仕様書書きで
それは自動化できない前提だから不完全な世界なのです
じっさい要件定義は不完全な現実が入ってくるし

となるとプログラミングが「完全でないと不可能」というより
「可能だが不完全」という方が実態に合ってくるでしょう？

まあ正確には逃げ道がいくつもありますけどね
囲碁（のゲームAI）のように完全な世界だけを扱おうとか
仕様書の作成は「プログラミング」ではなく「設計」だとか
仕様書の作成は「プログラマ」ではなく「SE」の仕事だとか
仕様書を自動作成する「メタAIプログラミング」を仮定するとか

**ことのは** · 2020/03/13(金) 22:21:37.30

>>828
＞機械に近い部分から解決していくか
＞人間に近い部分から解決していくか

＞機械に近い部分から解決されていくだろう

逆に人間に近い部分から解決していくスタンスもあるでしょう

これは別になにか天の邪鬼でただ逆張りしてるのではなくて
論点を明確にするため、議論を多様化するためでもあります

>>770
「翻訳メモリ」を機械翻訳に応用するという例は
人間に参加させるというアプローチで
じつは人間も仮想的な計算資源みたいに解釈できると

**ことのは** · 2020/03/13(金) 22:29:08.59

>>829
＞株価予測プログラムならそんなのは無理ですよ
難しいとは思いますが無理とは断言できないでしょう

「ランダムウォーク仮説」が正しいかどうかは
経済学者でも意見が分かれるのだから

＞統計学と確率論でルールを決めうちして
＞そこから先は「完全情報ゲーム」の世界に移行

そこは決め打ちしかないとは決まってなくて
ファンダメンタルの情報を引っぱってこよう、
たとえば特許情報の解析は昔からあるけど
その応用で企業の決算書を解析しようとか
いろいろな手法がありえるでしょう

グーグルの機械検索エンジンだって
グーグルが実現するまでは
別に「理論的基盤」とかなかったでしょう？
グーグルがその基盤を作ったわけで

もっと言えばAIやインターネットだって
昔の人は「そんなのは無理」と言ったかもしれない

あまり断定すると技術的な可能性をなくしてしまうので
未来の技術は仮説的な思考で考えることにしています

**ことのは** · 2020/03/13(金) 22:33:55.18

>>830
考えが一致するのが目的というより
考えの多様性と生産性が目的なので
別に一致しなくてもいいのです

もし昔の「ルールベースしかない」で
開発者が全員一致したままだったら
自然言語処理の次のステージに進んでなかったし

今の「ルールベースはオワコン」
「機械学習しかない」で全員一致したままでも
さらに次のステージに進んでいかないかもしれないから

**ことのは** · 2020/03/13(金) 22:37:34.48

>>831
＞完ぺきな株価予測プログラムは存在しない
完璧な絶望が存在しないようにね……w

＞トレーダーの代わりに株の売買が出来る
＞AIは存在するし既に稼働している

昔から「株ロボ」とかありましたからね
ただ一方で「ソーシャルトレード」みたいに
あえて人間を使おうという発想もやはりある

まあここでは自然言語処理が本題なんだけど
人間は自然言語を自然に理解できるので
人間に参加させるのは場合によって有力な手段です

**デフォルトの名無しさん** · 2020/03/13(金) 22:49:42.90

>>832
何を言ってるのか意味がわからん

大雑把な話を避けるために、話の領域（プログラムでいえばスコープ）を限定しようとしてるのに

プログラムを作るのがプログラマの仕事なので、ここがAIができるようになると人間は別の仕事に移行するのは当然ですが
そこに至るまでには多分長い時間がかかると思います

従って上流工程の部分をAIが本質的に解決するのはまだまだ難しい

でもプログラミングだけに限れば結構、条件が揃いつつあるんじゃないでしょうか？

今のIDEも高機能エディタも構文上、次に来るべきワードやシンタクスの候補を教えてくれます
また過去に開発した大量のプログラム資産はAIの学習教材として、かなり役立つはず

ライブラリの使用方法もプログラマが学習するよりもAIの方が得意なはず（本来はね）

問題は、何を解決したいか、必要なデータや資源（ライブラリや仕様書）をどのようにAIに指示・提供したらよいか
そういった部分がまだ手探りといったところ

それでも上流工程よりは条件整備ができつつあるんじゃないかと思ってます

**デフォルトの名無しさん** · 2020/03/13(金) 23:05:21.51

>>834
ランダムウォークは確率論ですよ
正確には確率過程、マルコフ過程の一つです

仮にランダムウォークという手法を使ってみると決めたら、そこから先の作業は「完全情報ゲーム」です
他の手法でも同じ

理論的基盤がないものを使って、解決ができないのは当たり前の話で
だから何が言いたいのかわかりません

大体、株価なんてのは天気の影響も受けるし、コロナの影響も受けるし、為替の影響も受けるし…
つまり理論的学術基盤が何もないので統計や確率でごまかしてるようなもん

**デフォルトの名無しさん** · 2020/03/14(土) 13:07:52.69

株で一番確実に儲かるのはインサイダーだす

**デフォルトの名無しさん** · 2020/03/14(土) 14:13:39.84

これはやる？

https://news.nicovideo.jp/watch/nw6818自然言語処理ライブラリ「Camphr」（カンファー）をオープンソースとして公開578

**デフォルトの名無しさん** · 2020/03/14(土) 14:52:05.88

斬新な区切り方ですねω

**ことのは** · 2020/03/14(土) 20:40:37.22

>>832
>>837

結局私が言いたいことは
自然言語処理そのものが不完全だということです

AIプログラミングが完全でも仕様書は作れない
仕様書は自然言語で書かれているから
じゃあ自然言語処理のAIも不完全になる

そしてこの構図で見ると前世紀のルールベースでの
自然言語処理がなぜ挫折したのかよく分かる

Prologは一階述語論理を言語的に実装したもの
述語論理は完全な体系（本当は実装が不完全だが措く）
だが自然言語は述語論理より複雑な体系だから
フレーム問題のようなことが起きてカバーできない

だから完全な基盤があって上手くいく保証がある
って発想自体が自然言語処理では通用しない
8クイーンみたいな箱庭というかトイプロブレムなら
完全に解析できてる問題もあるんだけど

**ことのは** · 2020/03/14(土) 20:46:04.08

>>837
＞今のIDEも高機能エディタも構文上
＞次に来るべきワードやシンタクスの候補を教えてくれます

これは日本語漢字入力や検索エンジンと
同じで局所的な問題でしょう

エキスパートシステムという言い方をすれば
前世紀でも部分的にはできていた

将棋や囲碁もエキスパートシステム（弱いAI）
であって強いAIではないから
結局弱いAIをどう使うかという問題になる

＞ライブラリの使用方法
ライブラリの依存関係をAIに解かせる
みたいな環境構築の自動化は進展の余地があるでしょう

＞問題は、何を解決したいか
＞必要なデータや資源（ライブラリや仕様書）
＞そういった部分がまだ手探り

要するに自然言語処理はまだ不完全なのです
だからこそ新規アプリを開発する余地がある
枯れきったジャンルだと新規参入は難しいし

**ことのは** · 2020/03/14(土) 20:54:19.62

>>838
やはりグーグルの例で
もしまだ人力ポータルが主流だった頃に
機械検索エンジンが作れると言ったら
「理論的基盤がないから、そんなのは無理ですよ」と言われても
当時はそれなりに説得力があったかもしれません

将棋のAIに機械学習が搭載されてから飛躍的に強くなったけど
昔は「機械学習では強くなれない」みたいな意見があったそうで
今から後出しジャンケンで言えば「何言ってんの」って思えるけど

だから不確実なものは不確実なので
できる訳ないとかできるに決まってるとか
先に決めつけても仕様がないのです

＞株価なんてのは天気の影響も受けるし
気温が上がるとアイスクリームが売れるというのは
統計でよくある例だし常識的にも分かることだけど
株価と気温など天候の相関関係を統計的に解析する
というのも可能でしょう。儲かるかどうかは別だけど

固定観念の枠を外して可能性を考えることは
ソフトの開発において有効な考え方だと思います
それは自然言語処理がまだ未解決のジャンルだから

**ことのは** · 2020/03/14(土) 21:05:09.18

>>840
自然言語処理ライブラリ「Camphr」（カンファー）をオープンソースとして公開
https://pkshatech.com/ja/news/2020-03-13/

リンクが崩れているので改めて張り直しました

このCamphrというのは説明を読むと
spaCyのプラグインで
spaCyとは Pythonで動かす自然言語処理ライブラリなので
今はPythonが主流だし開発環境の選択肢になるでしょう

>>839
それはそうですね
違法だけど

**デフォルトの名無しさん** · 2020/03/14(土) 21:06:04.47

>>842
あなたは自分自身の自然言語が適切か省みたほうがよい
問いかけや課題に対して正面から向き合わず、別の話ばかりしている

＞＞AIプログラミングが完全でも仕様書は作れない

＝＞そんな話は私はしていないし、否定もしていない
　　　仕様書をどう作るかという話は私は一度もしていない
　　　できないことを議論しても仕方がない
　　　できること（できそうなこと、可能性ある事）は何かという話をしている

＞＞だから完全な基盤があって上手くいく保証がある
＞＞って発想自体が自然言語処理では通用しない

＝＞そんな話は私はしていないし、否定もしていない
　　　あなたが株価予測を例に挙げたので、株価予測には理論的基盤がないと申し上げた
　　　例が適切ではないという意味だ

私はあなたの意見を全部否定してるわけではない
全部肯定しているわけでもない
どの部分が共感できてどの部分が共感できないか、
互いの関心の範囲がずれていれば、重ねられる部分はどこか

擦り合わせをすることで、自分の考えを補正したり再発見したりできる可能性がある

**デフォルトの名無しさん** · 2020/03/14(土) 21:49:06.23

>>842
>結局私が言いたいことは
>自然言語処理そのものが不完全だということです

ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

**デフォルトの名無しさん** · 2020/03/14(土) 22:32:16.51

3/15 日 19:30 BS232 自然言語処理の応用放送大学

**デフォルトの名無しさん** · 2020/03/15(日) 00:18:30.91

>>847
自律神経の働きによって胸は鼓動を打ちチンポは勃起するが、シコシコするのは人の意識のため主体は手となる

NLPの辞書としては、チンポが独立した生き物としての学習は可能だが世界の事実と異なるためデータ数が少なく採用されないだろう
そもそもとして、NLPの不完全性からの問題提起もオブジェクト指向の集約も夢精の例もほぼ意味がなく、生物学の知識だけで解けるという極めて低品質な謎かけ、読みやすさを意識した文体しか褒めるところがないな

**デフォルトの名無しさん** · 2020/03/15(日) 08:22:22.79

若い人なのかな、想いが先行して色々足りてない

**デフォルトの名無しさん** · 2020/03/15(日) 08:26:59.82

世界の事実？

>>849
>チンポが独立した生き物としての学習は可能だが世界の事実と異なるため

化学の元素なるものは空想である、物理的エネルギーなどというのも空想である。
だいたい、客観的事実存在という観念なるものが大いなる空想である。
今日の実験や科学はけっして空想を排斥することはできないのである。

**デフォルトの名無しさん** · 2020/03/15(日) 11:00:04.12

>>845
損みたいに自分の自社株持ってる人がコメントで株価操作出来る人は違法で逮捕されないのはなぜなんだぜ？

**デフォルトの名無しさん** · 2020/03/15(日) 11:48:26.52

株価が大きく動いた後で重大なニュースが発表されるということがよくある
間違いなくインサイダーなんだろうが、逮捕されたという話を聞いたことがない

**デフォルトの名無しさん** · 2020/03/15(日) 13:00:47.42

>>213
>自然言語処理は、自然科学とまったく異なるただの　形　而　上　学　だからな

それらしい理屈をつけているだけで、ユークリッド幾何学なんてコンピューターの世界だけ。

**デフォルトの名無しさん** · 2020/03/15(日) 13:21:03.46

このマウンティング合戦でどうしたいの？

**デフォルトの名無しさん** · 2020/03/15(日) 22:14:42.53

俺が一番偉い。みんな跪け。
これでトップはすでに決まった。
以降のマウンティングは無意味である。

**デフォルトの名無しさん** · 2020/03/16(月) 07:10:30.47

NICTからBERTのモデルが公開されたね
これはとても良いこと

**デフォルトの名無しさん** · 2020/03/16(月) 07:20:50.25

マウンティングの相手はbotだった

**デフォルトの名無しさん** · 2020/03/19(木) 09:38:18.82

ロゼッタのBLEUが90あたりだそうで

0.2ポイント上がった（笑）とかでドヤ顔で論文出して喜んでいたのはなんだったんだろう、て思う

**デフォルトの名無しさん** · 2020/03/20(金) 10:39:18.21

>>530
>例えば、現実の世界に、円形をした物はたくさん存在するが、いずれも完全な円ではないし円そのものでもない。

　例えばですけど、僕の知り合いが中学生のころ、数学で「√3は無理数なのに、1：2：√3の直角三角形は現実に存在する。
実物の三角形の√3の端はどうなっているんだ？」と疑問に思って親に聞いたところ答えられなかったことがあったそうです。
https://news.nicovideo.jp/watch/nw6859935?news_ref=top_topiclist

**デフォルトの名無しさん** · 2020/03/20(金) 10:43:42.62

虚数は存在しない(これも嘘だが)とされているが
無理数は実在するからな

**デフォルトの名無しさん** · 2020/03/20(金) 11:06:28.44

>>849
>チンポは勃起するが、シコシコするのは人の意識のため

意識するのもチンポの働きなんだが？

＜俺＞
「　部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。」
＜チンポ＞
「　その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。」

**デフォルトの名無しさん** · 2020/03/23(月) 08:01:20.83

中澤さん、必死やんw
https://twitter.com/Tzawa/status/1241647447790608384
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2020/03/23(月) 15:24:05.32

まあ確信犯やろなあ
https://i.imgur.com/xZcndZq.jpg

**デフォルトの名無しさん** · 2020/03/23(月) 15:30:52.77

つまらんレスすんな

**デフォルトの名無しさん** · 2020/03/23(月) 15:43:41.09

>>650
>脳でなくチンポで物を考える生物についてなら

チンポは考える葦である！

**デフォルトの名無しさん** · 2020/03/26(木) 19:10:51.36

>>650
>脳でなくチンポで物を考える生物についてなら

【エロGIF】見てるだけでチンポがムズムズしてくる
http://ero-shame.com/blog-entry-103469.html

**デフォルトの名無しさん** · 2020/03/30(月) 09:51:52.14

Google翻訳ってコーパスどうしているんだろう？
WEBサイトから集めて自動アライン？

**デフォルトの名無しさん** · 2020/03/31(火) 00:48:25.33

そんな高度なことはせずに、wiki+αでコスト重視だと思う

**デフォルトの名無しさん** · 2020/03/31(火) 08:22:25.84

足りなくない？
特許明細書とかは？

**デフォルトの名無しさん** · 2020/04/05(日) 20:35:26.03

942名無し三等兵2020/04/04(土) 08:20:34.27ID:VRY1NLOI
なんでカスミンを揶揄するとチンポ厨が牽制に出てくるんだろう

「正確な記述を心がけています」とかのたまったカスミンが「チンポがシコシコする」の語法的誤りには全く触れないのも変だし
カスミンが直接返答するとプライドに傷付くようなレスにばかりチンポ厨が牽制を入れるのも不自然だし
カスミンとチンポ厨は共依存で嫌われ者同士で援護しあう関係でしょうか

「カスミンはホモ」

**デフォルトの名無しさん** · 2020/04/06(月) 17:36:18.80

204 名無し三等兵 sage 2020/04/06(月) 14:56:56.40 ID:K9vi7RPu
本が読書する
ニンジンが料理する

これが妙だと思わない脳の持ち主ってどうよ？　と思っていたが、脳がチンポなら仕方ない
ただし人間扱いしてやる理由もない

**デフォルトの名無しさん** · 2020/04/20(月) 17:32:27.72

狂気ネットワーク

**デフォルトの名無しさん** · 2020/04/30(木) 11:11:26.63

2020-04-27
番外編９８年ブルマJC （エッチなポーズ連続のエロダンスを強制される哀れな娘達）
https://vuluma.hatenablog.com/entry/erodancejcshuchi

↑
チンポがシコシコする、とはこういう意味だ！

**デフォルトの名無しさん** · 2020/05/27(水) 09:01:15.03

Trieって使うべき？

**デフォルトの名無しさん** · 2020/06/11(木) 11:31:35.31

>>859
BLEU自体も微妙な評価尺度なのにね

**デフォルトの名無しさん** · 2020/06/11(木) 12:20:51.61

問題がないわけじゃないけど
指標としてはいいんじゃない？

**デフォルトの名無しさん** · 2020/06/26(金) 05:35:39.03

パラレルコーパスって
ラベル付きデータって言えるの？

**デフォルトの名無しさん** · 2020/07/06(月) 20:51:10.99

MeCabの処理のデモを提供するいくつかのウェブのページで、
「複合名詞」とか「サ変動詞」とか、デフォではないと思われる要素を散見するのですが、

これって自分でカスタムなロジックを入れて作ってる、で正解ですかね?
大雑把に、名詞が連続したら複合名詞にするとか、「名詞＋する」をまとめるとか。
それともそういうのも処理できるバージョンがあったりします?

**デフォルトの名無しさん** · 2020/07/06(月) 21:06:46.82

デフォでしょ

**デフォルトの名無しさん** · 2020/07/07(火) 01:56:21.86

>>880
そうですか。例えば「形態素解析」を処理すると一般的には|形態|素|解析|か
|形態素|解析|と処理されます（辞書によります）。よね?
これを|形態素解析|と一語に処理してほしい場合にどうしたらいいのかと。

ちなみに mecab-ipadic-NEologd を使ったら|形態素解析|と一語になりましたが
辞書のサイズが1.1GBですか。これがロジックで済むなら大きな辞書を使わずに
同様の処理が可能なのかなと。

**デフォルトの名無しさん** · 2020/07/07(火) 03:19:09.63

ロジックですまないから辞書にしてんでしょ

こねくり回した sentcepiece より random を加えた bpe の方が良くて草

**デフォルトの名無しさん** · 2020/07/07(火) 08:32:40.79

>>882
なるほどー。
他にも、何月何日とか、〇〇円とかの数詞系を1フレーズと認識させたいのですが、
確かにこれもNElogdの辞書だとうまくいくんですよね。
あとは辞書の大きさだけがネックかも。

**デフォルトの名無しさん** · 2020/07/07(火) 08:44:19.61

そっか、二百億円と書く以外に2百億円と書く場合もありますね。
NEologdでも後者は駄目っぽいです。

**デフォルトの名無しさん** · 2020/07/07(火) 08:50:36.93

あとサ変動詞（〇〇する）、も「〇〇」と「する」をまとめたかったり。
〇〇「を」するという言い方もたまにするので微妙。

**デフォルトの名無しさん** · 2020/07/07(火) 16:21:30.75

489 名無し三等兵 sage 2020/07/07(火) 13:32:25.30 ID:VR0moFYQ
やっぱり珍カスの別人格じゃんチンボ脳www
ケツ蹴るぞとか言われたら発狂して（でもチビるほど怖いから）別のキチガイ人格でレスして勝った気になるマジキチガイ、
それが珍カス

**デフォルトの名無しさん** · 2020/07/07(火) 16:25:31.33

どうしたん
字繰りの練習か？

**デフォルトの名無しさん** · 2020/07/08(水) 09:54:53.62

MeCabのC++ APIを使ってみようかと思うのですが。taggerでnodeを作って。

品詞はnode->featureの値のカンマ区切りを自分でパースしてゲットするので正解?
nodeに品詞の値の要素があってもいいのではと思ったり。

元のテキスト上のオフセットとノードの関係を知りたい場合、node->surfaceが元の
テキストのポインター? バイトオフセットを計算する必要があると。

UTF-16で使いた場合、MeCabってUTF-16でセットアップできるんですかね。それとも
UTF-8でセットアップして、プログラム上で毎回文字コード変換?

などという疑問が早速あるのですが、皆さんいかがしてますでしょう。
個人的にはJavaのBreakIteratorのような使い勝手が欲しいのですが...

**デフォルトの名無しさん** · 2020/07/08(水) 10:00:05.70

https://qiita.com/nunulk/items/da69b2cc8643fd8a7f8f

**デフォルトの名無しさん** · 2020/07/08(水) 10:03:49.95

java用
https://qiita.com/kumazo/items/5c5c57d94b2080ffbb5a
C++
http://www.mwsoft.jp/programming/nlp/mecab_cpp.html
https://www.meiseid.co.jp/article/mecab-install-note

**デフォルトの名無しさん** · 2020/07/08(水) 10:05:02.57

goやらrustがあるのに？
しかもコマンドラインでやればいいようなことしかしてないくせに？

**デフォルトの名無しさん** · 2020/07/08(水) 15:46:13.33

javaやpythonのポーティングもあったよね
きうてぃーもあるのに

**888** · 2020/07/08(水) 16:31:27.31

皆さん一般的な使い方のリンクをありがとう。そのレベルは一応大丈夫なつもり。

MeCabのAPI、パース結果と元のテキスト上の位置との関連を見つけにくいような。
パース結果だけを（で）取り扱う、という立ち位置なのか。

JavaのBreakIteratorはイテレータだけでなく元のテキストのオフセットで結果を得る
メソッド等もあり、パース結果と元のテキストとの関連をより処理しやすい。
（>>888の最後に書いたのはそういう意味。言語自体のことではなく。）

うーんもしかして必要に応じて自分で少し作り足したりする必要があるのかな?

**デフォルトの名無しさん** · 2020/07/08(水) 16:38:43.55

ちなみにJava APIはNode.getSurface()がStringを返してくるのでC++ APIとは違い
元のテキスト上のオフセットはわからないのではないか、という。
(まさかStringに対してポインタ演算みたいなことはしないですよね?）

これも、オフセットが必要な使い方はするな、という立ち位置なのかもしれんけど。

**デフォルトの名無しさん** · 2020/07/08(水) 17:08:30.52

Java APIではNode.getLength()が要素のバイト長を返してくるようで（例えばUTF-8とか）。
しかしJavaで文字処理してるときにUTF-8のバイト長を教えられても、って感じはする。
ま、Node.getSurface()がStringだからそのlength()でいいんだろうけど。

Javaだけで使うならMeCab本体のエンコーディングはUTF-16の方がうれしいような。可能?

一方MeCab本体をUTF-8でインストールしてもJava API自体は動いているわけだから文字
エンコーディングのマッチングとか、何かしてるのかな?

**デフォルトの名無しさん** · 2020/07/08(水) 20:35:44.70

511 名無し三等兵 sage 2020/07/07(火) 21:24:00.41 ID:e+um6EKL
カスミンが「「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！」に霞ケ浦の回答をするのは何時なりや？
全世界は知らんと欲す

**デフォルトの名無しさん** · 2020/07/09(木) 04:21:03.81

そんなことしなくても
コマンドラインでできそう(笑)

**デフォルトの名無しさん** · 2020/07/09(木) 08:09:13.69

>>897
ん、上のMeCabの話へのレス?
プログラムの中で使いたいのでAPIについて考えているのだが。

**デフォルトの名無しさん** · 2020/07/09(木) 09:12:00.22

AIがプロファイリングするとJava使えっていう結論が出た

**デフォルトの名無しさん** · 2020/07/09(木) 16:23:26.64

だからコマンドラインでできそうだなあってこと(笑)

**デフォルトの名無しさん** · 2020/07/09(木) 18:03:29.48

もうお前らどうでもいい。
MeCabの、自分にとって使いにくい部分はアダプタを書いてイテレータのクラスに
繋げた。今のところ若干無理矢理感があるがインターフェース自体はおk。

そういえば思い出した。
昔、Mac OS Xのライブラリを眺めていると何故かMeCabがあり、遊んでみたら何故か
辞書がUTF-16だった。
今になって全てわかった気がする。

**デフォルトの名無しさん** · 2020/07/09(木) 20:01:48.96

mecabで何すんの？(笑)

**デフォルトの名無しさん** · 2020/07/09(木) 21:25:21.99

酢で和えるとおいしい

**デフォルトの名無しさん** · 2020/07/10(金) 10:50:45.15

テキストの処理で単語を処理単位にした方がいい場合がいろいろある。
ちなみにメヒビとかアオサとか割と好き。

しかしMeCab用の巨大辞書を某デバイスに突っ込むことは容認されるだろうか。
Text To Speechのファイルよりもでかかったらまずいか。
そういえばあれだってトークナイズとかしてるんだろうなあ。

**デフォルトの名無しさん** · 2020/07/10(金) 10:55:56.90

読み上げ君とかは時々変な読み上げ方するが
MeCab使ってたらもうちょっとマシなんだろうか

**デフォルトの名無しさん** · 2020/07/10(金) 16:59:23.16

とりあえずMeCabの辞書って圧縮とかはかかってないっぽいかも。
squashfs上に置いたりしたら性能がどのくらい落ちるかな。

**デフォルトの名無しさん** · 2020/07/18(土) 08:30:17.82

覚えたてか(笑)

**デフォルトの名無しさん** · 2020/07/18(土) 12:55:50.29

MecabはEUCやshift-jisが効率よいんですよ。

**デフォルトの名無しさん** · 2020/07/18(土) 13:46:55.67

>>908
何の効率ですか? メモリ使用量? 処理速度?

今日び文字処理がUTF-16なAPIが少なくないので、連携して使うとするとMeCab側に
UTF-16のオプションがあると使いやすいのだが。

辞書は、UTF-8だと日本語が1文字3バイト使うのでやはりこちらもUTF-16だと
いいんじゃないかと。圧縮とかしてたら違ってくるけど。

**デフォルトの名無しさん** · 2020/07/18(土) 14:44:43.40

UTF 16なんて Java だけじゃない？

自然言語処理スレッド その５

自然言語処理スレッド　その５