ネットワーク分析から直感的に理解するTransformerの仕組みと処理の流れ - あつまれ統計の森
グラフ理論と隣接行列 グラフ理論は点と線で物事を表す理論です。たとえば駅の路線図では下記のように駅を点、路線を線で表します。 東京メトロホームページより 上記の路線図では「駅と駅が隣接するかどうか」を中心に取り扱う一方で、それぞれの位置や方角などは厳密に再現はされません。このように、「隣接するかどうか」のみに着目して物事を表す際の理論を「グラフ理論」といいます。 グラフ理論では点をノード(node)、線をエッジ(edge)、全体をグラフ(graph)と定義します。数式で表すと$G = (V,E)$のように表しますが、$V$が頂点のVertice、$E$がEdge、$G$がGraphであるとそれぞれ解釈すると良いです。 グラフの表記法に関しては主に$2$通りあり、「①図を用いる」と「②隣接行列を用いる」をそれぞれ抑えておくと良いです。例があるとわかりやすいので下記のWikipediaの例を元
30分で完全理解するTransformerの世界
はじめに 初めまして。ZENKIGENデータサイエンスチームのはまなすです。正式な所属はDeNAデータ本部AI技術開発部なのですが[1]、業務委託という形で今年度から深層学習系の開発等に携わっています。 深層学習界隈では、2017年に衝撃的なタイトル（Attention Is All You Need）の論文が発表されてから早5年半、元出自の機械翻訳タスクを大きく越えて、Transformer関連の技術が様々な領域で用いられる汎用アーキテクチャとして目覚ましく発展し続けています。 今回はそんなTransformerが現時点までにどのように活用されてきたか、また、どのように工夫されてきたかをざっくりと俯瞰し、流れをおさらいする目的の記事になります。本記事の大枠は、2021年時点でのサーベイ論文である A Survey of Transformers に倣いつつ、適宜、2023年2月上旬現在ま
Linux 6.1の注目機能「MGLRU」―メモリ管理に取り入れられたエイジングシステム | gihyo.jp
Linus Torvaldsは12月11日（米国時間）、前週の告知どおりに「Linux 6.1」の正式リリースをアナウンスした。 Linux 6.1 -Linus Torvalds Linux 6.1はメインライン開発ではじめてRustを採用したことが大きな話題となったが、そのほかにもユーザ空間におけるメモリサニタイザーツールに似た動的エラー検出の「KMSAN」やB-treeベースのデータ構造「Maple Tree」、AMDの新しいPMFドライバのサポートなど多くのアップデートが行われている。Googleの開発者がメインラインへのマージを提案してきた「MGLRU（Multi-generational LRU）」もそのひとつで、古参のカーネル開発者であるAndrew MortonもMGLRUのメインライン化をバックアップしてきた。 Linuxカーネルではメモリ管理に「LRU（Le
キャッシュによるRubyの正規表現のマッチングの高速化の紹介 - クックパッド開発者ブログ
9月からRuby開発チームにインターンシップとして参加している@makenowjustです。 総合研究大学院大学の学生で、普段は情報セキュリティに関する研究をしています。 インターンシップでは、キャッシュ (メモ化) を利用したRubyの正規表現の高速化を行いました。 ReDoSと呼ばれる、バックトラックが爆発することでマッチング時間が膨大になる脆弱性があります (ReDoSについては、拙作ですがWEB+DB PRESSに掲載された記事があります)。 近年、ReDoSは多く報告されており、Rubyもその例外ではありません (参考1、参考2)。 今回実装した最適化は、ReDoSを防ぐことを目的としたもので、多くの正規表現のマッチング時間が文字列の長さに対して線形となります。 ReDoSが起こる正規表現の例として、/^(a|a)*$/が挙げられます。 今回の修正の前後での実行時間を比較すると、
リアルタイム共同編集のアルゴリズム (Operational Transformation; OT) を理解する試み – RORO
Google Docsのように文書を複数人でリアルタイムに共同編集できるアプリケーションがあります。あのような機能は、多かれ少なかれ、Operational Transformation (OT; 操作変換) という考え方を使って実現されているようです。興味があったので、このOTについて調べてみました。 (追記: これからは OT でなく CRDT だという話 → I was wrong. CRDTs are the future) なおGoogle Docsではいわゆる「リッチテキスト」を共同編集できますが、ここでは話を簡単にするために「プレーンテキスト」を共同編集することを想定します。 リアルタイム共同編集の流れ 共同編集システムの登場人物は次の通りです： サーバ x 1（各クライアントから届く編集操作をもとに、最新の文書を保持します） クライアント x N（文書を編集する側です） そ
ランダムを楽しもう / Algorithm with Randomness
本スライドでは、以下の２つの内容を紹介します。 １．乱択アルゴリズム（乱数を使って問題を解くアルゴリズム） ２．ランダムな入力に対するアルゴリズム
正規表現を追い抜かせ！トライ木で複数固定文字列の探索をしてみた
はじめに こんにちは。GMO NIKKOのshunkiです。当記事は次の記事に触発されて書いています。よろしければ先にご覧ください。 GMO NIKKOのT.Iです。今回は当社のTRUE データフィードで使用している正規表現検索の効率化についての記事となります。前提（背景と目的）まずは宣伝（笑）当社公式サイトでは上記となっていますが、簡単にいうと・クライアントからデータを預かる・預かったデータを広告媒体毎のフォーマットの変換する・変換したデータを指定された場所に送信するということをやっています。その中のデータの変換時に禁止文言が入ったデータを行ごと除外するということをやっています。大量のデータに禁止文言が入っているかをチェックする必要がある... この記事では、複数文字列の探索について、正規表現よりもトライ木を使った方が速いことを確かめます。最初に問題設定を共有します。次に忙しい人向けにベ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Visualization of OT with a central server
アルゴリズムの素晴らしさが 2 分でわかる動画