  |
はてなキーワード: NLPとは
読める！読めないけどなんか読めるぞ！
后端开发
JavaC++PHPPythonC.NETC#GolangNode.jsRubyGIS工程师ERP技术开发游戏开发工程师音视频/图形开发全栈UE4编译器开发ErlangDelphiVBPerlASP
前端开发
移动开发
AndroidiOSU3DCocos2d-xWindows Phone移动开发工程师
PCB工程师射频工程师FPGA工程师单片机工程师DSP工程师驱动开发嵌入式软件开发嵌入式硬件开发信号完整性工程师硬件工程师硬件测试工程师硬件产品经理ARM
测试
自动化测试功能测试性能测试游戏测试软件测试移动端测试测试开发测试工程师测试经理/主管
数据
爬虫数据挖掘工程师数据分析师数据建模数据库开发工程师数据仓库工程师数据治理BI工程师ETL工程师大数据开发工程师数据开发数据采集
人工智能
推荐算法搜索算法自然语言处理(NLP)机器视觉图像算法语音识别深度学习机器学习算法工程师
运维/技术支持
运维经理/主管运维开发运维工程师DBA网络/信息安全网络工程师系统管理员系统工程师IT支持工程师桌面支持IT总监/经理/主管配置管理工程师硬件维护工程师系统集成工程师文档工程师
通信标准化工程师核心网工程师数通工程师无线通信工程师无线网络优化通信传输工程师通信电源工程师通信软件工程师通信技术工程师通信项目管理增值产品开发工程师通信设备工程师通信测试工程师电信网络工程师电信交换工程师电信/通讯工程师
高端技术职位
CTO/CIO/技术VP数据科学家大数据架构师大数据总监架构师安全专家运维总监技术合伙人技术/研发总监技术/研发经理
其他IT互联网技术
其他IT互联网技术职位
IT互联网产品
互联网金融产品经理电商产品经理数据产品经理移动产品经理商业产品经理硬件产品经理策略产品经理用户产品经理游戏策划师游戏制作人产品专员/助理产品经理产品总监产品VP/CPO
消费品/其他产品
快消品产品经理旅游产品经理教育产品开发保险产品开发/项目策划金融产品经理汽车产品规划机械产品规划其他产品职位
互联网运营
数据标注直播运营产品运营用户运营数据运营内容审核内容运营活动运营游戏运营策略运营新媒体运营社区/社群运营海外运营网站编辑网站运营运营专员运营经理/主管运营总监线下拓展运营网站营运管理网店运营网站策划
业务运营/其他运营
门店运营销售运营房地产运营其他运营职位
UE/视觉/平面设计
UI设计交互设计用户研究用户体验设计视觉设计动效设计网页设计品牌设计平面广告设计平面设计设计经理/主管美术/图形设计设计总监
工业/家居设计
家具设计家居设计玩具设计计算机辅助设计工程师工艺品/珠宝设计包装设计工业/产品设计
游戏美术设计
githubでなにか作ったものをアップロードするのは、自分向きではないことに気がついた。
私が仕事で作っているようなwebアプリケーションというのは、誰でも使える一般性の高いものではなく、もっと特定のビジネスに依存した特殊なものである。
だから一般的な誰でも使えるようなものを作るというのにはあまり慣れていないのだ。
なにか作る場合はkaggleのほうが遊び場として向いていると思っている。
kaggleで「コンペ」に参加するつもりはないし、あれはBERTが出現したぐらいからは、少なくともNLP(自然言語処理)界隈は不毛な場となってしまった。
指標があれば不毛なハックがある。それが現実というものである。
それに業務で実用レベルで使えるモデルというのは、もっと運用のしやすいシンプルなモデルである。
モンスターアンサンブルで精度がSOTAでーすピロローン！なんてことには興味がないが、コンペはそれを目指している。
ではなぜkaggleが良いかと言うと、データセットが転がっていて、notebookも簡単に作成できるからである。
「このデータをこうやって使うとこういうツールが作れる」「このデータをこうやって分析するとこういう知見が得られる」というのは、「web開発用のMVCフレームワークを作ります」よりも具体性がある。
そして特定のデータに対するモデリングをするために論文を調べるようなことになった場合は、勉強にもなる。
私は昔、自然言語処理のブログを書いていたが、実験したことのコードを載せるタイプの記事が多かった。
ところが自称データサイエンティストや自称NLPエンジニアがツイッター上で「ゴミのようなブログを書くな」と言っていて、自分が言われている気がして怖くなったのでブログを閉鎖した。
そういう「政治おじさん」との接触を最大限減らすには、ブログというフォーマットではダメだと思うわけである。
私のマグカップには"Talk is cheap, show me the code."と書かれている。
これはリーナストーバルズの名言だが、政治おじさんが近寄らない場所というのは、具体的なコードが存在する場所であると言えよう。
Aが関わっている業種は、テクノロジーまたはIT業界と考えられます。具体的には、ソフトウェア開発、インターネットサービス、デジタルマーケティング、またはEコマースなどが含まれる可能性があります。自然言語処理（NLP）技術を利用したサービスや、ウェブベースのアプリケーション開発を行っている点から、データ駆動型のサービスや製品を提供する企業である可能性が高いです。
Bの業務内容から、彼が従事している業種もテクノロジーまたはIT業界であることがわかります。Bの経験とスキルセットは、特にソフトウェア開発とインフラストラクチャの管理に関連しています。
俺の中というかMLやってる全員がパイプラインといったらデータとってくる部分だと認識してるしランダムフォレストなんか関係ないよ
で、なんのグループを出していてどのようなprocessing（NLP＝Natural Language Processing）をどの段階でしているの？
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
「ChatGDP」という用語はおそらく誤りで、「ChatGPT」というAIに関する質問かもしれません。ChatGPTはOpenAIによって開発された言語モデルであり、経済的な指標や国のGDPランキングとは直接関係ありません。
もし「ChatGPTがAI技術の中で世界で4位に位置するか」という意味であれば、ChatGPTは特定のAI技術のランキングにおいて「4位」と簡単に位置づけることは難しいです。AI技術の進歩は非常に速く、多くの異なる領域やアプリケーションが存在します。ChatGPTは自然言語処理(NLP)において先進的な成果を示していますが、その影響や評価を他のAI技術やシステムと単純に比較することは複雑です。
分野によりけりですが、私の場合は情報検索や推薦システムにNLPを利用しています
例えば検索の質を改善するためにlearning to rankを用いたり、概念検索を実装するためにエンコーダと近似最近傍法を使ったり、推薦に感情分析やパーソナリティ分析の結果を線型結合したりします
承認欲求が激しさを極めて、フォロワー2万人のツイッターアカウントを買ってしまいました(´；ω；｀)
私は寂しいんです、かまってもらいたいんです
ただ、そのアカウントが2008年から溜めてきた膨大な投稿(自動投稿されていた可能性大)を削除するのが面倒です
通常アカウントは一日に表示できる投稿数に限度があるため、何日かに分けて投稿を削除する必要があります
投稿を自動削除するブラウザプラグインも見つけましたが、繰り返しやっていると新しいツイートがロードされなくなるため、自動削除ボタンを押す→何秒か経ったら更新、というマウスシミュレーションをcneeで自動化する必要がありました
用途としては、NLPやプログラミング界隈の情報収集・発信として使おうと思っています
https://arxiv.org/pdf/2305.00833.pdf
Learning to Reason and Memorize with Self-Notes
大規模な言語モデルは、限られたコンテキスト メモリと多段階の推論に苦労することが示されています。
モデルが自己メモを取ることを可能にすることにより、これらの問題の両方を解決するための簡単な方法を提案します。
最近のスクラッチパッド アプローチとは異なり、モデルはいつでも入力コンテキストから逸脱して明示的に考えることができます。
これにより、モデルはコンテキストを読み取りながら情報を想起し、オンザフライで推論を実行できるため、メモリが拡張され、複数ステップの推論が可能になります。
複数のタスクに関する私たちの実験は、推論時に自己メモを取ることにより、トレーニング設定からより長く複雑なインスタンスに私たちの方法がうまく一般化できることを示しています.
1. イントロダクション
Transformers (Vaswani et al., 2017) および同様のバリアントは、シーケンスベースのタスクで印象的な結果を示しています
特に、GPT-3 (Brown et al., 2020) などの大規模な言語モデル (LM) はトランスフォーマーを使用し、質問応答 (QA) などのさまざまな NLP タスクを解決できます。
LM を QA タスクに使用すると、図 1 (上) に示すように、事実情報と質問を含むコンテキスト プロンプトが与えられ、モデルが直接回答を生成します。 ただし、この自己回帰の「ワンステップ」アプローチは、複数ステップの推論タスクと格闘します (Austin et al., 2021; Press et al., 2022a; Creswell et al., 2023)。 これは、バニラ LM が各トークンに対して固定された計算を行い、現在のコンテキストに応じてさらに「考える」オプションがないという事実から生じると主張します。 (2021) 図 1 (中央) に示すように、モデルが質問に答える前に推論トークンを生成できるようにするスクラッチパッドの使用を提案しましたが、完全なコンテキストと質問を読み取った後です。 同様に、一連の思考を促す方法 (Wei et al., 2022; Zelikman*Equal Contributor 1Meta AI. への対応: JackLanchantin <jacklanchantin@meta.com>, Sainbayar Sukhbaatar<sainbar@meta.com>.et al., 2022; Huang et al., 2022) は、モデルをプッシュして、一度に 1 ステップずつ答えを説明し、より首尾一貫した最終的な答えに導きます。 非線形タスク (Fan et al., 2020)、LSTM (Hochreiter and Schmidhuber, 1997) などの再帰型先行モデルが十分に備えられているもの。 Fan et al., 2020; Ju et al., 2022; Hutchins et al., 2022)、しかし、それでも与えられたプロンプトに対して一定量の計算を使用します。 推論と状態追跡メモリがより扱いやすくなります。 私たちの方法である「Self-Notes」により、LM はオンザフライでコンテキスト プロンプトから逸脱し、明示的な推論トークンを生成できます。 図 1 (下) に示すように、スクラッチパッドとは異なり、モデルは生成されたトークンを入力コンテキストとインターリーブできます。 このようなセルフ ノートは、明示的な中間推論ステップと状態追跡用のメモリの両方として機能します。 具体的には、推論ステップで 2 つの事実を組み合わせる必要がある場合、結果として得られる推論をセルフ ノートに書き込んで、将来の推論に使用することができます。したがって、中間推論ステップとして機能します。 たとえば、「アリスは箱を持っています」と「アリスは公園にいます」が与えられた場合、「箱は公園にある」と推測してそれを自己メモに書き、将来のステートメント「鍵は in the box」で「鍵は公園にある」と結論付ける。 さらに、コンテキストをトラバースしながらモデルがエンティティの最新の状態を新しいトークンとして書き込むことができるため、SelfNote はワーキング メモリの形式として機能できます。 たとえば、プログラミング環境では、最初に x=5 を想定し、次に x を 1 ずつ増やします。モデルが x=6 をセルフ ノートとして正しく記述していると仮定すると、元の x=5 ステートメントをそのコンテキストから安全に削除できます。 モデルが x の値について問い合わせられた場合、モデルは既に答えを持っています。
私たちの提案した方法と、スクラッチパッド (Nye et al., 2021)、思考の連鎖 (Wei et al., 2022)、または内部独白 (Huang et al., 2022) などの以前の研究との主な違いは、モデルを許可することです。 各コンテキストステートメントを順番に読み取るときに、複数のメモを明示的に書き出す。 InarXiv:2305.00833v1 [cs.LG] 2023 年 5 月 1 日図 1: (上) ベースライン バニラ LM は、コンテキスト (C) と質問 (Q) が与えられると、回答 (A) を直接生成します。 (中央)スクラッチパッドを使用すると、モデルは質問に答える前に中間推論トークンを生成できますが、コンテキストが表示された後です。 (下) 私たちの Self-Notes メソッドにより、モデルはいつでも推論してメモを取るために入力コンテキストから逸脱することができます。言い換えれば、私たちのアプローチは、将来の推論に役立つ可能性のある情報でコンテキストを補強するスクラッチパッドのインライン形式です。 私たちはこれを、人間が読む方法と同様に、明示的に述べられていない情報を推測するための行間の読み取り (および書き込み) の形式と見なします (van den Broek et al., 2009)。 以前の方法では、モデルが完全なコンテキストを読み取った後に反芻することができ、読み取っている間ではなく、最後に大量の推論を行うように強制されます。
さらに、そのようなポストコンテキスト推論は、推論が開始される前に以前のコンテキストトークンがモデルのコンテキストウィンドウからすでに出ている可能性があるため、メモリとして機能できません。 たとえば、数週間または数か月の対話履歴を持つインテリジェント エージェントを考えてみましょう。 直観的には、最初から考え直すことなく、以前の対話で行った推論ステップを使用できることは理にかなっています。自己メモを生成するようにモデルに教えるために、トレーニング中に、入力の一部としてグラウンド トゥルース自己メモを言語モデルに提供することを検討します。 コンテクスト。 推論中に、トレーニング中に学習した特別なトークンを生成する場合、モデルはコンテキストから逸脱し、SelfNote を生成できます。モデルが Self-Note の生成を完了すると、元のコンテキスト トークンが引き続き供給されます。 これにより、モデルは最後だけでなく、入力トークンの処理中にメモリを推論および作成できます。 また、Self-Notes をトレーニングするための半教師ありおよび教師なしの方法も提案します。多段階の推論と状態追跡を評価するように設計された 5 つのテキスト データセットでこの方法をテストします。 , 2020; Anil et al., 2022)、および 2 つの現実世界のチェス ゲーム タスク (Toshniwal et al., 2022)。 私たちの方法は、明示的なメモ取りを行わない微調整された言語モデルとスクラッチパッドのベースラインの両方よりも優れています.2. 方法シーケンス内の次のトークンを予測する自己回帰変換モデル M を考えてみましょう
