aiwaブランド復活より・・・

下記記事中にでてくる
販売を手がける角田（かくた）無線電機
って、あの秋葉原で無線機売ってた、Ｘ－１の角田さん？

「aiwaは日本で生まれた宝物」三井知則社長、9年ぶり復活の理由を語る
http://www.huffingtonpost.jp/2017/06/21/aiwa-returns_n_17238608.html

メルカリの個人情報流出の原因が・・・

やっちゃいそうなので、メモメモ・・・

CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして
http://tech.mercari.com/entry/2017/06/22/204500

これに限らず、エンドツーエンドの試験、社外のネットワークからアクセスしないと、
ほんとのところ、やばいよね・・

【６月２８日追加】
メルカリの個人情報流出、陥った「no-cache」の罠
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/062601030/

Swaggerで定義したAPIをAPI管理システムでマネージメントする件

REST APIは、Swaggerを使う形になってきているのかしら？
で、API管理は、昨日

GUIで、Web APIのJSON,SOAP,XML変換やAPIキーチェック、認証、トラフィック制御ができる
http://blog.goo.ne.jp/xmldtp/e/e1283276521c9b978b423ad0d59ceb1d

で聞いてきたようにApigee Edgeなどがある。
詳しくは、以下の記事。

API管理ツール、OSSも登場して戦国時代へ
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/012500793/

で、問題は、Swaggerで定義したAPIを、API管理ツールで管理できるのか？
という話。

富士通のAPI Manager、つまり、Apigee Edgeでは、できるという話を聞いてきた

（具体的には、APIを登録するとき、API Proxyの登録ということをする。
　この登録画面の、Build a Proxyで、
　　　Proxy bundle
　を選択すると、Swaggerで作ったAPIをインポートしてくれるらしい。
　ちなみに、昨日のエントリの上にある、GUIでAPI認証やマッシュアップ、JSON変換
　などを行う画面だけど、あれはConditional Flowといわれ、API Proxy editor画面
　で編集する。それを出すには、上記登録をして、各APIの画面が出たら、DEVELOPタブ
　をクリックすると出てくる）

で、オープンソースのAPI管理ツールのKongでは出来るのか？っていうのを、
今研究中（って、今日のお仕事の内容違う気が　＾＾；）。

Ethereum（イーサリアム）ネットワーク過負荷による停止。

ネットワークには、大きなトランザクションバックログがあります。この輻輳は、昨日のステータスICOによって部分的に引き起こされていますが、他の要因も同様に作用しているかどうかは不明です。

とのこと

現在日々、ICOが繰り広げられており、しかもEthereumブロックチェーン上に構築されたステータスが巨額（巨大）になっています。

ということらしい・・・

その結果

しかし、販売が始まるとすぐにネットワークが混雑し、ステータスチームは誰もが約束したトークンをすぐに提供することができませんでした。

残念ながら、2つの取引所がEthereum財布を無効にしてしまいました。これは、この技術の未熟さを示すため、Ethereumの大きな問題です。

まじ（＠＿＠！）

仮想通貨Ethereum(イーサ)ネットワーク混雑｜詐欺ICO懸念、オーバーロード引き起こす問題
http://virtualmoney.jp/I0001146/
（太字は上記サイトより引用）

※ICO(クラウドセール)とは?
ICO（Initial Coin Offering）は企業またはプロジェクトが自らのトークンやコイン（従来の金融市場における株式のようなもの）を発行し資金調達を行うプロセスである。そしてそのトークンが暗号通貨取引所に上場されることである。
（http://cryptocurrencymagazine.com/what-is-ico-crowdsaleより引用）

新しい形態素解析器 Sudachiをオープンソースでワークスアプリケーションが８月中旬に出す予定

６月２２日

Works Applications NLPエンジニアによる自然言語処理の実用化に向けた勉強会

に行ってきた！ので、内容メモメモ

---

■ご案内（人事の人）
・Wifiはないよ
・アンケートは途中で帰っても、書いてね
・つぶやいて　ハッシュタグ　WAP_TECH
・アジェンダ
　・ＷＡＰ会社概要
　・とーく１
　・とーく２：形態素解析

・ＷＡＰについて
　徳島→自然言語処理に特化した研究所
　ＥＲＰ：日本の中ではトップシェア
　ＨＵＥ：世界の「働く」を変える　動画
　　　　　人工知能型ＥＲＰ

■ＥＲＰと自然言語処理
・自己紹介
・ワークス徳島人工知能ＮＬＰ研究所
　働き方に技術でブレークスルーを起こす
・徳島県がＩＴ企業
　ＡＩ（あい）

・ＥＲＰとは
　ひとものかね
　　ＨＲシリーズ
　　ＡＣシリーズ
　　ＳＣＭ
　　ＥＣシリーズ
　ＥＲＰ：つかいにくい→バックオフィスのため

・動画
　１億円の不便と０円の便利
　ＥＲＰソフト　ＶＳ　Ｇｏｏｇｌｅ

・ＨＵＥ
　０．１秒の応答速度
　ＡＩの活用
　１２００社超の業務ノウハウ

　ＨＵＥの人工知能＝インプットレス
　コンシューマＩＴのあたりまえをエンタープライズＩＴに

・課題とアプローチ
　Enterprise Serch
　データ入力業務の効率化

・Enterprise Search
　Ｔｒｙ＆Ｅｒｒｏｒを繰り返せる
　多様なデータソースを横断して検索
　業務にＦｏｃｕｓし、ほしい情報に素早くたどり着ける

　サジェスト：サーチ内容に特化したサジェスト
　エンタープライズサーチ（全社横断）
　エンタープライズコラボレーション機能
　ＨＵＥ独自機能

　業務ごとのチューニングはプロダクト開発の役割
　チューニングを効率化、もしくは不要にするための仕組み・技術の開発

　辞書を簡単に編集・繁栄できるフレームワーク
　大規模なシステム辞書の開発（形態素、同義語）
　表記ゆれ・動議表現の自動抽出技術の研究開発

　社内でしか使われない用語、業種ごとに使われ方が違う語は共通辞書には入れられない
　　ＣＥＯ
　前後の文脈

　ユーザー環境にあるデータから自動構築が必要
　適合率重視のタスク
　言語現象を分析、減少ごとに異なるアプローチ
　単純な抽出タスクではない
　さまざまな情報源、技術の組み合わせによるチャレンジ

　さまざまなデータ入力業務
　　効率化、入力支援　ＨＵＥ
　→マジックペースト

　課題とアプローチ
　・業務ごとにとりたい項目が異なる
　　　業務ごとにモデルを作成
　・文書からの語句抽出ではない→令案と情報を文脈として活用
　　大規模辞書も併用
　・手書き・画像への対応
　　もう一つの研究チーム
　　ユーザー企業ごとに扱うフォーマットはバラバラ
　　　企業ごとはバラバラ、でも１企業が扱うフォーマットはある程度固定
　　　使い込めば精度向上
　　　操作・修正ログを用いた機械学習
　　→ログからOverFittingぎみに個別企業特化モデル
　　　→履歴書は通用しない

　その他の研究テーマ
　ＮＬＰ要素技術の研究開発
　　成果の一部はＯＳＳで公開
　Chatbotの実用化
　　FAQ Bot（社内の）,スケジューラBot,タレントサーチbot
　　目的特価
　新しい働き方を提案する機能の研究開発
　　　メンタルヘルスリスク、退職リスクの早期検出
　　　　→秋には公開できる？（今は話せない）
　　　隠れたはいパフォーマー人材の検出・分析

・最後に
　ＥＲＰ→ＮＬＰ、機械学習
　業務フローの分析

■形態素解析の話
・自己紹介
・形態素解析とは
　伝統的な自然言語処理の階層
　応用：情報検索、翻訳
　要素技術；いいかえ、照応
　基礎：形態素、構文、述語項

形態素解析の３要素
　セグメンテーション：分割
　すてみんぐ（れんまたいぜーしょん）：辞書型に
　パートオブスピーチタギング：品詞

共通接頭辞検索とらてぃす
　部分文字列がいっぺんにみれる
　　→トライ構造
→らてぃすがくめる

トライ構造をどう作るか
　めかぶ、ちゃせん：Ｗ配列、スキップリスト・・・いろんなやりかた
　　→ＦＳＴ（くろもじ）とＷあれいが多い

コスト付け
　Ｎ－Ｇｒａｍモデル
　　マルコフ連鎖を想定
　　Ｗｎ＝Ｗ１，Ｗ２・・・Ｗｎの生起確率→前方に依存
　　（Ｎ－１）語のみいぞんとする（そこまでをかける）
　最優推定、条件付き確立場（ＣＲＦ）
→かな漢字変換も
　徳永さん　日本語入力を支える技術

その他の機能
　表記正規化：送り仮名、異体字
　読み付与：よみがな、はつおん、れんだく
　派生：可能動詞、自動詞、他動詞（じゅまん）

既存のオープンソース形態素解析器と辞書
MeCab:IPADIE,UniDIc(+NEologd),JUMAN辞書
Juman:JUMAN
KyTea：点推定を使ったモデル

辞書の話
UniDic：
　国立国語研究所短単位
　誰がタグ付けしても再現できる（手続きで決まっている）
　学習コーパスＢＣＣＷＪ
　難点：短すぎ、分割ルールが直観的ではない、固有名詞が不足

ＩＰＡＤＩＣ：
　ＩＰＡ品詞体系：学校文法に近い、分割長ほどほど、粒度にばらつき
　学習コーパス：ＲＷＣＰコーパス：非公開
　難点：メンテナンスとまっている、ＯＳＳ非互換（ＩＣＯＴ条項）、NAIST-jdicも停止

NEologd
　ＩＰＡＤＩＣを補完：固有名詞・複合名詞を１語として登録、UniDic版も
　Ｗｅｂからの語彙収集：システムによる自動、半自動
　コスト推定：単語精製コストをコーパスを使わず調整
ＪＵＭＡＮ
　益岡、田窪文法に基づく：癖のある品詞（な形）
　パラメータは人手：JUMAN++ではＮＮも利用
　付加情報が多い
　間欠的にメンテナンス：JUMAN++は語彙追加も

→つかうとなると、ＩＰＡＤＩＣにＮＥｏｌｏｇｄがいいかな

ＴＩＰＳ
・前処理は大切
　脆弱：文字コード、改行、言語、テキストでないもの
　構造情報は別に
　特殊なものは専用のパーサーで

・単語追加
　再学習はしない：結果がブレブレ、コーパスの調達、手で調整
　人手調整：品詞ちゃんときめる（ＭｅＣａｂの連接ＩＤ）
　生起コストは適当でも大丈夫
　　→解析はおおむね品詞連接コストで決まる

・単語追加の注意点
　単語追加を避けるべき語
　　一般的な語の品詞違い「みんな」
　　短い語：社員名簿
　　ひらがな語「なのは」問題　なのはを人名にすると・・・
　解析を強制したい
　　特定の文字列の解析を一定にしたい
　　→文字列を１語で登録　負荷情報に分割位置

・使いやすい形態素解析
　語の同定
　　切って、品詞つけるだけで十分
　　　細かい品詞分類はいらない、つかえる分割単位か、何に使うのか
　　その後がなんなのか
　　　ほかの資源との関連付け、Entity Linking,Wikification、同義語・概念辞書
　解析の一貫性
　　わかったことは出力
　　　ＶＳ
　　状況にかかわらず一定
　分割の粒度
　　ほしい長さはアプリケーションによって違う
　　既知語と未知語で粒度が変わる

・形態素解析器 Sudachi
　オープンソース、開発もオープン、辞書も作る
　Javaで

　語の同定
　ブラックボックスだとできないこと

　やりたいこと
　　複数の文辰単位
　　ＵｎｉＤＩＣ＋ＮＥｏｌｏｇｄ
　　継続的なメンテナンス
　　機能のプラグイン
　　同義語辞書との連携

　分割単位
　　Ａ単位：ＵｎｉＤｉｃ
　　Ｂ単位：ＩＰＡＤＩＣ
　　Ｃ単位：NEologd

　略語は同義語で
　プラグイン形式でフックして処理を差し込める
　大規模使用時の省メモリ化
　複数ＶＭでメモリ共有
　８月中旬初版リリース予定！