https://tech.stockmark.co.jp/blog/Recent content in Blogs on Stockmark Tech BlogHugojaThu, 25 Jan 2024 17:00:00 +0900https://tech.stockmark.co.jp/blog/202312_engineering_organization/Thu, 25 Jan 2024 17:00:00 +0900https://tech.stockmark.co.jp/blog/202312_engineering_organization/2023年の4月から、プロダクト開発チームのEMを務めている岩谷です。本記事では、当時プロダクトエンジニア13人中3人の退職が重なる中々しびれる状況から、エンゲージメントや開発品質の改善に向き合い、怒涛の半年間が過ぎ、現在21人の組織になるまでに取り組んできたことや学びについてご紹介できればと思います。 事業背景 2023年3月以前、以下のような組織体制で、私はML Engineering / MLOpsを推進する基盤チームのEMを勤めておりました。 プロダクト開発チームは、いわゆるマトリクス組織で、３つの職能横断のフィーチャーチームを構成し１つのAnewsというプロダクトを開発していました。エンジニアは全体でEMが1名、チームごとにエンジニアのリーダーがおり、開発の運用方法は全て各チームに委ねられている状態でした。 そんな中、EM1名、リーダー１名、エンジニア1名が新しいチャレンジの場を求める形で、3~4月の間に退職が重なってしまいました。退職理由は、全員と深く話せたわけではありませんが、例えば社員ではなく個人として社会で自律していきたいなど、真剣に自身に合った生き方やキャリアを考えて下した結論でした。私としては一定仕方の無いことと捉えていましたが、事象だけを見るとネガティブに捉えられる可能性もあり、残されたメンバーは役割の穴埋めだけでなく、精神的な部分のフォローアップも重要であったと思います。 私は過去にAnewsの開発チームでチームリーダー・テックリードを担っていた時期もあり、マネジメント職の中では、メンバー・システムの両面で解像度を最も高く持っていたため、プロダクト開発チームのEMを兼務し本イシューに取り組むことになりました。 これまではプレイングマネージャーとしての仕事がメインであり、チームから一歩離れた立場で開発チームに関わっていくというのは初めての経験だったため、本当にできるのか不安はありました。ただ、客観的に見ても自身が適任者だと思い使命感を感じていたことと、自身のキャリアを広げるチャンスとも捉えており、当時はポジティブな気持ちで走り出していたと思います。 やったこと 責務・課題の把握 責務・課題の把握を進めるにあたり、まず、コアとなる役割が抜けたことから、主要なステークホルダから複数の視点での情報を得て、責務の棚卸しが必要があると考えました。加え、人間関係的な問題や精神的にネガティブな空気が無いかも確認するために、各チームリーダーおよびPdMと1on1を行うことにしました。 責務について、幸いなことにフィーチャーチーム内の運用は安定しており、基本的な開発〜保守は自律的に進められる状態になっており、EMとしては主に以下のような業務を行っていたことがわかりました。 ピープルマネジメント（全メンバーの目標設定・育成・評価・1on1） 採用（ペルソナ策定、スカウト、面談、面接、オファー） コスト管理（クラウド、各種開発ツール） 情シス系の業務（ISMS対応／セキュリティ管理） 課題については、特に多く挙がったのが品質に関わる事項でした。 有識者の不足による考慮漏れの多発 10人中、4人が元々別プロダクトのメンバー、3人が1年以内の入社者、1人がSREであり、ソフトウェアエンジニアの中でプロダクト把握度の高いメンバー（いわゆる「有識者」）が2人だけになっていた。 中規模以上の改善施策の停滞 品質向上につながる改善施策について、20%の稼働を充てるという大方針はあったものの、実態としては新規開発の隙間で各メンバーの判断で実施する、という形をとっており、長期化しそうな中規模以上の施策や、チームを跨ぐような課題に中々手がつけられていない状況であった。 逆に、1on1の中でわかった良い点もありました。実はこの３ヶ月程前に、企画と開発を分離した体制から、フィーチャーチーム体制への変更を行なっていたのですが、企画の進めやすさ、コミュニケーションパスのシンプル化等の理由でPdM、エンジニアともにポジティブな意見が多く、かつチーム内の人間関係も良好であった点は不幸中の幸いでした。 3チームから暫定的に2チームへ まず最初に決めたのは、チームを２チームに減らすことです。リーダーが退職したことはもちろんありますが、全体としてAnewsの経験が浅く、ドメイン知識や技術力の底上げをするためにも相互サポートがしやすいようチームを分散させすぎない方が良いと考えました。 改善施策の期初計画化 停滞していた中規模以上の改善施策については、「やっていいのかわからない」というPdM・他チームへの遠慮のようなものが感じられたため、やって良いのか迷わず計画的に進められるよう、半期ごとの期初計画に入れることにしました。誤解のないように補足しますが、PdMのメンバーは皆エンジニアリングに対して理解があり、改善施策にも協力的でした。それでも、「自由にやって良いよ」だけでは動きづらい現実があったのです。 期初計画とは言いましたが、なるべく自律性を重視したかったため、課題感とアイデア自体は各チームでリストアップしてもらい、マージした後自分とリーダーで話し合って優先度付けをしました。 決定した施策については、担当チームを決めて、リーダーがチームに持ち帰り各個人の目標まで落とし込んでいきました。 成長・育成目標の策定 有識者の減少という問題に対処するために、ドメイン知識も含めたスキルマップを作成しました。シンプルなもので、フロントエンド、バックエンド、バッチ処理、モバイルアプリの４つに対し、開発できない、開発はできる、影響まで考慮して設計・レビューできるの３段階にわけました。 考慮漏れを減らすには「影響まで考慮して設計・レビューできる」人の存在が重要であるため、特に開発量が多いフロントエンド、バックエンドに絞って、各チームに１人以上はそういった人が配置できるようにすることを全体の目標とした上で、これも個人目標まで落とし込んでいきました。 ピープルマネジメントのリーダーへの委譲 元々EMが全員の目標設定、1on1、評価を行っていましたが、退職が続き不安感のある中で、兼務かつしばらくチームを離れていた自分が全てを行うことに懸念がありました。 そんな中、タイムリーにもCo-VPoEであるiwashiさんがモデレーターを務めるイベントで、「エンジニアリングマネージャーのしごと」の著者でもある吉羽さんが、目標設定は土台であり、運用が大事である旨を話されており、日々メンバーの仕事を見ているリーダーに運用に入ってもらうべきと言う考えが強くなりました。 しかし、目標設定・評価の経験がないリーダーもいたため、いきなり完全に任せるのではなく、伴走する形を取ることにしました。 具体的には、目標設定および最終評価には自分も参加し等級ごとに適切な目標ラインの目線合わせを行うこと、自分とリーダーの間で高頻度でメンバーの目標進捗について共有してもらい、課題に対する対応策の検討や、目標自体の見直しなどを話し合うようにすることで、委譲を進められる地盤を整えていきました。 採用の委譲、役割整理 また、採用においても、一部委譲を進めました。元々EMが全てを行ってたカジュアル面談は、リーダーと分担して実施することにしました。カジュアル面談では、相互理解を深めること、マッチングの可能性を探ることが主目的と考えており、例えばエンジニア経験が短く、技術的な幅や深さを広めていきたいと考えられているような方の場合、現場開発に入っていない自分よりチームリーダーと対話してもらったほうがより手触り感のある話ができると考え、候補者様の書面情報から適切な面談者をアサインする形式にしました。 また、候補者様に魅力を感じていただくことも重要で、プロダクトに関するお客様の成功事例等を集めて関係者で話し合い解像度を上げる活動を行い、皆が自信を持って話せるようにしていきました。 カジュアル面談でリーダーの負荷が高まる懸念に対し、元々リーダー２人で実施していた１次面接を、１人で実施できるようにし、時間的負荷の軽減を行いました。リーダー２人はそれぞれフロントエンドとサーバサイドに強みが分かれていたので、候補者様に合わせて適切な面接者をアサインする形です。このように、役割ややり方を常に見直しながら運用を現体制にアジャストしていきました。 学び 良かったこと 人員面については、元々入社の決まっていた2人、新たに採用の決まった5人、基盤チームの統合による4人（自分含む）が加わり、退職も出ていないため10人から21人の組織となりました。 もちろん、人が増えれば良い・退職が出なければ良いというものではありませんし、まだ期間が短いので問題が顕在化していない可能性もありますが、悪い流れで退職が続いていき組織崩壊、という最悪のシナリオは避けられたのかなと思っています。 定性的な面では、改善が進められない、考慮漏れが多いといったエンジニアの不安の声がほとんど出なくなりました。様々な要因はあると思いますが、1on1でエンジニアのメンバーと話す中で、「これをやった方が良さそうなんだけど影響範囲広くて・・・次の期初計画で提案します！」と言われた時は本当に嬉しくて、ああこれか、と思いました。決して全ての課題が無くなったわけではありませんが、課題があっても自分達で変えていけば良い、変えられるという手応えが得られたというのが１番大きかったのではないかと思います。 今振り返ると、元の状態は、プロダクトの新規開発とシステム品質の担保という責務に対し、十分な権限の執行の仕方が明示されていなかったとも取れます。主体的に期初計画を立てるというプロセスを入れたことにより、責務と権限のバランスが取れ、より自分事として自律的に動ける状態になり、「不安を言う」というアクションから「不安な事項に対して具体アクションを起こす」という変容が起きたのかもしれません。 課題 様々な事を行いましたが、特にリーダーにはチーム開発の運用に加え様々な役割も持ってもらい、結果としてもついてきていたため自分としては十分に高い評価を行ったつもりでしたが、最終評価の際に少しギャップが生じるということが起こりました。 距離が近くなるほど、まあ大丈夫だろう、わざわざそこまで話さなくても、という感覚で十分な期待値すり合わせが期中にできていませんでした。色々なことに追われていたため甘えが出ていたのだと思います。どんな関係性であっても基本に忠実にやるべきことはやらなければならないと痛感しました。 また、育成計画で有識者を増やす事を掲げていましたが、退職したEMやリーダーのように何年もいたメンバーと同等レベルの有識者を半年で育成するのはさすがに無理がありました。 一方で、知見を高める手段として行ったドキュメンテーションなどを通じて、組織として知見を溜めていく動きが活発化していったことで、中期的によりロバストな組織になっていくための足がかりができ、むしろ良かったのかもしれません。メンバーと1on1等で話す中では不安の声を聞くことが無くなっているため、良い方向に向かっている感覚を組織として持ててきているのだと思っています。 このように当初計画とは違う形で進んだ状況を振り返り、特に人や組織が関わってくると、計画の蓋然性は低くなるものだと思うので、あまりMECEに考えすぎず、失敗する前提で並列に施策を進めるのも１つのやり方だと思いました。エンジニアリング組織論への招待の中で「経験主義と仮説思考」として不確実な問題に対する向き合い方が取り扱われていますが、１つ体感できたケースだったと思います。 今後の取り組み これまでは顕在化した課題に対する対処的な施策が主でしたが、今後は成長可能性を高める潜在的なイシューに取り組んでいきたいと考えています。具体的には以下のような取り組みを始めているところです。 生成AI領域での価値創造を加速するために、専門チームを立ち上げ、３チーム体制を復活させました。 よりプロダクト価値を生む組織を目指して、プロダクト戦略の解像度を高める活動、フィーチャーチーム内の共創の進め方の見直し等、探索的に取り組んでいます。 採用力や成長力を高めるために、外部発信等の活動を強化していきたいと考え、テックブログ執筆や外部登壇等、少しづつですが活動を増やしています。 成長指針づくりがしやすい環境を目指し、等級制度を改定したいと考えています。 最後に 様々な取り組みを記載してきましたが、前提として良いプロダクトを作っていきたい、良い開発組織になっていきたいという思いを持ったメンバーが集まってくれていることに大きく支えられてきていると実感しています。 まだまだ学ぶべきことも多く、伸び代だらけの組織ですが、一緒にプロダクトと組織を成長させていただける方をまだまだ募集していますのでカジュアル面談からお気軽にご連絡ください。https://tech.stockmark.co.jp/blog/anews_vue3/Fri, 15 Dec 2023 11:00:00 +0900https://tech.stockmark.co.jp/blog/anews_vue3/はじめに この記事では、私たちが開発しているAnewsというプロダクトでのVue 3移行プロジェクトについて紹介していきます。 Anewsはビジネス向けにユーザーの趣向に合わせて日々のニュースなどの最新情報を提供するプロダクトです。フロントエンドはVue.jsというフレームワークを使用しています。2023年末にVue 2のサポート期限が迫っており、それまでにAnewsのVue 3移行を完遂すべく、Vue 3移行プロジェクトを行いました。 そこで得られた知見としてVue 2とVue 3の違いや、必要だった対応、実際に行った移行戦略などまとめていきたいと思います。 移行前の環境 今のAnewsは2020年に開発がはじまり、AnewsはVue 2.6.12、TypeScriptを使用していました。 TypeScriptを活用して開発するため、TypeScriptのクラスでVueのコンポーネントを定義できるVue Class Componentを使った開発をしていました。 移行を見据えてやってきたこと Composition APIへの移行 Vue 3ではVue Class Componentがサポートされなくなっています。これによりコンポーネントの書き方をクラスコンポーネントから、Composition APIの書き方に変える必要がありました。 以下のパッケージを導入し、Vue 2.6.12のままComposition APIの移行しました。 yarn add @vue/composition-api Vue 2.7への移行 Vue 2.7では、@vue/composition-api相当の機能がVue本体に取り込まれたので、追加のライブラリなしに、Composition APIを使用することができるので、アップグレードを行いました。 以下のようにdefineComponentなどのAPIのインポートパスを変更しました。 // Vue 2.6.12 import { computed, defineComponent, PropType, ref } from '@vue/composition-api'; // Vue 2.7 import { computed, defineComponent, PropType, ref } from 'vue'; 本格的に移行プロジェクト始動 ブランチ戦略 Anews開発におけるブランチ戦略の詳細は以前のテックブログの記事で紹介しているのですが、主に以下の3つのブランチを用いた開発をしています。 developmentブランチ：開発用 stagingブランチ：検証用 masterブランチ：リリース用 普段の開発はdevelopmentブランチからブランチを切り、pull requestがapproveされたコードをdevelopmentブランチにmergeしていきます。そして、developmentブランチをstagingブランチにマージし、テストを行い、最後にstagingブランチをmasterブランチにmergeしリリースとなります。 Vue 3の変更もdevelopmentブランチからブランチを切り、変更後にmergeするという方法もあったのですが、以下の理由で現実的でないと判断しました。https://tech.stockmark.co.jp/blog/documentation_for_anews/Thu, 14 Dec 2023 17:00:00 +0900https://tech.stockmark.co.jp/blog/documentation_for_anews/エンジニアリングユニットの酒井といいます。 昨年の9月に入社し、Anewsの開発に従事しつつ時々SREっぽいこともしています。 今回は、自分が入社当初から改善したいなぁと考えていたAnewsのドキュメントについて、これまでやってきた取り組みについてお話しできればと思います。 取り組みを始めたきっかけ そもそも自分は組織開発において、ドキュメントが重要だという認識がありました。それはこれまでの経験則によるところもありますし、『Googleのソフトウェアエンジニアリング』中で以下のような言及があり、重要性を再認識したというのもあります。 10.2 何故ドキュメンテーションが必要なのか p220: ドキュメンテーションは長期的に見ると決定的に重要であり、決定的に重要なコードにとっては特に、組織がスケールするのに伴い途方もない恩恵をもたらす。 テストを書くことは普通になりつつありますが、ドキュメントに関してはまだまだな印象が個人的にはあります。書籍では以下のように言及されており、テストと比べると優先順位が下がってしまうのが理解いただけるのではないでしょうか。 10.2 何故ドキュメンテーションが必要なのか p218: ドキュメンテーションの恩恵は全て下流で生じるため、ドキュメンテーションの作者は通常、直に恩恵にあずかれるわけではない。[…]すぐにプログラマーの利益になるテストと違い、ドキュメンテーションは通常、より多くの労力が前もって必要で、後になるまで作者に明確な利益をもたらさない。しかしテストへの投資同様に、ドキュメンテーションに行われる投資は、長期的には回収できる。 またStockmark内部の話でいうと、比較的短いスパンで組織の動きが発生しており（ちなみに自分はこれまで4チームに在籍していました）、他方エンジニアも徐々に増えてきていました。それもあって、そう遠くないうちにドキュメントの重要性が高くなるなと自分は考えていました。 また元々Anewsの開発においては、PRDは作成されており、エンジニアが設計書を書くこともそれなりに行われていました。オンボーディング時も丁寧にフォローしていただいて困ったことはなかったのですが、開発を進めていくにつれて、欲しい情報にアクセスしにくいと感じることが徐々に増えてきていることに気づきました。 こういった状況もあり、まずは自分だけでちょっとづつ進めてみることにしました。ちなみにやるにあたってはドキュメンテーションに行われる投資は、長期的には回収できるという言葉にもあるとおり、すぐに効果のでるものでもないので、長期戦覚悟で取り組み始めました。 どのように進めたか 闇雲にドキュメントを作っていってもだめなので、いくつか段階を踏みながら進めていきました。 1. どんなドキュメントが足りないのか整理する まずはそもそも我々には何が足りないのか整理するところから始めました。『Googleのソフトウェアエンジニアリング』の中ではドキュメントには5つの類型があると書かれています。 10.5 ドキュメンテーションの類型 p226: ● コードのコメントが含まれたリファレンスドキュメンテーション ● デザインドキュメント ● チュートリアル ● 概念的ドキュメンテーション ● ランディングページ（landing page） Stockmarkでは会社の様々な情報をNotionで管理しています。開発用のドキュメントも同様で、PRDや設計書もNotionで管理しています。また各リポジトリのREADMEもしっかり機能していました。しかし概念的ドキュメンテーションやチュートリアル、ランディングページは存在しない、もしくは品質的に十分でない状況でした。そこでまずはこの3つのドキュメントを作成もしくはブラッシュアップすることに決めました。各ドキュメントがどのようなものなのかは後程説明します。 2. 対象読者とそのゴールを決める 対象読者とそのゴールを決めるのは重要です。『エンジニアのためのドキュメントライティング』では1章丸々使って、読者の理解に関するポイントを詳しく説明しています。対象読者やそのゴールが決まってないと記載内容がぶれてしまうので、更新をし続けていくうえでも、誰に向けた何のドキュメントなのかをはっきりさせておくことは重要です。 作成すると決めた3つのドキュメントに対して、以下のような対象読者とゴールを設定しました。 チュートリアル 対象読者：新たにジョインしたメンバー ゴール：Anews開発で必要な最低限の知識を習得できること 概念的ドキュメンテーション 対象読者：Anewsのエンジニアメンバー全員 ゴール：Anewsの概要と主要機能についての知識を習得できること ランディングページ 対象読者：Anewsのエンジニアメンバー全員 ゴール：Anewsの開発・運用で必要な情報がどこにあるのかわかること 3. どこに作るか決める ドキュメント専用ツールを自分たちで運用するのも一案ですが、管理するものを増やしてまでやるメリットが見いだせなかったので、既に我々が使っているツールで追加の運用コストがかからないものを選択肢として考えました。そうすると我々の場合だと、GithubかNotionが候補となります。この2つを比べた時に以下の理由により、Notion上に構築することに決めました。 ドキュメントOwnerにリマインドする機能がある リッチなUIが簡単にできる 記法に縛りがある 以下でそれぞれについて詳細を説明します。 ドキュメントOwnerにリマインドする機能がある ドキュメントは更新され続けることが重要です。それを補助する機能としてNotionのWikiには、ドキュメントOwnerに一定期間毎にリマインドする機能があります。 NotionのページをWiki形式に変換すると、配下のページにOwnerとVerificationを設定することができます。Verificationは認定マークみたいなもので、以下のように、いつまでこの認定マークを有効にするかを選択することができます。 NotionのVerificationの設定 この期限が切れたらOwnerにメールや画面上で通知が飛びます。 この機能によりOwnerが更新を忘れるといったことを防げるのではないかと考えました。 リッチなUIが簡単にできる Markdownだけでは表現が難しいリッチなUIが、Notionだと簡単に作成できます。またデザインに迷ったらテンプレートも豊富にあるため、それらを真似することも可能です。ちなみにNotionの普通のページをWiki形式に変換すると、それっぽいページに変換してくれます。自分のようなレイアウトを考えるのが得意でない人にとってはめちゃくちゃありがたい機能です。 記法に縛りがある Notionは記法にある程度縛りがあります。Notionの記法に則って書くことで、ドキュメントに統一感が生まれやすくなると考えています。 個人的に気に入っているのは、見出しが3階層しかないのでネストが深い文章が書けないようになっている点です。例えばこれをMarkdownでフリーフォーマットで書くと、いくらでもネストが深くできてしまうので、読み手に取って見づらくなってしまう可能性があります。 4. どんなものを作るか決める それでは3種類のドキュメントを具体的にどう作っていったかを説明したいと思います。https://tech.stockmark.co.jp/blog/202312_anews_batch_test_framework_migration/Tue, 05 Dec 2023 13:00:00 +0900https://tech.stockmark.co.jp/blog/202312_anews_batch_test_framework_migration/こんにちは、エンジニアリングユニットの飯森です。 先日、Anewsのバッチ処理のテストフレームワークを刷新するプロジェクトに取り組みました。 本記事ではこの取り組みについて紹介します。 本記事を読むことで、以下の2点が分かります。 バッチ処理のテストフレームワークの刷新をどのように進めたのか ストックマークでは工数がかかる改善施策にどのように取り組んでいるのか プロジェクトの背景 最初に、Anewsのバッチ処理とそのテストフレームワークについて説明します。 Anewsとバッチ処理 ストックマークはAI 情報収集プラットフォームAnewsを運営しています。 Anewsでは、ニュース、論文、特許といった様々な情報を国内外約35,000メディアから収集し、AIによる最適な情報配信を提供しています。 Anewsで配信されるコンテンツ（フィード）には様々な種類があります。 例えば、ユーザーの興味や嗜好に合わせたパーソナルフィードや、ユーザーが設定したキーワードにマッチするテーマフィードなどがあります。 これらのフィードは日々のバッチ処理によって生成されています。 Anewsを支える大規模バッチ処理 上図はAnewsのバッチ処理を定義しているAWS Step Functionsのワークフローです。 Anewsで日々の情報配信が行われるためには、このバッチ処理が安定稼働する必要があります。 バッチ処理の安定稼働を確保するためには、テストが不可欠です。 バッチ処理のテストフレームワーク バッチ処理のコードはPythonで書かれており、そのテストフレームワークとしてはmambaが使用されていました。 mambaを使用していた理由は開発者の学習コストが抑えられるためです。 AnewsのウェブアプリケーションのバックエンドではRubyが使用されており、そのテストフレームワークとしてはRSpecが使用されています。 mambaはRSpecと同様の記法でテストを書くことができ、mambaを使用していました。 ですが、mambaは2020年11月を最後に更新が止まっており、長期的に使用するには不安がありました。 このため、バッチ処理のテストフレームワークを刷新することが改善施策として挙げられていました。 改善施策のプランニング 次に、ストックマークにおける改善施策のプランニングについて説明します。 ここでの「改善施策」は、数週間程度時間がかかったり、複数チームの連携が必要になったりする、比較的工数がかかる改善施策を指します。 このような改善施策は、重要度が高いにもかかわらず、なかなか優先度を上げることが難しく、後回しにされることがよくあります。 そこで、ストックマークでは、重要な改善施策に関しては、組織の目標として計画に取り込み、実行する機会を確保しています。 具体的には、以下のような手順で改善施策をプランニングします： 各チームは次期に取り組む改善施策の候補をリストアップし、優先順位を付ける。 他チームとの連携が必要な施策については、各チームのリーダーが協議し、優先順位を調整する。 チーム内で各施策の担当者を決定し、担当者は次期の個人目標にその改善施策を組み込む。 このようにすることで、次期に取り組む改善施策の実行の機会が確保されます。 また、担当者の個人目標と結びついているため、改善施策を進めるインセンティブになります。 改善施策をどのように進め、いつ実施するかは、担当者の裁量に委ねられます。 また、改善施策を行うことについて組織で合意形成できているため、工数については担当者が必要なだけ確保できます（たとえば、今回のテストフレームワークの刷新プロジェクトは1ヶ月程度工数を確保して進行しました）。 一方で、改善施策とは別にプロダクトの機能開発も同時進行で進める必要があります。 このため、以下のように、チーム内で誰がどのタイミングで機能開発と改善施策に取り組むかを調整しながら進行します。 機能開発（上段）と改善施策（下段）の着手時期調整のイメージ このように、機能開発を進めながらも改善施策に取り組む機会を確保しています。 今回のテストフレーム刷新プロジェクトについても同様にプランニングしました。 また、私が志願して担当させていただくことになりました。 テストフレームワークの選定：pytest-bdd 新しいテストフレームワークを導入するにあたり、まずはテストフレームワークの選定を行いました。 調査対象とするPythonのテストフレームワークとして、以下のものを検討しました： pytest pytest-bdd behave radish Lattuce テストフレームワークの選定基準としては、社内事情を考慮し、以下のポイントを優先的に検討しました： 現在もメンテナンスが継続されていること BDD（ビヘイビア駆動開発）テストフレームワークであること 使いやすさ 1については、旧テストフレームワーク（mamba）の課題が、メンテナンスされていないことだったため、採用しました。 2については、Anewsのバッチ処理の各ジョブにはビジネス上の要求から様々な仕様を満たすことが求められます。 BDDテストフレームワークでは、システムに求める仕様を自然言語で記述しながらテストを書くことができます。 このため、何をテストしているかが分かりやすく、求められる仕様を全て満たしているか確認しやすいというメリットがあります。 また、旧テストフレームワークのmambaもBDDテストフレームワークであり、BDDテストフレームワークであればmambaで書かれたテストを書き直しやすい（テストを移行しやすい）というメリットもあります。 よって、2も選定基準に入れました。 3については、多少主観的な要素も入りますが、テストが書きやすい点も重視しました。この点については、各テストフレームワークで実際にテストコードを作成し、感触を確認しました。 これらの基準に基づき、最終的に選定したのはpytest-bddです。 behaveも上記の基準を満たしたのですが、pytest-bddはpytestのプラグインであるため、pytestの機能やプラグインを使える（特にテストの並列実行にも対応している）などを考慮し、pytest-bddに決めました。 新テストフレームワークの導入と運用 pytest-bdd関連のライブラリの導入とテスト環境の整備は、特に問題なく進められました。https://tech.stockmark.co.jp/blog/202311_stockmark_13b_instruct/Fri, 10 Nov 2023 10:00:00 +0900https://tech.stockmark.co.jp/blog/202311_stockmark_13b_instruct/Research部門の近江崇宏です。 先日、ストックマークではビジネスのドメインや最新情報（2023年9月まで）に対応した130億パラメータの大規模言語モデル（LLM）であるStockmark-13bを公開しました（Stockmark-13bの詳細に関しては、こちらのブログを参照ください）。 今回、Stockmark-13bに対して追加の学習を行い、ユーザーの指示に従うように訓練したStockmark-13b-instructを公開します。 モデルはHuggingface Hubからダウンロードいただけます。 Stockmark-13b-instructのライセンスはCC BY-NC-SAで、研究目的のみにご利用いただけます。 https://huggingface.co/stockmark/stockmark-13b-instruct 当社は理化学研究所の共同研究プロジェクトである「LLMのための日本語インストラクションデータ作成プロジェクト」に参加しており、このプロジェクトで作成されたインストラクションデータを用いて1、Stockmark-13b-instructの開発を行いました。 （追記）理化学研究所 革新知能統合研究センターからもプレスリリースが発表されました。 Stockmark-13b-instruct 先日、当社が公開したStockmark-13bは2200億トークンもの日本語のテキストで事前学習されたモデルです。 十分に訓練された事前学習モデルは流暢な文章を生成したり、fine tuningを行うことで様々なタスクに特化することができる一方で、そのままではユーザーの意図に沿った応答を行うことはできません。 LLMがユーザーの指示に従った応答を行うようにするためには、さらに追加の学習が必要です。 このために広く行われているのがinstruction tuningと呼ばれる学習で、これは多様な指示とそれに対する望ましい応答からなるデータセットを用いて学習を行うものです。 日本語のinstruction tuningのデータセットとしては以下のようなものがあります。 データセット 略称 データ数 言語 databricks-dolly-15k-ja dolly 15015 英語のデータセットを日本語に翻訳 oasst-89k-ja oasst 88838 英語のデータセットを日本語に翻訳 alpaca_ja alpaca 51716 英語のデータセットを日本語に翻訳 LLMのための日本語インストラクションデータ作成プロジェクト riken 1003 日本語 Instruction tuningでは、訓練に使うデータセットの質が最終的なモデルの性能に大きな影響を与えます。 最初の3つのデータセットは英語のデータセットを日本語に翻訳したものであり、データ数は多いものの、日本では馴染みのない話題や、日本語としては理解が難しいようなサンプルも含まれています。 「LLMのための日本語インストラクションデータ作成プロジェクト」は、このような既存のデータセットの課題に対応するために、日本語の質の高いデータセットを作成を目指したプロジェクトです。 データセットは現在作成の途中であり、現時点で公開されているデータ数は1003と他のデータセットに比べると少ないものの、データの質は高いものとなっています。 以下では、Stockmark-13bをそれぞれのデータセットで学習し、使うデータセットによって性能がどのように変わるかを評価しました。 ここでは学習の方法としてLoRA tuningを用いました。 結果としては、「LLMのための日本語インストラクションデータ作成プロジェクト」のデータセットで学習したモデルの性能が一番高いものになり、このモデルを公開することとしました。 Stockmark Business Questions まず最初に、先日のブログでも扱った、ビジネスや時事問題のドメインでの知識を問う50題の質問からなるStockmark Business Questionsを用いて評価を行いました。 モデルの出力の正解・不正解の判定は人の手により行いました。 下の表は学習に用いたデータセットごとにモデルの正答率をまとめたものです。 データセット 正解率 riken 0.86 alpaca 0.80 dolly 0.72 oasst 0.7 どのデータセットを使うかによって性能に差が見られ、性能は大まかには以下のような順になりました。 データ数としては少ないながらも、「LLMのための日本語インストラクションデータ作成プロジェクト」のデータセットで学習されたモデルの正答率が最も高い結果となりました。 riken > alpaca > dolly ~ oasst 以下は、「2023年8月に福島第一原子力発電所が海洋放出をおこなったものは何か？」という質問に対する回答例です。定性的には「LLMのための日本語インストラクションデータ作成プロジェクト」のデータセットで学習されたモデルは、その他のモデルに比べて、質問で聞かれたことを単に答えるだけではなく、より詳細に回答を行う傾向がみられました。https://tech.stockmark.co.jp/blog/about_data_intelligence_unit/Fri, 10 Nov 2023 09:00:00 +0900https://tech.stockmark.co.jp/blog/about_data_intelligence_unit/ストックマークでData Intelligence UnitでUnit Leaderをしている坂本です。 今回はこのData Intelligence Unit（通称データチーム）の取り組みを紹介します。 ストックマークのサービスについて ストックマークは、「Anews」と「Astrategy」という2つのサービスを提供しています。 現在我々はAnewsをメインで担当しているため、Anewsを中心にお話しさせていただきます。Anewsはニュース、論文、特許といった様々な情報を国内外35,000メディアから集めてデータベース化し、企業ユーザーに対してAIによる最適な情報配信を提供しています。既に非常に多くのお客様にご利用いただいております（参考：https://stockmark.co.jp/news/20220913）。このAnewsは以下のような特色があります。 エンタープライズ企業における情報収集をAIで最適化するという、未知の領域を開拓している 製造業の研究開発を中心に、様々な業種や職種のユーザーに使っていただいている 数千万に及ぶ記事データや論文・特許データなど、多種多様なデータを扱っている 組織全体で利用していただき、情報共有の場としても活用できる ニュースや論文、特許を扱ったサービスは数多くありますが、我々のサービスはビジネスに特化しており、ビジネスに関係した情報を中心に扱っていること、ユーザー1人1人のビジネス上のニーズにAIの力で的確に応える必要があることが大きな違いになります。 私の関心を可視化したワードクラウド 上記はAnewsのデータから最近の私の関心をワードクラウドにしたものです。最近のトレンドを反映して生成AIへの関心が非常に強くなっていますが、それ以外にもAI系のサービスを提供している各企業の動向ウォッチ、自分の職務であるデータ分析やデータマネジメント、お客様であるTDK様の動向など、私1人を例にとっても非常に多様な関心を持っていることが分かります。このような関心にフィットした情報を的確に届けることができれば、その人の業務生産性を大きく上げることができます。 （ちなみに、私は時間があれば各種ニュースサイトやSNSを見るほど情報収集好きですが、Anewsでしか出会えない情報も多く、1ユーザーとして手放せないサービスになっています。） しかし、個人のニーズを捉えることは簡単ではないですし、ビジネス向けだと組織の方針や業務ミッションが大きく影響します。そのような複雑な状況を的確に把握し、事業として成長するためにどのようなアクションを実行すべきかを考えるためには、データを活用してユーザーの解像度を向上し、機能リリースなどの施策が効果を上げているかを確認したり、データを基にして新たな仮説を生み出すといった取り組みが重要になってきます。 データ組織について データチームは2023年の5月に新設された組織で、社内のデータ活用を推進する役割を持っており、以下のようなミッションがあります。 社内のあらゆるデータを集約して誰でも活用できるようにするデータ基盤の構築と運用 データ基盤を基にデータ分析を行い、より良い意思決定を実現する データ基盤とデータ分析の知見を活かし、データ活用による顧客価値創出の研究開発 データ基盤の構築と運用 データ基盤は社内の各所に存在するデータを一箇所に集約し、裏側の仕組みを意識することなく社内の誰でも使えるような形にしています。 データの集約元としてはAurora, OpenSearch, Salesforceがあります。弊社のサービスはAuroraをDBとして採用しており、アプリケーションのデータだけでなく分析用のログも格納しています。また、これとは別に、ニュース・論文・特許を格納したOpenSearchが存在し、またビジネスプラットフォームとしてSalesforceもあります。 データ基盤の構成 アーキテクチャはBigQueryをベースとして構築しています。BigQueryに対して、troccoを使って各サービスからデータを転送してデータレイクに保存しています。データレイクに保存されたデータは、データウェアハウスおよびデータマートを通じて、BIツールにより社内のユーザーが利用できる形式で提供されています。 BIツールはRedashを中心に使っていますが、用途によってはスプレッドシートを使うことも多いです。Redashのクエリは一元管理しており、必要なクエリがあればSlackの専用チャンネルで依頼してもらい作成する形になっています。 データ分析の実施 データ基盤に集約したデータを基にしたデータ分析もデータチームで担当しています。 前述したように、Anewsはとても複雑度が高いサービスであるため、正解が分からないことも多く、分からないなりに仮説を立てて施策を実行し、それをきちんと評価することが重要です。そのためにデータ分析は重要な役割を担います。 具体的には各種施策で設定した目標が達成できているかを分析したり、他チームからの依頼で特定のテーマに沿った分析を行うこともあります。また、プロダクトマネージャーと協力して、KPIの設計やダッシュボードの作成も行います。それ以外にも、CSの方がお客様とコミュニケーションを行うために利用状況を可視化したレポートを使うこともあり、そちらの支援も行います。 定量的な分析が中心になりますが、ユーザーのニーズは多様で、かつビジネス向けだと単純な集計では把握できない様々な要因が複雑に絡み合うことも多いので、ユーザー1人1人を深掘りするN1分析も重視しています。N1分析では対象ユーザーをピックアップし、そのユーザーに関するデータをできるだけ多く集め、そこからインサイトを導き出します。データを集めるだけでもそれなりに大変なので、効率的にN1分析を行うためのツールを内製して使っています。 また、デザイナの方が実施するユーザーインタビューと組み合わせたり、ビジネスサイドの人の顧客インサイトも取り入れるなど、我々のチームだけに閉じずに社内全体で分析に取り組むように意識しています。 データを活用した研究開発 設立してから半年の間にデータ基盤の構築やデータ分析はかなり安定して行えるようになってきたのですが、より直接的に顧客価値にコミットしたいという想いがありました。そのため、データを活用した機能の研究開発もスコープに入れ始めています。 このミッションはまだ始まったばかりですが、以下のような内容を予定しています。 プロダクトの開発は別のチームが担当していますが、その中でもニュース配信などのデータ活用機能に対して、データ分析の知見を活かしたアルゴリズムの改善の提案や、リリース後の評価を行う 企画や開発を支援するためにユーザーの関心を可視化するモデルを研究開発する（前述したワードクラウドもこの研究成果を使っています） チームとして育つための取り組み データチームは私も含めて3人で構成されており、少数精鋭チームとなっています。データ活用はエンジニアリングやデータサイエンス、ビジネススキルなど必要とされるスキルが非常に広いため、日々スキルアップの取り組みをしています。 一例として、ストックマークの開発系のチームでは研究日という仕組みがあり、月に1日各個人でテーマを設定して自由な活動をすることが推奨されています。最近では、オープンソースのLLMを動かしてみたり、コンサルタントの思考術の本を読んだり、推薦システムに関する文献を調査するなど各人が様々なテーマに取り組みました。 今後の予定 設立して半年が経ち、かなり安定して業務を回すことができるようになってきていますが、まだまだやりたいことが山積みになっています。 以下に代表的なトピックを挙げます。 データ基盤のさらなる進化 データ基盤はまだ発展途上の状態です。データウェアハウス、データマートもまだ十分でなく、直接データレイクを参照しているクエリも多数存在している状態です。今後の事業成長や利用者の増加に合わせて、より堅牢で使いやすいものにしていく必要があります。 データ分析の質・速度向上 データチームはエンジニア出身のメンバーが多く、データ分析も手探り状態で始めました。半年の間に分析の型をかなり作ることができましたが、まだまだ質や速度を改善できると考えています。そのために、スキルアップの取り組みを継続的に行ったり、LLMなどを活用して一部を自動化していくことを検討しています。 データ民主化の促進 設立直後は社内にデータ活用のノウハウが十分に蓄積されていなかったため、データ分析はできるだけデータチームが担当することにしました。しかし、Anewsのような複雑度の高いサービスを成長させていくためには、社内の様々な役割の人の知見を統合して進めていく必要があります。そのためにも、今後はより全社でデータと向き合い活用する文化を作っていきたいと考えており、チームで獲得したノウハウを他チームにも展開していきたいと思っています。 新しい仲間を募集中です データチームの取り組みを簡単にご紹介しました。 ストックマークのサービスは未知の領域を開拓するものであるため、それを支えるデータ活用の取り組みがこれからさらに必要になっていくのは間違いありません。 この新しい冒険を一緒にしてくれる仲間を募集しておりますので、もし興味を持たれた方はぜひカジュアル面談をお申し込みいただけると嬉しいです。 気になった方はぜひ 採用ページ をご覧ください！https://tech.stockmark.co.jp/blog/202310_stockmark_13b/Thu, 26 Oct 2023 17:50:00 +0900https://tech.stockmark.co.jp/blog/202310_stockmark_13b/Research部門の近江崇宏です。 ストックマークではビジネスのドメインや最新情報（2023年9月まで）に対応した130億パラメータの大規模言語モデル（LLM）を商用利用も可能なライセンスで公開しました。 モデルはHuggingface Hubからダウンロードいただけます。 https://huggingface.co/stockmark/stockmark-13b このモデルは、合計2200億トークンの日本語のテキストデータにより事前学習が行われました。 一般に事前学習でよく使われるWikipediaやCommonCrawl由来のコーパスだけではなく、当社が独自に収集しているビジネスに関連するWebページや特許などのデータも用いました。 そのため、既存のモデルに比べると、最新の情報やビジネスのドメインに対応したようなモデルになっております。 実際に、ビジネスに関連する知識を問うタスクでは、既存のモデルに比べて高い性能を示し、今回開発したモデルがビジネスや時事問題のドメイン知識を獲得していることがわかりました。 また、日本語の言語理解のベンチマークであるJGLUEの中で、特に与えられた文脈の中から質問に答えるJSQuADでも、高い性能を示すこともわかりました。 開発にあたっては、AWSのLLM開発支援プログラムの支援を受けました。 また、この開発は国立研究開発法人産業技術総合研究所との共同研究の一環で行われました。 モデルの概要 今回のモデルのアーキテクチャーは130億パラメータのLlama2を用いております。 モデルの事前学習では、ハードウェアアクセラレーターとしてはAWSが開発している機械学習アクセラレーターであるTrainiumを、ライブラリとしてはTrainium上で分散学習を行うためのライブラリであるneuronx-nemo-megatronを用いました。 事前学習に用いた日本語のデータセット（合計約2200億トークン）の構成は以下の通りになっており、既存の同規模のモデルと比べると、日本語のデータの規模が大きく、多様性も高いものとなっています。 CommonCrawlは2023-23、2022-49、2022-21、2021-21のスナップショットを用いました。 評価 ビジネスに関連した知識 今回開発したモデルが実際にビジネスのドメインに関連した知識を獲得しているかどうかを評価するために、市場動向、時事問題、社会課題、ビジネストレンドなどの知識を問う問題を50題作成しました。 評価にあたっては、今回作成したモデルと、以下の既存の同規模の3つのモデルの事前学習済みモデルを用いました。 llm-jp/llm-jp-13b-v1.0 pfnet/plamo-13b matsuo-lab/weblab-10b また、参考のためにChatGPTも評価に追加しました（以下、ChatGPTのバージョンはgpt-3.5-turbo-0613を使いました）。 評価にあたっては、まず、それぞれのモデルに対して、日本語に翻訳されたAlpacaデータセットでInstruction tuningを行いました。 事前学習のみをおこなったLLMだと、必ずしも意図に従って応答を行なってくれないという問題があり、またInstruction tuningされたモデルにしても、応答の質やスタイルが、どのようなデータセットでInstruction tuningを行うかに大きく依存するため、このように各モデルを同じ方法でInstruction tuningしてから、評価することにしました。 モデルの出力の正解・不正解の判定は人手により行いました。 結果として、ChatGPTを含め既存のモデルに比べると高い性能を示すことがわかり、私たちのモデルは最新の情報やビジネスのドメインの知識を獲得していることがわかりました。また、私たちが今回用いた独自のビジネスに関連するWebコーパスは全体のデータセットの中では4-5%程度と小さな割合しか占めていないが、それでも100億パラメータ規模のモデルではドメイン知識が一定獲得できるということも示しています。 私たちのモデルのみが正しく答えられたようなQAの具体例は以下のようなものとなっています。 Question: 2023年3月に経営破綻したアメリカの2つの銀行は？ Question: ダークストアとは？ 日本語の言語理解 日本語の言語理解のベンチマークであるJGLUEを使った評価も行いました。ここでは質問回答のタスクとしてJSQuADとJCommonsenseQAを対象とし、lm-evaluation-harnessを用いて評価を行いました。ここでは、事前学習のみを行なったベースモデルを対象としました。 その結果、同規模のモデルと比べて高い性能を示し、特にJSQuADでは最も高い性能を示すことがわかりました。 stockmark/stockmark-13bとllm-jp/llm-jp-13b-v1.0では、few-shotの提示数はJSQuADでは2、JCommonsenseQAでは3としました。プロンプトのバージョンはJSQuADでは0.2、JCommonsenseQAでは0.3を使いました。 pfnet/plamo-13bのスコアは次のページから取得しました：https://tech.preferred.jp/ja/blog/llm-plamo/ matsuo-lab/weblab-10bのスコアはこちらのページから取得しました。 テキスト生成の効率性 ChatGPTとの比較 ChatGPTと比較すると、パラメータ数が100億の規模のモデルを使うメリットとして、テキスト生成を高速に行えることが考えられます。そこで、実際にテキスト生成の速度の比較を行いました。私たちのモデルからテキスト生成を行う時には、DeepSpeedのライブラリを用いました。 1秒あたりに生成される文字数を計測したところ、私たちのモデルはChatGPTに比べて、約4倍高速であることがわかりました。これは実際に試してみると体感としても、大きな差になります。 同規模のモデルとの比較 また、私たちのモデルと同規模のモデルとの生成の効率性の比較も行いました。この実験では、DeepSpeedを用いた前項とは異なり、Hugging Faceのtransformersのgenerate関数を用いてテキスト生成を行いました。これは、一部のモデルではDeepSpeedを使っても処理時間があまり短縮されない場合があったからです。上と下の表でstockmark/stockmark-13bの1秒当たりの文字生成数が異なっているのはそのためです。 その結果、同規模なモデルの中では、私たちのモデルが最も生成速度が速いことがわかりました。 この一つの要因はトークナイザにあると考えられます。上の表に、CC100の日本語のデータセットから見積もられた1トークンあたりの平均文字数を示しています。私たちのモデルはこの値が高く、効率よくテキストをトークンに変換できていることがわかります。トークン化の効率に差が起こる要因としては、トークナイザの語彙数、トークナイザの語彙が日本語のみか日英混合か、トークナイザ学習時にデータに対して事前分割を行うかどうかなどが考えられます。https://tech.stockmark.co.jp/blog/about_knowledge_unit/Tue, 22 Aug 2023 10:00:00 +0900https://tech.stockmark.co.jp/blog/about_knowledge_unit/Stockmark の Researcher の広田です。 Stockmark には自然言語処理の研究開発を行う Research チームがあり、 その中の1つの組織に知識グラフの自動構築をテーマとする Knowledge Unit があります。 この記事では Knowledge Unit の取り組みを紹介します。 なぜ知識グラフなのか？ ストックマークは企業向けの情報収集ツール Anews を提供しています。 私たちはよくお客様から、まだ自分たちが気づけていない情報があるのではないか不安だ、という声を耳にします。 市場動向や技術動向・競合他社情報などから気づきを得ることはビジネスにおいて非常に重要です。 一方で気づきを得るための情報収集はとても大変です。 インターネット上では日々膨大な量のテキストが公開されており、これらを人力で収集し尽くすことはとても難しくなっています。 また収集を行うにはその分野の専門的な知識も必要になるため、あまり詳しくない分野の情報を調べるのはとても難しい問題です。 私たちはこうした問題を解決する技術として知識グラフに着目しています。 私たちが日々 クロールしている ニュースや論文・特許・オントロジーなどのオープンデータ、 そしてお客様のビジネス情報を1つの知識グラフ上に構造化することで、 膨大なテキストデータから日々質の高い気づきをお届けするサービスを目指しています。 なお、 Knowledge Unit は東北大学自然言語処理研究グループとの共同研究を行っています。 今の Knowledge Unit の取り組みは？ 私たちは現在製造業分野の知識の構造化を進めており、 製造業で特に重要となる知識を次の 4 つのカテゴリに分類しています。 構造化を進めている製造業の知識 これらの知識をテキストなどの非構造データから自動拡充することが私たち Knowledge Unit のテーマです。 ここで鍵になるのが relation extraction, entity linking という 2 つの技術です。 Relation extraction Relation extraction はテキストで言及されている概念間の関係を推定するタスクです。 例えば以下のニュース文を考えてみます。 トヨタでは新たな生産方式によって部品点数の大幅な削減を図ることができ、生産工程や生産にかかる期間を短縮できるほか、生産コストの抑制にもつながるとしています。 (引用: https://www3.nhk.or.jp/tokai-news/20230724/3000030634.html) このニュース文からは次のような関係 (triple) を得ることができます。これが relation extraction です。https://tech.stockmark.co.jp/blog/202308_gpt_neox/Tue, 08 Aug 2023 11:00:00 +0900https://tech.stockmark.co.jp/blog/202308_gpt_neox/Research部門の近江崇宏です。 今回、ストックマークは最近の話題にも詳しいGPT-NeoXをベースとした14億パラメータの日本語のLLM（大規模言語モデル）をオープンソースとして公開します。モデルはHugging Face Hubからダウンロードいただけます。 https://huggingface.co/stockmark/gpt-neox-japanese-1.4b 当社はビジネスにおける情報収集・分析をサポートするサービスを運営しており、そのために最新のWebデータの収集を日々行なっております。今回の事前学習では、一般にLLMの事前学習によく使われるCommon Crawl由来のデータだけでなく、当社が所有している独自のWebデータ（2023年6月まで）も含めて事前学習を行うことで、最近の話題にも詳しいモデルを開発しました。具体的には、事前学習に用いたデータセットはCC100の日本語サブセット、Wikipediaの日本語版、当社独自の日本語Webデータから構成されています。コーパス全体でのデータ量は約200億トークンで、そのうち当社独自のWebデータは約90億トークンほどです。モデルのアーキテクチャの詳細などは以下をご覧ください。 https://huggingface.co/stockmark/gpt-neox-japanese-1.4b/blob/main/config.json また、今回の事前学習モデルの構築は国立研究開発法人産業技術総合研究所（産総研）との共同研究の一環で行われ、事前学習も産総研の計算インフラストラクチャであるABCIで行われました。 当社は今後も大規模言語モデルを活用したサービスの向上を進めていくだけでなく、研究開発で得られた言語資源の公開などを行うことにより、日本語の自然言語処理の発展に貢献します。 実際の出力例 今回は、2021年9月までのデータにより学習されているChatGPT（つまり最近の話題については知らない）と本モデルに対して、最近の話題を入力してその出力を比べてみました。 また、当社のモデルはInstruction tuningをしていないので、必ずも質問に対する回答の体を成していないこともあります。また出力に事実でないことが含まれることには注意が必要です。 お題1: 「最近の画像生成AIをいくつか教えてください。」 当社のモデルは、2022年以降に登場したStable DiffusionやMidjourneyなどのモデルを知っていることがわかります。 本モデルの出力 「Stable Diffusion」は、テキストから画像を生成するAIで、「Midjourney」「DALL・E2」「Stable Diffusion 2.0」などが有名です。「Google Colaboratory」で試すことができますが、GPUやメモリなどのリソースを消費するので、今回は割愛します。 「Midjourney」は、入力したテキストを学習して画像を生成してくれるサービスです。日本語にも対応していますし、無料で使えるので試してみてはいかがでしょうか? 「Stable Diffusion」は、テキストを入力するとそれをもとに画像を生成してくれます。こちらも無料なので試してみてください。 ChatGPTの出力 申し訳ありませんが、私の知識は2021年の9月までのものであり、最新の情報は提供できません。2021年までの時点で、いくつかの人気のある画像生成AIは以下の通りです： DALL-E: オープンAIによって開発されたAIで、テキストの指示に基づいて画像を生成することができます。例えば、「ピンク色の雲の上に浮かぶ眼鏡をかけたカエル」などの指示を与えると、それに合った画像を生成します。 StyleGAN: NVIDIAによって開発されたAIで、特にリアルな顔写真の生成に優れた性能を持っています。StyleGAN2やStyleGAN2-ADAなどのバージョンもあります。 BigGAN: Google Brainによって開発されたAIで、高解像度な画像を生成することができます。大規模なデータセットを使って高品質な画像を生成します。 VQ-VAE-2: DeepMindによって開発されたAIで、高品質の画像生成とベクトル量子化技術を組み合わせています。 これらは2021年までのものであり、その後も多くの新しい研究や開発が進んでいることでしょう。最新の情報を得るには、2023年現在の情報源や研究論文などを調査することをお勧めします。 お題2: 「ラピダスはどのような企業？」 ラピダスは2022年に設立された日本の半導体メーカですが、当社のモデルは事業内容や出資した企業など正しく答えられました。（ただし、正確には設立は6月ではなく8月です） 本モデルの出力 「日本の半導体産業の復活」をうたう、次世代半導体の国産化を目指す新会社。その名は「Rapidus」。2022年6月7日、トヨタ自動車やNTTなど8社が出資して設立された。 ChatGPTの出力 私の知識は2021年9月までの情報に基づいているため、"ラピダス"という企業について直接的な情報は持っていません。もし、それが私の知識の範囲外の新しい企業である場合や、他に何か具体的な情報があれば、それに基づいてお答えすることができるかもしれません。 一般的に企業に関する情報を知りたい場合は、インターネット検索エンジンを使って最新の情報を調べることをおすすめします。そうすることで、ラピダスについてより詳細な情報を見つけることができるかもしれません。 皆様も、色々と試していただければ幸いです！ 最後に 今回の14億パラメータの日本語LLMの公開に伴い、LLMの自作・活用方法をソフトウェアエンジニア向けにシェアします！ 機械学習・自然言語処理の知見をお持ちでない方にもわかりやすくお伝えしますのでぜひご参加ください！ 参加登録は下記URLよりお願いいたします。 https://stockmark.connpass.com/event/292468/https://tech.stockmark.co.jp/blog/engineer_recruiting/Thu, 03 Aug 2023 18:00:00 +0900https://tech.stockmark.co.jp/blog/engineer_recruiting/こんにちは、エンジニアリングユニットの岩谷と申します。今回はエンジニア組織と、採用の観点について記載していきたいと考えています。 動機は２つあり、 選考プロセスを進めた上で組織・人の面を見て魅力的に感じていただけることが多く、選考前の方にもしっかり発信していきたい 文面だけでは見えないカルチャーやマインド面での相互不一致を減らしたい 何かしらのきっかけでストックマークにご興味を持っていただいた方（まだ興味がない方も！）には、是非１度読んでいただけると幸いです。 組織の特徴（仕組みの面） 現在20名ほどのエンジニアが所属しており、プロダクト開発２チーム、ML処理基盤、オープンデータ、SREの５チームにわかれています。 プロダクト開発チームはPdM・Designerとの一体チームで運用しており、チーム内の運用方法は各チームに委任されていますが、スクラムに近い運用で、KPTAなどしながらチームの運用自体も自己改善していくようにしています。 開発内容の流れとしては、PdM・BizDevを中心に作成する大枠のロードマップと、エンジニアが主体的に計画する改善施策の２つがメインで、これらを具体的にどのように進めていくかはPdM・Engineer間で定期的にすり合わせを行い決めていきます。 よくある「改善施策」と「新規開発」の優先度問題は割り切りで考えており、エンジニア全体の２、３割を目安に改善活動にリソースを当て続ける大方針を置いており、改善稼働は確保する前提で新規開発の計画も調整をしていきます。 エンジニア内でのタスク分担については、得意スキルと伸ばしたい領域を考慮した上で、専門領域は決めずにチーム内で調整して新しいことにもチャレンジできるようにしています。これは本人のためもありますが、マルチスタックなエンジニアが増えることが組織全体の生産性を上げることに繋がると考えているからです。 （最近Joinしたメンバーの入社前後ギャップとして、「マルチスタックに開発に携われるという点は、想像以上に徹底されていてびっくりした」という声もあったので、客観的にもちゃんと運用できていると思います笑） 組織の特徴（文化面） 現在エンジニアリングユニットのバリュー制定を進めており、その中で全エンジニアから声を集めました。全体を俯瞰する中で見えてきた組織の文化について記載していきます。 顧客・プロダクト志向 研究日（月に１日、学習やプロトタイピングなど、自由に活動して良い日を設けています）に自分のアイデアを形にしてみたり、顧客のためになるなら早くリリースしたいなどの声がありました。企画の主体はPdMだとしても、一緒に価値を作っていくチームとしてそこに興味がないとコミュニケーションもうまく行きづらいので、会社としても重視していますし、実際にそういったマインドのメンバーが集まってくれていると思います。 改善意識が高い 開発体験の向上意識が高い、ポストモーテムが徹底されているなどの声がありました。おかしいと感じた部分についてKPTAの場などで課題提起したり、すぐ直せるものならさっさとPR出してしまうなど、ボトムアップでの改善活動に主体的なメンバーが多いと思います。 協力・相互支援 ペアプロや、設計の相談など、協力的なチームであるという声がありました。ウェットなコミュニケーションを大切にしていますが、強制はせず、求める人には親身に協力してくれる人が多いと思います。チームがわかれていますが、どうしても得手不得手などはあるので、案件によっては設計検討の支援に他チームのメンバーが入るなど柔軟な動きも多いです。 技術的探求心 特に経験年数の短いメンバーは得意領域を軸にしつつもスキルの幅を広げていきたいという声がありました。ベテランでも、サーバサイドのアーキテクト・ML Engineeringなどメインでやってきた方がVue.jsの開発をしだしたりしています。有志での勉強会も現在２つ週次で行われています。 どのような方にJoinしていただきたいか？ 今までのキャリア、実績に加え、今後の成長性込でポテンシャルも加味して判断するようにしています。現在の技術スキルだけではなく、今後どう伸ばせるかという観点も大事にしています。成長性やポテンシャルを判断する上で、ポイントになることが多かった観点を記載していきたいと思います。 技術面 触れてきた技術に対して深掘りを行い、体系的に理解（メリデメなど含む）をした上で活用しているか。世の中には多くの技術や手法がありますが、何をどう活用すべきかは事業特性やメンバー特性など様々な変数で左右されます。自分たちの組織にとってプラスになる技術的選択を行う上ためには深掘りと体系的な理解が欠かせないと考えています。 また、一定期間チームの開発のご経験がある方の場合は、実装やテスト・レビューなどを行う上で、チーム目線と、中長期目線を持てているかというのも重要な要素になると考えています。 自律性 ただ割り当てられた仕事をこなすだけではなく、違和感や課題を放置せず、提起および改善に向けた行動に繋げているか。組織として、全社的な戦略ももちろん重要ですが、お客様・ソースコードなど事業の中核をなす物理的な要素に最も触れているのは現場であり、現場だからこそ気付ける課題やアイディアを活動にのせていくことが重要だと考えています。 成長性 より高い成果を出せるようになるために自発的な行動が行われているか。仕事の中では、技術面や自律性に記載した部分への取り組み方をニアリーイコールで成長性として捉えることが多いです。また、特にジョブチェンジなどキャリアの短い方については、動機・熱力を持っているか、具体的に副業や自主開発などでスキルを埋める行動を起こしているかといった点が重要だと考えています。 採用状況・窓口について ストックマークではソフトウェアエンジニアを採用しています！特に事業的にはIPO前の最後かもしれない大きな開発チャレンジの企画が動き出しており、非常に面白いタイミングだと思っています。 話を聞いてみたいと感じていただけたらこちらより気軽にお問い合わせください！ （某採用媒体様のアンケートで、採用候補者様から継続的に平均以上の満足度の評価をいただいていますので、ご安心してご連絡いただければと思いますｗ）https://tech.stockmark.co.jp/blog/what-dev-teams-have-in-mind/Mon, 03 Jul 2023 08:00:00 +0900https://tech.stockmark.co.jp/blog/what-dev-teams-have-in-mind/はじめに どのスタートアップ企業でも、プロダクトリリースサイクルの高速化・最適化を心がけているかと思います。本記事では、ストックマークのプロダクトである Anews の新機能（論文配信）を例にとって、ストックマークの開発の実際について紹介いたします。 本記事から学べる点は大きく 3 点です。 高速な価値提供を実現するために意識すべきこと フロー効率の極大化によりユーザー価値へつなげる方法 中期目線で開発速度を保つ方法 それでは、それぞれ個別に 1 つ見ていきましょう。 高速な価値提供を実現するために意識すべきこと どんなプロダクトであっても、実装しようとしている機能は、何らかの方法で検証してみるまで顧客にとって必要なものか分かりません。本記事のテーマである論文配信機能についても同様ですが、少なくともユーザーインタビューなどの仮説検証で一定のニーズは確認できていました。 ニーズまでは確認できているので、実際にミニマムな機能を提供することで、仮説検証を進めます。ミニマムといっても、開発着手時点で実装可能な候補がたくさんあります。その候補の中から、いかに何も作らずに仮説検証できるか、そのために仮説検証対象を削ぎ落としていくのが重要です。 今回はその実現のために、”最新データの追従” を最初は盛り込まずに検証する、というアプローチを取りました。こう書くと簡単なように見えますが、機能追加先のプロダクトである Anews は、毎日最新の情報を提供するプロダクトであるため、最新情報が届かないことはユーザーにとって違和感があるかもしれません。しかし、まずユーザーに価値があるかどうか判断するために、最新データを常に追従を当初から実装しないという意思決定をしています。（さらにいえば、最新データをどの程度の頻度で取得・更新すべきか、も検証する必要があります） 論文データを取得する方法もいくつかありますが、今回は SemanticScholar に決定しました。SemanticScholar は検索による科学文献のデータ提供および、API により 2 億件以上の論文を含む科学文献のデータを無料で取得可能な機能を提供しています。こちらの決定要因も、まず仮説検証が迅速にできることを重要視した点にあります。 このように、高速な価値提供を実現するために徹底的に価値の本質を見極めることを重視しています。 なお、SemanticScholar には公開されているスキーマが存在しません。今回調査した情報は弊社公開 Notion ページにまとめておりますので、参考にご活用ください。 フロー効率の極大化によりユーザー価値へつなげる方法 論文配信の提供を始めると実際にユーザーの行動ログやユーザーのフィードバックが集まり始めます。まず、当初の狙い通り、実際に論文が読まれることがまず検証できました。さらに利用ログを確認していると面白いことが 1 つ分かってきました。 それは、わずかしかない日本語の論文が想定されるより優先して読まれているということです。SemanticScholar は日本語の論文に注力しているわけではないため、全論文量の 2%程度しか日本語論文が含まれていません。その日本語論文が読まれやすいことがわかったわけです。 この知見をもとに、日本語論文の強化を検討しはじめます。今回は、国立情報学研究所が提供する CiNii について、CEO の林がコメントしたのをきっかけに、CiNii のデータ取り込み・論文提供まで 1 ヶ月弱で実現しました。 この裏側で意図していたのがフロー効率重視の考えです。本機能の価値が高いと判断したため、他の機能開発のし掛かりを並行して進めるのではなくむしろ止めて、国内論文の拡充に集中して開発を進めました。 ちなみに、こちらの機能提供により、論文の閲覧数が 5 倍以上に増加しており高いニーズがあったことが確認できています。 論文閲覧数のグラフ 中期目線で開発速度を保つ方法 ある程度の開発経験のあるエンジニアであれば、よほど大きな機能でない限り、1 人で作り切ってしまった方が早いことがあります。今回の論文配信機能の開発裏側では、まさに開発メンバー 1 人で実装を進めていました。 一方で、1 人で開発を進めていると中長期的に見て開発速度が落ちていくリスクがあります。たとえば、開発メンバーが体調不良になった場合、そのメンバーが回復するまでに開発が止まりかねません。 そこで、論文配信の機能が継続的に提供されるとわかった段階で、徐々にプロダクト開発に携わるメンバーを増やすように進めてきました。具体的には、新しい機能については、別の開発メンバーと共同で開発するようにします。 そのため、別の開発メンバーが参加しやすいように、「背景」を重点的にドキュメントに起こしておきます。機能や処理に関してであれば、ソースコードから一定理解できます。一方で、その実装に至っている背景については、コメントに手厚く書いておかない限りソースコードからは読み取れません。ドキュメントに背景を残しておくと、長期的に開発速度が落ちにくくなります また、今回の実装では全体のインフラ構成も複雑であったため、事前に鳥瞰図を準備しておきました。2023/6 時点の設計・実装はやや異なりますが、当時準備していたものを参考までに掲載いたします。 当時のインフラ構成 これらの準備によって、途中から開発に参加する場合であってもスムースに入れたようです。 まとめ 本記事では、ストックマークの開発で意識していることを重点的に紹介しました。ユーザーに価値をいかに早く届けられるか、そして中期目線で開発速度を落とさないための取り組みを紹介しました。 本記事では技術的な詳細はそこまで触れておりませんが、 もしご興味あれば是非カジュアル面談でお話させてください。こちらより気軽にお問い合わせください！https://tech.stockmark.co.jp/blog/noise_reduction_en/Tue, 16 May 2023 15:50:00 +0900https://tech.stockmark.co.jp/blog/noise_reduction_en/Motivation When crawling articles from the internet, the output is usually in HTML format. This HTML includes the page text, structure, and styling information but may also contain a lot of non-content information, such as author description, advertisements, links to other articles, and other metadata. It is possible to differentiate non-content text from HTML by leveraging CSS styling information as well as HTML tag names. For example, in some articles, colorful or italic text is very likely to be noise.https://tech.stockmark.co.jp/blog/noise_reduction/Mon, 08 May 2023 09:00:00 +0900https://tech.stockmark.co.jp/blog/noise_reduction/本記事執筆時点の2023年4月時点で、ChatGPTのニュースを見ない日はないほど、世の中にChatGPTの記事が溢れています。「こんなことに使える」「あんなことに使える」と応用範囲が広いChatGPTですが、「あたかも当然のように嘘をつく」ように決して万能なわけではなく得手不得手があります。そんなChatGPTに対して、プロダクト開発側に立つ方にとって気になるのは「実際にプロダクトに組み込めるのだろうか？」という点でしょう。 そこで、本記事ではストックマークのプロダクトで実現している「記事中にあるノイズ削除」にフォーカスして、自社で利用するモデルとChatGPTとを比較していきます。なお、プロダクトに組み込む場合は、ChatGPTではなくAPIを利用するケースが自然ですが、GPT-4ベースのAPIを執筆時点で利用できなかったことから、ChatGPT Plus(GPT-4)を利用しています。 本記事は以下の3点を中心に紹介します。 前提: 記事中のノイズ削除がなぜ必要なのか？ どのようにストックマークでノイズ削減を実現しているか？ ChatGPT との比較 前提: 記事中のノイズ削除がなぜ必要なのか？ ストックマークの自社プロダクトでは、Web上にあるニュース記事からの「意味のあるテキストの抽出」を実現しています。Webに溢れるコンテンツはさまざまな理由からノイズ（広告、記事のメタデータ）を含んでいます。 たとえば、次の画像では段落の間に外部へのリンクが挿入されており、これは記事の本旨からするとやや外れた内容になっています。 ノイズを含む記事イメージ そのまま活用すると、必ずしも読み手にとって最適な情報を提供できるわけではありません。そのため、ユーザーにとってより価値のある情報提供するために、記事中にあるノイズを削除する必要があります。 どのようにストックマークでノイズ削減を実現しているか？ 特定のWebサイトに限れば、HTMLのスタイリング情報(CSS)やセマンティックタグの活用によるノイズを含まない情報抽出は可能です。しかし、膨大なニュースサイトに対して統一的なルールセットを用意・適用するのは現実的ではありません。Webサイトの構造は変化しますし、なにより誤ってHTMLタグが利用されていると、記事中の重要コンテンツを落としてしまうことすらあります。 そこで別の方法として、HTMLから文字列を抽出して、その文字列に対してノイズを削除する方法があります。ストックマークではこちらの方法を活用しています。なお、単にテキストを抽出というと、完全に構造情報が失われるように思われますが、ここは一工夫を加えています。具体的には、異なる対象から抽出されたテキストは、2つの連続する改行である \n\n で区切りを設けるなどいくつかの区切りを設けています。 上記で抽出されたテキストを入力として、自社で開発したモデルを利用してノイズを除去しています。具体的に言えば、2つのモデルを活用しています。1つはSklearn MLPClassifierです。もう1つの言語モデルには、日本語のBERTモデルである BERT base Japanese (IPA dictionary) をファインチューニングしたものを利用しています。 これらのモデルを活用して、さまざまな区切り文字列を活用して「この文はノイズかどうか？」を0から1の間でスコアリングして、ノイズ度を出力します。文章の階層構造などの文字列以外のより上位の情報の活用により、文脈を考慮した精度向上も狙えますが、たいていは文脈を考慮せずとも判断できるため、ここでは文そのものに着目しています。 ChatGPT Plus(GPT-4) との比較 ChatGPT の効果的な活用方法として、プロンプトエンジニアリングガイドなども公開されていますが、ここでは Zero-shot 方式でノイズ削除を試みた例を紹介します。プロンプトはシンプルに 本文の箇所だけを、文字を変更せずに出力してください。 としています。 試行例は複数ありますが、わかりやすいものを1つキャプチャにて紹介します。 ChatGPT(GPT-4)によるノイズ削除キャプチャ 赤枠①で明示したように、不要な情報が削除しきれていません。また赤枠②の箇所から分かるようにChatGPTの制約から、出力トークン数に制限があり文が途中で終わっています。さらに、キャプチャでは明示していませんが、実行ごとに出力結果が変わることがあります。 その他の点も含めてまとめると次のようになります。 項目 ストックマークのモデル ChatGPT 正確さ 常に元の記事を維持したままノイズ削除可能 元の記事が失われ、短い要約になることがある 速度とコスト 10億パラメータのBERTであり高速で実行可能。また文レベルの推論であり効率的 より長い処理時間および高いコストがかかる ロバスト性 複数回の同じ入力に対して常に同じ結果が得られる 厳密なプロンプト調整が必要であり、応答が一定せずプロダクション環境での利用に難しさがある まとめ 本記事では、プロダクトの応用に向けてChatGPTと自社モデルとの比較を紹介しました。ChatGPTは非常に強力なサービスですが、適用範囲に得手不得手があります。そのため、実際の本番プロダクトに組み込む場合には、スコープを限定したより効率的なモデル作成が効果的です。https://tech.stockmark.co.jp/blog/perceiverio_recommender/Thu, 20 Apr 2023 09:00:00 +0900https://tech.stockmark.co.jp/blog/perceiverio_recommender/Introduction Web services usually require many different types of recommender systems using large amount of user log and content data. It is no different for Stockmark! For example, news article, category and keyword recommenders are some of the recommendation services that run in our news distribution and analytics platforms Anews and Astrategy. There is also demand for different kind of recommendation tools, such as user recommendation. On the other hand, it is challenging to design different models for each recommender task.https://tech.stockmark.co.jp/blog/aws_cost_optimazation/Wed, 19 Apr 2023 09:30:00 +0900https://tech.stockmark.co.jp/blog/aws_cost_optimazation/クラウドインフラに関わるコストは、各企業にとって1つの重要テーマかと思います。毎月、支払うコストであり、数％の増減であったとしても最終的にかなりの金額になります。 昨今の為替事情もあり、そんなクラウドインフラのコストを弊社で削減してきた方法を本記事で紹介いたします。本記事を読むことで、実例と共に手法を学んでいただけます。 何を実施したか？ ストックマークでは、クラウドインフラに AWS を活用しています。AWS のコスト削減のプラクティスは広く知られており、公式からもドキュメントが提供されています。 具体的な方法の中からいくつか代表的なものを取り上げると次のような項目があります。 コスト分析と監視 リザーブドインスタンス、スポットインスタンスの活用 オートスケーリングの活用 ストレージの最適化 データ転送の最適化 リソースの削除や停止 たとえばリザーブドインスタンスの導入といったすでに利用中なものもあります。本記事では、昨年度下期に実施した以下の3つ、特にストレージの最適化に焦点を当てて紹介します。 コスト分析と監視 ストレージの最適化 リソースの削除や停止　（本記事では割愛） コスト分析と監視: コストが高い要素の把握 「推測するな、計測せよ」という格言があるとおり、パフォーマンスのみならずコストについても、まずは実測されているデータに注目するのが第一です。コストは自動的にAWS側で計算されているため、そのコストの内訳を確認するのが初手になります。 ストックマークでも、コストを定期的に確認しています。本記事では、一定のインパクトのあった S3 のコスト削減について紹介していきます。 ストレージの最適化 今回のコスト削減では、クラウドストレージとして利用していた AWS S3(Simple Storage Service) のストレージクラスを AWS S3 Glacier へと変更しました。 Glacier はアクセスが遅い、という欠点があるもののコストは非常に安価です。そこで、ユースケースがハマれば、コスト削減につながる有力な手段になり得ます。 もちろん、結論だけ切り取ってしまえば、非常に簡単な処理であるため「単にちょっとした変更をするだけでは？」とお考えになるかもしれません。しかし、現実には S3 に蓄積しているデータを活用する業務フローがいくつかあるため、既存業務にインパクトを与えない、もしくは与えたとしても問題のない方法で移行する必要があります。 コスト試算時の注意点 次に移行に関わる作業・影響調査に着手する前に、 Glacier に移行時のコストを試算しています。試算の結果、一時的にコストが増えるものの3ヶ月でペイしそう、と分かってきました。 詳細な金額は掲載していませんが、試算コストのイメージがわかる画像を以下に載せておきます。 AWSの移行前後のコスト試算イメージ なお、試算時にはオブジェクト数やメタデータも考慮に含めてください。利用タイプによってはコストに効いてくる可能性があります。 ストレージクラスの変更に伴う影響調査 コスト削減につながることがわかったため、次はストレージクラスの変更に伴う実影響を把握しにいきます。ここは、実際にS3を利用している各メンバーへのヒアリングや、S3を利用しているプロダクトコードの調査といった地道な作業が必要になります。 単純に開発メンバーだけに閉じていれば簡単ですが、実際にはお客様からの問い合わせ起点で、過去のデータを確認したいケースもあるため、そんなに簡単ではありません。今回は、実際にお客様対応をしているメンバーに確認して、「（過去の対応履歴から）1ヶ月あれば十分」と判断できました。 実際の移行 ストックマークではクラウドインフラの管理に、 terraform を活用しており、変更は非常に簡単です。公式ドキュメントにあるように、 “storage_class” に “GLACIER” を設定し、必要な日数 “days” に数値を設定すればOKです。 なお、移行時には verisoning にも留意ください。（設定されていないと期待どおりに動かないことがあります） 今後に向けて コストの最適化は、ワンショットで終わるものではなく、継続的にふりかえりしながら進めていくのが効果的であると考えています。実際に、プロダクトの作りとしてキャッシュをさらに上手く活用して AWS lambda の実行回数を減らすといった改善の余地も見えています。 現時点で、もっとも ROI の高い活動を見極めた上で、各チームがコストに責任を持って自律的に最適化していきたいと考えています。 1https://tech.stockmark.co.jp/blog/datastore_migration/Fri, 17 Feb 2023 08:00:00 +0900https://tech.stockmark.co.jp/blog/datastore_migration/本記事では、ストックマークで2022年の12月に実施した、6千万件を超える記事レコードの大規模データ基盤マイグレーションについて紹介いたします。本記事を読むことで、大規模データマイグレーションの勘所を実例から学べます。 本記事でお伝えする内容は以下の4点となっています 背景 検討の進め方 大変だったこと 再現可能な知見 背景 ストックマークでは大量の記事データを利用するプロダクトとして、AnewsとAstrategyの2つのプロダクトがあります。どちらのプロダクトも共通の記事データストアにある内容に、プロダクトごとの弊社独自の自然言語処理を加えたものを活用しています。アーキテクチャを簡単に表すと次のようになっています。 移行前のアーキテクチャ AnewsとAstrategyでは解決する顧客課題が異なります。それぞれのプロダクト観点ごとに、顧客価値のディスカバリーを最優先としたことから、お互いのプロダクトで独自に進化してきた結果、本構成になっています。 もちろん、当時の時点でプロダクト開発に着手する最初の段階から将来を見据えて基盤を共通化する、という考え方も存在します。しかし、そもそも共通化の必要性が明らかでない状態で着手しても、無駄に機能を作りこんでしまう可能性が高いため、スタートアップとしては不適と判断しています。 やがて事業そのものが進化するにつれて、2つのプロダクト価値の接続の重要性が高まってきました。今後も両プロダクトが大きく成長していくことを考えると、このタイミングでのデータストアのマイグレーションへの着手を判断して実行したのが3ヶ月ほど前です。 検討の進め方と移行後の方式 マイグレーションを進めるにあたり、重要な観点を2つ定めました。 弊社の強みであるデータと自然言語処理技術が進化し続けられるデータ基盤となること 各プロダクトの開発のアジリティを落とさないこと 今できていることからデグレが起きないこと 上記を満たすように、移行方式を数パターン考えて、移行コスト、移行後の運用性・拡張性などの観点から、最終的に以下のアーキテクチャとしました。 移行後のアーキテクチャ 本アーキテクチャでは、記事マスタを元に、AnewsとAstrategyが参照するデータ基盤を別々に構築しています。ただし、データ基盤を構築するまでのパイプラインを共通化することで、2プロダクト間のデータ整合性を保ちます。 この共通バッチ処理は、Astrategyのパイプラインをベースに作成しました。スクラッチで作成する案もありますが、活用できる既存資産はできる限り利用して移行コストを抑えています。 大変だったこと Anewsはサービス開始から5年以上が経過しています。5年以上もデータがたまっていると、プロダクションの実データで試さないとわからないことがあった点が、最も大変だったことです。 以前の記事でもご紹介しましたが、ストックマークではAWS Lambda x Node.js を利用して、記事データを日々蓄積しています。収集した記事データに処理を加えてプロダクトごとのマスターデータストアを作成しています。 今回は移行では、そのプロダクトごとのマスターデータストアを再構築します。再構築の対象記事データは6000万記事レコードを超えており、再構築にはおよそ4-5日かかることがわかっていました。 そのため、仮に再構築に何度も失敗してしまうと、4-5日 x 失敗回数の時間がかかってしまいます。そこで、一定の机上検討をして、なるべく精度の高い方式で移行に取り組みました。 しかし、どれだけ机上検討を加えても、プロダクトションのデータでなければ分からないこともあります。過去に行われた、何らかの緊急対応によるデータ改変や、暫定的な最適化処理が想定外の問題を引き起こすことがあり、これらはデータ移行後のテストで多く発見しました。可能な限りデータパッチで凌ぎましたが、復旧が困難な状況に陥り全件の再構築を行い、2度目のトライで移行に成功しています。 再現可能な知見 2点あります。 1つ目は、前述のように1度は移行をやり直したものの、机上検討の時間を一定にして実際に試行した方法です。 ミッションクリティカルなシステムで、ミスが取り返しのつかない影響を引き起こす場合は別ですが、今回のように既存系が動いている場合は、プロダクションデータを利用して試行を織り込んだ計画にするのが良いと考えています。 もう1つは、開発チームの意識統一です。移行に伴う開発時間を最小化するために、重要な点をチームでウォークスルーして認識をすり合わせしていきました。全体方針などはドキュメントに起こしてあるため、それを読むことで一定の理解は得られますが、理解度には差が出ます。そこで、重要な箇所に絞ってチームでドキュメントの項目を1つずつ確認する時間をとりました。 まとめ 本記事では、ストックマークで実施した大規模データ基盤移行の概要を紹介しました。 本記事で取り扱っていない細かい工夫や技術詳細は多々あるので、もしご興味あれば是非カジュアル面談でお話させてください。 また、本記事をより詳細に扱うイベントとして、Stockmark Tech Meetup #06 - スタートアップの成長フェーズに応じたデータストアのリファクタリングのタイミングと方法を、2023/03/08(水) 19:30より開催いたします。本記事に興味をもっていただけましたら、こちらも是非ご参加ください！https://tech.stockmark.co.jp/blog/bart-japanese-base-news/Tue, 24 Jan 2023 11:00:00 +0900https://tech.stockmark.co.jp/blog/bart-japanese-base-news/はじめに Research部門の江間見です。ストックマークでは、自然言語処理技術の研究開発を行っています。 弊社では、大量のビジネスニュースを解析対象としていますが、人間がすべてのビジネスニュースを精読することは不可能です。そのため、読むべき記事を判断するために、記事分類や要約等を行うことが必要不可欠となります。 近年では、この要約タスクの分野では、高い精度が報告されている事前学習済モデルBART等が存在します。 そこで、弊社で日本語向けのBART事前学習済モデルを作成しましたので、今回はそのモデルの紹介と公開を行います。 BART とは BART は、2019 年 10 月 29 日に Facebook社によって提案されました。 BART は、双方向エンコーダー (例えばBERT) と左から右へのデコーダー (例えばGPT) を使った seq2seq 構造を使用します。BART は、基本的にテキスト生成用のモデルですが、テキスト理解タスクにも適しています。そのため、さまざまな抽象的な対話、質問応答および要約などのタスクでよく使われます。 Stockmark の BART BART の事前学習済モデルは Hugging Face で公開されていますが、日本語かつビジネスニュースに特化したモデルはありません。そのため、弊社では日本語ビジネスニュースコーパスを学習したBART事前学習済モデルを作成しました。 今回、Hugging Face にてこのBART事前学習済モデルを公開します。BART事前学習済モデルの詳細な利用方法は以下のリンク先をご覧ください。 https://huggingface.co/stockmark/bart-base-japanese-news ここからは、弊社のBART事前学習済モデルを簡単に紹介します。 事前学習 事前学習では、オリジナル文章の文の順序をシャッフルし、テキストのトークンをランダムにマスクトークンに置き換えた文章をオリジナル文章に復元するタスクを学習します。 今回は、約3年間半分（2019-01-01~2022-07-12）の約2100万のニュース記事（約2.9億文）を事前学習データに使い、BART-baseサイズのモデルを事前学習しました。 事前学習の期間は、Google TPU v2-8（64 GiBメモリ）で約45日間です。 事前学習済モデルの出力 事前学習で、文順入れ替えタスクとマスク穴埋めタスクを学習しましたので、事前学習結果の主力例を以下に示します。 文順入れ替えタスク 文順入れ替えタスクでは、以下のような文章があった場合、文の順番をシャッフルし、元の文順に戻します。 # オリジナルテキスト(正しい文順) 明日は大雨です。電車は止まる可能性があります。ですから、自宅から働きます。 文順入れ替えタスクを学習しているか確認するために、以下のように文の順番をシャッフルした6パターンを事前学習済モデルに入力します。 入力: # パターン1(このパターンはオリジナルテキストと同じです) 明日は大雨です。電車は止まる可能性があります。ですから、自宅から働きます。 # パターン2 明日は大雨です。ですから、自宅から働きます。電車は止まる可能性があります。 # パターン3 電車は止まる可能性があります。明日は大雨です。ですから、自宅から働きます。 # パターン4 電車は止まる可能性があります。ですから、自宅から働きます。明日は大雨です。 # パターン5 ですから、自宅から働きます。電車は止まる可能性があります。明日は大雨です。 # パターン6 ですから、自宅から働きます。明日は大雨です。電車は止まる可能性があります。 出力:https://tech.stockmark.co.jp/blog/2022_trend_words/Mon, 12 Dec 2022 01:00:00 +0900https://tech.stockmark.co.jp/blog/2022_trend_words/本記事は、Stockmark Advent Calendar 2022 の 12 日目の記事です。 年の瀬といえば流行語大賞ですね。今年 2022 年も 大谷ルール や オミクロン株 などいろいろな流行語が世間を賑わせました。 弊社サービス Anews もこの1年を通して様々なニュースをお客様に届けてまいりました。 振り返ると、コロナウイルスやロシア・ウクライナ危機、サステイナビリティに対する関心の高まり、原材料の高騰問題などお客様のビジネスに大きな影響を与えるニュースがたくさんありました。 そこで今回は弊社サービス Anews でこの1年で配信されたニュース記事に対してキーフレーズ抽出を行い、2022年のトレンドを振り返ってみたいと思います。 またこの記事の後半ではキーフレーズを抽出するロジックについても解説します。 Anews について ストックマークはAI 情報収集プラットフォーム Anews を運営しています。 Anews は国内外約 35,000 サイトからニュースを収集し、ビジネス活動を行うお客様に毎日配信するサービスです。 Anews の人気機能の1つに 業界ニュース があります。 業界ニュースは Anews で配信しているニュースから各業界に関するニュースをピックアップして届ける機能です。 今回はこの業界ニュースで採用している各業界区分からキーフレーズを抽出したいと思います。 業界別2022年のキーフレーズ まず各業界のキーフレーズトップトップ5をご紹介します！キーフレーズの抽出方法およびランキング方法はこの記事の後半で説明します。 業界 キーフレーズトップ5 輸送機械 自動運転, 電気自動車, ガソリン車, CO2, 車中泊 半導体・電子機器 充電器, 5G, 太陽電池, イオン電池, 探索機 総合電機 5G, 清浄機, 顔認証, 再エネ, 非接触 金属 太陽電池, リチウムイオン電池, 全固体電池, 脱炭素, 車載型 化学 CO2, 生分解, プラごみ, 環境配慮, 脱炭素 医療・製薬 検査キット, 抗原検査, PCR検査, 遺伝子検査, 不妊治療 IT 暗号資産, クラウド, 仮想通貨, 5G, 脆弱性 食品 代替肉, 食品ロス, 陸上養殖, 生分解, 国産大豆 エネルギー 太陽光発電, 洋上風力, バイオマス, 再エネ, 燃料電池 銀行・金融 暗号資産, 仮想通貨, キャッシュレス, 取引所, ビットコイン 保険 自動運転, 電気自動車, シェアサイクル, 高齢者, 認知症 抽出したキーフレーズから、複数業界にまたがったトレンドがいくつか見えてきました。https://tech.stockmark.co.jp/blog/definition_sentence/Fri, 02 Dec 2022 11:00:00 +0900https://tech.stockmark.co.jp/blog/definition_sentence/はじめに こんにちは、Researcherの北山です。今回は自然言語処理技術を用いてAstrategyにおける顧客体験向上のための取り組みを行ったので、その内容を共有したいと思います。 本内容は弊社のTech Meetup #04でも発表した内容になりますので、ご興味のある方はそちらもご覧いただけますと幸いです。 自然言語処理とは 自然言語処理とは、我々が日常のコミュニケーションで用いている言語（自然言語）を機械で処理する技術のことです。情報系の分野では単に言語というとプログラミング言語を連想する方も多いため、それと区別するために自然言語という用語が使われています。自然言語処理が活用されている事例としては、例えば以下のようなものがあります。 弊社では、そういった自然言語処理を活用し、ニュース記事内の情報を構造化することによって顧客体験の向上に取り組んでいます。例えば、以下の例ではニュース記事から主題企業とその取り組み、またそれがどのフェーズにあるのかといった情報を抽出して構造化しています。こうした情報を蓄積して構造化しておくことで、その後の分析や情報提供に活用することができます。 出典[1] 構造化事例: 定義文抽出 今回は構造化の一つとして、定義文抽出に取り組みました。ここでは、以下の図に示すようにニュース記事から単語の定義を説明している文（定義文）を抽出しています。 出典[2][3][4] 定義文のニーズ そもそも、なぜ定義文が必要になるのでしょうか？これまで、Astrategyを利用していただいているお客様がトレンドなどに分からない単語が出てきた際に、外部サービス（Google検索など）で調べなければならなかったり個別のニュース記事を見にいって中身を確認しなければいけなかったという課題がありました。定義文抽出によって予め用意された定義文をAstrategy内で提示することができれば、そういった課題を解決することができます。 出典[2] 定義文抽出の流れ ここからは、実際の定義文抽出の流れについて説明します。以下の図のように、ニュース記事を定義文判定器と主語抽出器の2種類によって処理した後、抽出された定義文をデータベースに保存することによって構造化が行われます。そうして保存されたデータベースにアクセスすることによって、必要な時に定義文の情報を利用することができます。 2つの処理器についてもう少し詳しく解説すると、まず、定義文判定器ではニュース記事内の文章1つ1つを定義文であるか否かの2値に分類しています。こちらは、BERTという機械学習モデルを使用しています。BERTは大量のデータにより学習された大規模事前学習済みモデルであり、追加で用意したデータでfine-tuningすることにより様々なタスクを解くことのできる汎用モデルでもあります。今回は、社内で作成した定義文用のデータを用いて判別器を作成しました。 出典[2] また、主語抽出器では定義文判定器によって定義文と判定された文に対して、主語部分を特定し抽出しています。こちらは、形態素解析という技術を用いています。形態素解析とは、文を単語単位に分割しそれぞれの単語に対して品詞情報などを付与することのできる技術です。その情報を用いて「複合名詞＋は/とは」が出現する箇所を文中から検出し、複合名詞部分だけを抜き出すようなアルゴリズムによって主語抽出器を作成しました。 出典[2][3][4] 抽出結果 以下は定義文抽出によって獲得することのできた定義文の一例です。メタバースやNFTのような近年流行りの単語だけではなく、バスクチーズケーキやぴえん〇〇のようなマイナーそうなものまで幅広く抽出することができました。表示順は、検索している単語が文の主語と完全一致しているものを優先して表示しており、その中でも文の長さが長いものが上に来るようになっています。今後の製品上でのリリースに当たっては、お客様のニーズに合わせて優先して表示するべきメディアのソースなど、並べ替えに使用する情報を選定していく必要があります。 出典[5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24] 今後の展望 現在、抽出した定義文をAstrategy上のサービスに表示できるように開発を進めております。また、定義文の情報を活かした別の取り組み（文章要約やトレンド分析など）を進めることによって、新たな価値提供ができるのではないかと考えております。 記事の出典 [1] https://thebridge.jp/tag/astrategy [2] https://and-engineer.com/articles/YuORlxAAACAAKnUa [3] https://www.zenchin.com/news/content-11.php [4] https://prtimes.jp/main/html/rd/p/000003991.000003442.html [6] https://diamond.jp/articles/-/295882 [7] https://finance.yahoo.co.jp/news/detail/20220511-00935059-fisf-stocks [8] https://panora.tokyo/archives/43200 [9] https://prtimes.jp/main/html/rd/p/000000017.000060077.html [10] https://prtimes.jp/main/html/rd/p/000000023.000081780.html [11] https://prtimes.jp/main/html/rd/p/000000054.000025762.html [12] https://prtimes.jp/main/html/rd/p/000002374.000003670.html [13] https://japan.cnet.com/release/30613322/?ref=rss [14] https://www.weeklybcn.com/journal/explanation/detail/20220517_191017.html [15] https://prtimes.jp/main/html/rd/p/000000191.000015685.html [16] https://gigazine.net/news/20190801-pablo-basque-minipassion/ [17] https://news.yahoo.co.jp/articles/09e31317d0c351bf6d9079b1bc89fdcad95c8a58 [18] https://hayarimon.jp/seven-eleven-mont-blanc-wafu-parfait-basque-cheese-cake-8413/ [19] https://more.hpplus.jp/odekake/gourmet/50813 [20] https://www.atpress.ne.jp/news/240984 [21] https://www.rbbtoday.com/release/dreamnews/20210222/584199.html [22] https://www.dreamnews.jp/press/0000232289/https://tech.stockmark.co.jp/blog/some_tips_for_software_development/Thu, 01 Dec 2022 08:00:00 +0900https://tech.stockmark.co.jp/blog/some_tips_for_software_development/ストックマーク Co-VPoE の岩瀬です。本記事はストックマーク アドベントカレンダー 2022の初日記事です。 ストックマークの開発チームは高速にかつ堅実に価値を生み出しています。その内部で何を意識しているのか、何を工夫しているのか、本記事でその一端をお届けします。効果的な開発プロセスを追求するエンジニアや、テックリード、エンジニアリングマネージャに少しでも参考になることを狙っています。（なお、概要＋一部の公開ですので、全体像やより突っ込んだ詳細については、本記事最下部にあるカジュアル面談までお願いします！） 本記事で紹介するトピックは以下の6つです。 スキーマ駆動によるコミュニケーションの最適化 Over Fetching を生み出さないAPI設計 価値のベースラインを保つリグレッションテスト 継続的なライブラリバージョンのメンテナンス CIは命綱 「推測するな、計測せよ」によるユーザー体験の向上 それでは早速いってみましょう！ スキーマ駆動による開発効率化 ストックマークのエンジニアは、フロントエンドであればバックエンドであれ、gRPCのスキーマを触れるようになっていきます。これによってメンバー間のコミュニケーションコストを最小化しており、円滑に開発が進められるようになっています。 もう少し具体的に内部を紹介すると、PRDを作ったメンバー※や、PRDのメイン検討・実装を担うことになったメンバーがprotoファイルを先に作って、Pull Requestを出すようにしています。 ※ ストックマークでは、エンジニアであってもPRDを書くことがあります。[記事1][記事2] Over Fetching を生み出さないAPI設計 ストックマークのプロダクトは大量の情報を扱うものが多いため、API設計を雑にしてしまうと、Over Fetchingが発生する可能性があります。Over Fetchingすると、必要以上のデータをやりとりすることがあるため、速度の低下を招くためユーザ体験が悪化してしまいます。 そこで、内部のAPI設計として、画面ごとに最適化して必要十分なAPIとなるようにしています。この場合、画面ごとに一部重複してしまう可能性がありますが、実装として共通部分を共通のmessageとして括りだして使うなど、保守性を高めています。 価値のベースラインを保つリグレッションテスト プロダクト開発というのは、常に新しい価値を生み出し続けるものではありません。新しい価値を生み出しながらも、狩野モデルで挙げられる当たり前品質・一元的品質をキープする必要があります。 ストックマークのプロダクトにおいても、常に品質を保ち続けたい機能がいくつかあります。たとえば、検索精度や検索キーワードの自動補完がその機能に該当します。検索機能を例にとると、ストックマークのプロダクトのユースケースでは、検索が利用される機会が多くあります。そのため、検索精度が悪化してしまうと、ユーザー体験が著しく悪化してしまうのです。 そこで、内部のアルゴリズムに手を加えた場合であっても、体験が悪化していないことを担保するために、リグレッションテストを継続的に実施しています。自動化している部分も多くありますが、人間の価値判断が必要な部分については、人の目も活用しています。 本セクションの例として取り上げているような「良い検索精度、ユーザーに高い価値をもたらす検索精度ってなんだろう？」というテーマは、人の目を活用する一例です。もちろん、再現率と適合率を考慮したF値を見るような手法や、ランク指標を測るMRR（Mean Reciprocal Rank）などもありますが、現時点ではいちばん顧客アウトカムに寄与するものとしてマニュアル対応をしています。 継続的なライブラリバージョンのメンテナンス 皆様は過去に、開発・運用しているプロダクトで利用しているライブラリのバージョンがかなり古くなってしまった、という経験はありませんか？バージョンの差分が開けば開くほど、バージョンの最新化は困難になりがちです。 ストックマークではライブラリバージョンが古くならないよう、開発プロセスに組み込んで対応しています。具体的には、開発の週次ミーティングの中でdependbotによる通知をレビューしています。 CIは命綱 開発を続けていると、特定の環境要因（たとえばCircle CI）でCIが意図通りに動作しないことがあります。たとえば、CircleCI の Executor 環境とローカル環境の違いやバイナリのコンパイルオプションの違いなどが要因となって、Python のsetuptools がインストールされずにテストが落ちるといった現象などです。 このような場合の対応策としては、その部分はカットしてしまったり、別のワークアラウンドを試したり、と様々な案があります。ストックマークでは、レアな事象が起きたとしても、過去に様々な事象を踏み抜いてきたエンジニアが在籍しており、CIが正常に動き続けるようにメンテナンスをしています。 実際に内部のエンジニアの発言から「CIは命綱。動いていなくても、少しならいいかもしれないけど、命綱がない状態で開発をしていたらぼくは怖い。」という力強い発言もありました。 「推測するな、計測せよ」によるユーザー体験の向上 ストックマークの開発チームは、プロダクトの内部でかかっている処理・IO時間を、Datadogを利用して可視化しています。可視化されたデータから、特にユーザー体験につながる部分を集中して改善しています。言い換えれば、場当たり的に予測して改善を繰り返すのではなく、データドリブンで開発プロセスを進めているということです。 わかりやすい仮の例を使うとすれば、バックエンドで1秒かかる処理を70%高速化するよりも、10秒かかるようなネットワークIOを10%高速化（IOの量を減らしたり、回数を減らしたり）したほうがユーザー体験につながるのです。 格言である「推測するな、計測せよ」を地で行く開発プロセスを進めています。 まとめ 本記事では、ストックマークの開発プロセスで意識していることや、工夫していることの一部を紹介しました。他にも、テスト時におけるモック注入や、環境ごとに適した依存性注入を実現するためのDI (Dependency Injection) 利用など、たくさんご紹介したい内容があります。 本記事では紹介しきれない詳細や他の課題について、詳しく知りたい場合はぜひお話しましょう！ また、本記事はストックマーク アドベントカレンダー 2022の初日記事でした。本日含め明日からも25日間、ストックマークの記事が続きますので、ぜひお楽しみに！https://tech.stockmark.co.jp/blog/knowhow_lambda_and_nodejs/Wed, 19 Oct 2022 08:45:00 +0900https://tech.stockmark.co.jp/blog/knowhow_lambda_and_nodejs/はじめに Stockmark のプロダクトでは、各メディアから記事を収集するために AWS Lambda (実行環境はNode.js) を大量に利用しています。「大量」とは実際にはどの程度なのかを紹介すると、月間で 1.6億 秒ほど(1日で約60日分) 使用しています。もしかしたら「えっ、なんでそんなに使っているの？」と思われているかもしれません。 本記事ではその疑問に回答しつつ、実運用から得られた知見を一部共有していきます。段階的に理解いただけるように、技術選定理由から説明していきます。 なぜ Node.js なのか？ なぜ AWS Lambdaなのか？ Lambda x Node.js でスクレイピングする際の落とし穴 ということで、早速1つ目からいってみましょう！ なぜ Node.js なのか? ストックマークのプロダクトでは、Web記事などを中心としてスクレイピングして収集した情報をベースにコンテンツが提供されています。Webページから必要な情報を抽出するためには、クライアント側（ブラウザ側）でレンダリングされた後の情報が必要になります。現代のWebページは、Client Side Renderingされることが多いため、単に curl して得られた情報のみでは、必要な情報が不足してしまいます。 そのため、JavaScriptを実行して、HTMLが構築されたあとのDOMから必要な情報を抽出する必要があります。具体的には、Puppeteerを用いてHeadless Chromeでページのナビゲーションを制御したり、JSDOMでDOMの操作を行なったりしています。以前はPythonで処理を記述していましたが、HTMLやJavaScriptの制御のしやすさ、ブラウザのAPIとの親和性などから、Node.jsを選定してそちらへ移行しています。 なぜ AWS Lambdaなのか？ Node.jsやPuppeteerを活用している背景は、ここまででお分かりいただけたかと思いますので、次に利用しているインフラストラクチャについて説明します。 前述した Puppeteer はAWS Lambda上で動かしています。最初期のスクレイピングにはLambdaではなくEC2を利用していましたが、次のシンプルな要件を満たすのが困難になってきました。 👉 要件：1時間で1万記事をスクレイプできること Stockmarkは毎朝、ユーザーごとに最適化された記事を配信しています。その記事のソースとなり得る記事を短時間に、かつ攻撃にならないように収集する必要があります。そこで、水平方向にスケールして、要件を満たせる実装として、2018年からAWS Lambdaを利用するようになりました。 しかしLambdaのおかげで万事解決したかというと、そういうわけでもありません。プロダクションサービスを提供するにあたり、実装上の落とし穴がたくさんあるのです。 Lambda x Node.js でスクレイピングする際の落とし穴 落とし穴 その1: Puppeteer がクラッシュする Lambdaは関数単位で動作しており、関数間でステートが完全分離されていると考えている方も多いでしょう。しかし、実運用ではそのように動作してくれません。 実際にはLambdaを大量に動かしていると、VMにアタッチされたストレージにキャッシュが溜まり、容量が足りなくなってPuppeteerの処理が失敗するようになります。これは外部動作の振る舞いを観察して分かったことです。 そこで、内部の実装としてキャッシュによりストレージが枯渇しないように、キャッシュをpurgeする処理を入れています。現在はこれで正常に動作しています。 落とし穴 その2: Lambdaが最大並列実行数に到達しない スクレイピングシステムは、Lambda → SQS → Lambda → SQS → ….というようなマイクロサービス構成になっています。大量のサイトをクローリングするためにはLambdaが並列に実行される必要があり、Lambdaにはあらかじめ最大並列実行数を予約しておく機能があります。しかし、実際にはSQSをトリガーにすると、Lambdaが最大並列実行数に到達しないことがあります。 最大並列実行数に実並列実行数が到達しないと観測してわかった場合には、同じLambda関数をIaCで複数個定義、作成することで、必要な並列実行数を担保するなどの工夫をしています。 落とし穴 その3: 巨大なXMLの存在 一部のサイトでは、XMLを利用して情報を配信しています。小さくシンプルなXMLであれば特に問題ないのですが、実際にはかなり大きなXMLが存在しています。具体的には、50MBを超えるXMLを複数圧縮して配信しているサイトがあるため、ダウンロード自体は問題なくても、parseにかなり時間がかかり、ものによってはタイムアウトで処理が失敗してしまいます。https://tech.stockmark.co.jp/blog/press_release_driven_development/Mon, 29 Aug 2022 09:00:00 +0900https://tech.stockmark.co.jp/blog/press_release_driven_development/ストックマークではプロダクト開発の方法として、プレスリリース駆動開発を採用しています。このアプローチは Amazon で Working Backwards と呼ばれる方法に類似した方法です。本記事では、実際にプレスリリース駆動開発を実施すると何が起こるのか？という点について紹介します。今後、プロダクト開発においてプレスリリース駆動開発を採用してみようかな？という方には、有益な情報になると思います。 先に実物を紹介 本記事でベースとしているプレスリリースは Astrategy というプロダクトの新機能になります。 実際のプレスリリース 詳細は実物をご覧いただければと思いますが、内容草案はまさにプロダクトのPRD(Product Requirements Document)や、実装が進む前からプロダクトオーナーが書いていたものです。 では、詳細検討が進む前にプレスリリース案を作成すると、社内では何が起こるのでしょうか？ プレスリリース駆動開発を起因とした3つの変化 社内で起きた変化のうち、ここでは3つを取り上げます。 顧客のアトラクト強化 プロダクトオーナー自身の気づきによる新機能の洗練化 より効果的な画像が作成できるように 以下でそれぞれを説明していきます。 1. 顧客のアトラクト強化 ビジネスサイドからすると、プレスリリースの内容を先に見ておくと、具体的に機能のイメージをつかみやすくなります。もちろん、ロードマップの内容から、この先に出てくる機能を理解することも可能ですが、プレスリリースは顧客向けの表現になっていることから、より解像度高く自社プロダクトを理解できるようになります。 その結果、顧客とのタッチポイントがあった際に、「この課題を解決するために、こういう機能を作っているんです。こんなイメージです。…」と具体的に説明できるようになります。顧客へより魅力的な説明が可能となるわけです。 2. プロダクトオーナー自身の気づきによる新機能の洗練化 プロダクトに新機能を追加する場合、当然のことながら具体的な顧客を意識して、何らかの課題を解決しにいきます。ただ、プロダクトオーナーは顧客インタビューや指標確認など様々な業務を並行していることが多く、頭の中のメモリをフルに活用していることが多く、ふとした瞬間に検討の抜け漏れが発生することがあります。 プレスリリースはこの抜け漏れを気づかせてくれる強力な武器になります。プレスリリース執筆時は、「顧客は誰か？どんな具体的なペインを抱えているのか？コアな価値は何か？」と、ある機能に集中することになります。さらに論理的な文章に起こす必要があるため、これまで考えていた内容の穴に気づきやすくなるのです。 結果的に、より機能を洗練してから作れるようになります。ソフトウェアテストにおけるShift Leftと同じように、できるだけ早い段階で仮説を洗練化できれば、的はずれな開発をする可能性を低くできます。 3. より効果的な画像が作成できるように プレスリリースはURLでシェアされることが多いため、文章だけでなくOGP向けに画像が作られるのが普通です。ストックマークのプレスリリース向け画像作成は、社内のデザイナーが通常実施しているのですが、新機能や改善を打ち出すペースが速いことから、スケジュールがタイトになりがちです。 しかし、プレスリリースを事前に作成していると、初期段階からデザイナーも開発工程に参画しやすくなります。機能の理解が高まり、かつスケジュールにゆとりも生まれるので、顧客にとってより効果的な画像を作成できるようになるのです。 まとめ 本記事では、ストックマークで採用しているプレスリリース駆動開発で起きた社内の3つの変化を紹介しました。「実際にどういうスケジュールで？どういうプロセスで進んでいるの？」などさらに詳細を知りたい方は、是非カジュアルにお話しましょう！https://tech.stockmark.co.jp/blog/branching_strategy/Wed, 22 Jun 2022 11:00:00 +0900https://tech.stockmark.co.jp/blog/branching_strategy/概要 組織の拡大に伴う開発チームの分割、独立性向上のためにGitHubの運用フロー見直しと同時にFeature Flagの導入を行いました。 結果として、独立した開発をしてもコンフリクトが発生しづらくなったことにより生産性が向上、副次的効果として部分リリースにより問題の先行発見をしやすくなり、品質向上にもつながりました。 背景：GitHubのブランチ戦略がチームスケールの弊害に プロダクトや会社の成長に伴い、開発チームにはスピードと安定性の両面が求められるようになっていきますが、少人数のメンバーだと限界がやってきます。実際に、小さな改善はできるけど、ソフトウェアアーキテクチャ自体を見直すような大きな改善施策は、新規開発もある中で中々優先度を上げられないような状態が起きていました。 このような状況下で、開発組織としては総スループットを向上させる必要がありますが、単純に同じプロダクトの開発人数を増やしていくと、調整コストの増大、コンフリクトの発生などにより生産性が思うように上がりません。Anews開発チームでは３人の小さなチームに分割して独立性を高め調整コストを下げる方針をとりましたが、時に大きなコンフリクが発生してしまい、これを防ごうとすると調整コストが発生する状況にあり、両立が課題になっていました。 変更前の運用：コンフリクトと調整コストのトレードオフ 運用方法 開発項目毎にmasterからfeatureブランチを派生する １開発が大きい場合、サブタスク用のブランチをfeatureブランチから派生する（図中feature/greenの例） 開発項目毎に、サブタスク全てが完了してからdevelopment環境にリリースし受け入れレビューを行う リリースは毎週実施しており、火曜日に受け入れレビューが完了している全てのfeatureブランチをreleaseブランチにマージし、staging環境にリリースしてテスト 木曜日にstagingブランチをmasterブランチにマージし、production環境にリリース 発生していた課題 規模の大きな開発の場合、コード変更がベースブランチであるmasterにマージされるまでの期間／規模が大きくなり、大きなコンフリクトが発生するリスクが高い（図中feature/greenとfeature/redをrelease/2にマージするタイミング） しかも、開発をしてからコンフリク解消作業の間に期間が空くため、既に他の開発に着手していることがほとんどで、割り込みによるスイッチングコストが馬鹿にならない 人数が少ない間は、同じ箇所の開発をなるべく同時にしないようにしたり、必要な場合は設計の示し合わせをしてからそれぞれ開発を進めることでコンフリクトをなるべく防いでいた（これが調整コスト） 開発項目毎にdeveloppment環境を占有して受け入れレビューを実施するため、開発並列度が高まると環境待ちが発生し、解消しようとdevelopment環境を複数作るとインフラコストと管理コストが増大する 変更後の運用：ブランチ戦略見直しとFeature Flagの導入 運用方法 サブタスク含め全てのブランチをdevelopmentから派生する 単体開発が終わり次第developmentブランチにマージする developmentブランチの内容は常にdevelopment環境に自動リリースする 開発項目毎に、サブタスクが全て完了してからdevelopment環境で受け入れレビューを行う 火曜日にdevelopmentブランチをstagingブランチにマージし、staging環境にリリースしてテスト 木曜日にstagingブランチをmasterブランチにマージし、production環境にリリース 改善ポイント 全てのブランチの派生元をdevelopmentにし、サブタスク単位で完了次第developmentにマージすることで、ベースブランチであるdevelopmentと開発ブランチ（feature）間の差分の期間／規模を小さくし、コンフリクトリスクを小さくできる 図のfeature/greenとfeature/redの例では、変更前の運用ではrelease/2へのマージのタイミングでコンフリクト発生するリスクがありますが、変更後の運用ではfeature/redに着手する前にfeature/greenの変更がdevelopmentにマージされているため、コンフリクトが起きることはない 同時に、全ての開発内容がdevelopmentにマージされdevelopment環境にリリースされているため、１環境で同時に受け入れレビューを実施できる Feature Flagの導入 変更後の運用はこのままでは大きな問題が１つ残っています。 １つの開発項目を複数のサブタスクに分割する場合、全てのサブタスクが完了していない状態でもコード自体はマージされているため、何もしなければそのままリリースされてしまいます。全てのサブタスクが完了するまで変更がユーザには見えないようにするために、Feature Flagを導入することでこの問題を解消しました。 具体的には、開発項目ごとのFeature Flagを作成します。Feature Flagがオフの間はstaging／production環境でその機能が表示／実行されないようにしておきます。開発項目内の全てのサブタスクが完了し、受け入れレビューが完了したタイミングでFeature Flagを削除し、staging／production環境で機能が表示／実行されるようにします。これにより、コード自体は最小単位でマージされていくが、機能は開発項目単位でリリースされていく状態を実現しました。 副次的な話になりますが、特にバックエンドのAPIやバッチ処理は部分的に機能を追加してもユーザに影響が無い事が多く、Feature Flagを用いず裏で動いている状態でリリースしてしまうような形をとっています。これにより、先に完成したバッチ処理だけproduction環境にリリースし、そこで問題を発見し、ユーザ影響が出る前に修正を行えた例が実際に起きました。 小さくマージし、小さくリリースすることで、想定外が発生してしまった場合でも問題を小さなうちに解消する事ができ、総合的な品質を高めやすくなったと言えます。 今後に向けて シード時代、動くものを早く作るのが正義の時代から、今では多くのお客様にご利用いただくようになり、安心してご利用いただくための安定性や継続的に改善を続けられる組織のスケール性がより重要になってきています。 一方で、価値を生み続けるためには、素早く試すアジリティとチャレンジしやすい環境も欠かせません。 これらを両立していくために、ソフトウェアのリアーキテクチャ、プロダクト共通データ基盤、MLOps、ABテストなど、今後も変えていきたいことがたくさんあります。 今後の施策や、開発チームについてご興味あれば、ぜひお話しさせてください！https://tech.stockmark.co.jp/blog/stockmark_data_team_evolution/Mon, 13 Jun 2022 08:30:00 +0900https://tech.stockmark.co.jp/blog/stockmark_data_team_evolution/2022/5/25 に Stockmark Tech Meetup #02 を開催しました！本記事では、2つ目のLTである “個別最適でプロダクトを作り続けたスタートアップがデータ専任部隊を作ることにした話” を再編成してお伝えいたします。本記事を読むことで、以下の2点が分かります。 AIスタートアップが膨大なデータに立ち向かってきた歴史 ストックマークが抱える膨大なデータに対して、どのように開発チームがアプローチしているか ストックマークのプロダクトはデータに支えられている まず前提として、ストックマークのプロダクトである Anews と Astrategy はどちらも、国内外で公開されている膨大なデータを利用しています。 AnewsとAstrategyは膨大なデータに支えられている 上図のデータはWebクローラーによって毎日収集され蓄積されています。実装としては、大量のAWS lambdaによる汎用的な収集・抽出処理が内部で動作しています。Webクローラーときくと、「え、データを取ってくるだけでしょ？」と思われるかもしれませんが、そんなに単純ではなく非常に厄介な問題があります。 「何もしてないのに壊れる」のではなく「何もしてないと壊れる」 Webというのは常に動的に変化するものです。Webクローリングを実施する場合、ある程度のHTML構造をベースにデータを抽出していきます。たとえば、このタグのここには必要となる情報が存在している、このタグは不要な情報である、といったように判断しながら情報を収集しているということです。 HTML構造が変化しなければ問題ないのですが、Webは常に進化していきます。したがって、更新に追従し続けなければ、クローリングの失敗数が漸進的に増えてしまうのです。結果として、データに支えられるはずのプロダクトの価値が低下することになります。 Phase0: どちらのプロダクトが対応する？ 歴史的に、Anews と Astrategy の2つのプロダクトはコアな価値探索にフォーカスするため、別にチームで開発されてきました。Webクローラーの開発は、下図のとおりでプロダクト間の隙間に落ちているような状態になっていました。 開発体制 Phase0 Phase1: 役割の一部を明確化 ここで、まず取り組んだのはそれぞれのチームの適任メンバー数人が掛け持ちで分担するスタイルへの変更です。Anews のチームも Astrategy のチームのどちらも、クローラー開発の役割の一部を担うように変更しています。 開発体制: Phase1 もちろん、いきなりクローラーのチームを切り出した方がよいのでは、という考えもあります。しかし、まずは顧客価値創出を優先するためにチームを大きく変更するのではなく、徐々に変化していく方式で進めています。 この結果として、Webクローラーの改善が常時進むようになりました。ストックマークの開発チームでは、この状態を半年間維持してきました。その次のステップでデータチームの切り出しへ着手しています。 Phase2: データチームの切り出しへ 簡単にいえば、「プロダクトとデータはデータベースを介してやりとりする」方式です。 開発体制: Phase2 マイクロサービスアーキテクチャを学んだことがある方が上図をみると、すぐに気づく問題があります。それは共有データベース問題です。これは、開発チームでも認識していますが、次のSTEPへの過渡期として採用しています。 過渡期とはいえ、一定の成果が出ています。たとえば、プロダクトで配信できるWebサイト数が3.2倍・LeanとDevOpsで定義される4つのキーメトリクスの改善が得られています。また実際にお客様からも驚きの声を頂きました。 得られた改善効果 一方でまだまだシステムとして伸びしろが多くあります。ストックマークのプロダクトは構造化データを利用して、お客様に価値提供しています。構造化データは各プロダクトごとに作り込みされており、互いに流用し合うのが困難という課題がありました。 Phase3: データプラットフォームの構築へ これらの課題に対して、現在進行系で進めているのがデータプラットフォームの構築です。あくまで、顧客への価値提供を最優先としているため、安易に今回もチーム自体に大きな変更は加えず、最適な摂理面を探し続けるアプローチを取っています。 開発体制: Phase2からPhase3へ ストックマークの開発チーム・システムは、ここまで述べたように常に最適な体制へ変化しています。 なぜ上手く変化できているのか？ ここまで、ストックマークにおけるデータを取り巻く進化をお伝えしてきました。ここまでは上手く進化できているように考えており、今ふりかえると、そこには大きく2つの理由があったかと考えています。 逆コンウェイ戦略によってチームインタラクションをソフトウェアに寄せたため アジャイルに開発する土台があったため これら2点が組み合わさったことにより、開発パフォーマンスを高め続けられています。 未来へ ここまでご紹介した内容は、2022年6月時点のスナップショットではなく、未来に向けて引き続き最適な開発チーム・システムアーキテクチャへ変化させていく予定です。もし、未来の姿にご興味があれば是非お話しましょう！https://tech.stockmark.co.jp/blog/multilingual-language-models/Mon, 02 May 2022 12:00:00 +0900https://tech.stockmark.co.jp/blog/multilingual-language-models/グローバル化が進む現代において、様々な言語で情報収集を行う必要性がこれまで以上に高まっています。Stockmark ではそうしたお客様の情報収集を支援するために多言語テキストの解析にまつわる研究が行われています。本日はその基礎技術である多言語モデルについて紹介します。 多言語モデル (multilingual language models, crosslingual language models) は複数の言語を扱うことができる言語モデルです1。リソースが十分にない言語での下流タスクにおいて、多言語モデルのパフォーマンスが単言語の言語モデルよりも優れていることが報告されています (Wu and Dredze 2019)。また多言語を1つのモデルで扱えるようになることで、言語ごとに異なるモデルを用意する必要がなくなるという運用上の利点もあります。こうした点から近年では多言語モデルは自然言語処理の研究における1つのホットトピックになっており、Hugging Face 上で mulitiilngual タグがついたモデルは 2022年4月現在 320 を超える盛り上がりを見せています。 一方で日本語のような英語と文法的に大きく異なる言語では多言語モデルの性能が低いことも報告されています (Pires+ 2019)。そこで本記事では英語と日本語に着目し、ニュース記事タイトルのラベル分類を例にとって多言語モデルの性能を検証します。 ニュースタイトル分類タスクでの実験 本記事では日本語のニュース記事のラベル分類を例に取り、次の2つの fine-tuning の方法を比較します。 日本語のニュース記事分類データでのみ fine-tuning を行う 英語のニュース記事分類データで事前に fine-tuning を行ってから日本語データで fine-tuning を行う 両者の違いは、日本語データでの fine-tuning の前に英語データでの fine-tuning を行うかどうかという点にあります。一般に英語のデータは日本語のデータに比べ多く手に入れやすいため、後者でより精度が高くなる場合はモデルの改善を行う上で大きな利点があります。 データセット 本実験では英語の記事ラベルデータセットとして News Article Classification dataset (NAC) (Fabio 2017) を、日本語のデータセットとして Stockmark 社内のデータセット2 (STMK) を使用します。NAC には 162,772 件、STMK には15,099 件の学習インスタンスが含まれています。両データセットで採用しているラベルが異なるため、今回はオリジナルのラベルを次の共通ラベルに変換してモデルを評価しました。 共通ラベル: business, education, entertainment, life, politics, science, travel 英語での fine-tuning の効果 まず、STMK 上で K-shot learning を行った場合の Accuracy を、事前に NAC で fine-tuning を行った場合とそうでない場合とで比較しました。ここで本記事では、各クラスのインスタンスをそれぞれ K 件用いて fine-tuning を行うことを K-shot learning と呼びます (N-way-K-shot 問題)。事前学習済み多言語モデルには mBERT と XLM-RoBERTa の2つを用い、両者に対して NAC で fine-tuning したモデルとそうでないモデルの 2 種類を用意しました (合計 2 * 2 = 4通り)3。図1 は K-shot learning の K を変化させることで Accuracy がどう変化するかを示した図です。K は {0, 1, 3, 5, 10, 20, 30, 50, 100} で実験を行いました。https://tech.stockmark.co.jp/blog/similar_articles_ja/Wed, 27 Apr 2022 12:00:00 +0900https://tech.stockmark.co.jp/blog/similar_articles_ja/本記事は Grouping Similar Articles with Search Engine More-Like-This Queries and Graph Algorithms の翻訳記事です。以前の記事である More Like This Query を活用した類似記事集約 入門 から、より踏み込んだ内容になっています。 はじめに ストックマークでは、毎日数千のメディアから数万件のニュース記事を収集しています。そのときに、異なるメディアから類似した内容の記事がクロールされることもあります。その一方で、これらの内容の重複した記事をそのままユーザに表示してしまうと、ユーザの情報収集体験を損ねてしまう可能性があります。そのため、ストックマークのプロダクトであるAnewsので記事推薦や、Astrategyでの事業活動比較などのニュース分析サービスにおいて、より良いユーザー体験を提供するためには、類似記事を検出して集約するのが重要です。 全く同じ内容の記事を集約するのは比較的簡単です。難しいのは、同じ内容の記事ですが、表現のやや異なる記事も集約する必要がある点です。類似記事の多くは、同じ文章を複製しているのではなく、同じ記事を別の著者が書いたという形になっています。 ストックマークでは、文書の類似性を見つけるために検索エンジンを利用しています。また、類似した記事をグループ化するためにグラフアルゴリズムを利用しています。以降で、詳細は説明していきましょう。 類似性グラフの構築 記事を集約する前に、類似性グラフを最初に構築します。グラフの各ノードは記事を表しており、2つのノードが類似していると判断された場合、2つのノード間にエッジが存在しています。類似性定義のためのメトリックによって、グラフは有向もしくは無向になります。今回の場合は有向グラフになります。 記事が固定次元のベクトルで表現できれば、doc2vec や S-BERT を利用して、ベクトル距離を計算して記事の類似性を計算できます。今回のプロジェクトでは、これとは異なる方法を利用しています。すなわち、記事の類似性取得に全文検索エンジンを利用しています。実際に、全文検索エンジンを利用したアプローチの方が、高精度で柔軟な検索が可能であることがわかりました。 ストックマークでは、ニュース記事のインデクシングに Elasticsearch を活用しています。Elasticsearch は、Apache Lucene の上に構築された全文検索エンジンです。Luceneでの類似性スコアリングはこちらに詳細があります。 インデックスされた各記事に対して、More Like This (以降、MLT) クエリを実行し、その類似記事を取得します。類似度判定には閾値を設定します。Luceneでの類似度スコアは記事の長さによって異なるため、絶対値で閾値を設定するのではなく、0から1の間の相対値でスコアを計算します。MLTクエリの実行で、最初のマッチした記事は、同一記事であるため、スコアは1になります。残りの記事は類似度に応じて相対値でスコアリングされます。 類似度の計算には、記事文書の title と body フィールドを利用しています。検索結果からノイズを減らすために、次のフィルタリングを加えています。 同じメディアからのニュースは無視する 5日以上間隔をあけて発表されたニュースは無視する（あるニュースの記事が5日後に再生されることはレアであるため） 類似記事が取得できたら、類似度グラフの構築が可能になります。もし記事 B が記事 A の類似結果リストにあれば、 A から B へのエッジを書きます。なお、MLTのスコアリングは対称ではないため、 B が A に似ているからといって、 A が B に似ているとは限らない点に注意してください。 グラフの構成要素の抽出 次に、上で作成した類似グラフ上で類似記事を見つけます。そのために、次のステップとして、2つの異なるアルゴリズムを利用しています。グラフの強連結成分およびコミュニティをそれぞれ検出し、それらの成分が交差した部分を類似記事と判定します。 有向グラフは、各頂点のペアの間に少なくとも1本の経路が存在する場合、”強連結している” と言われます。グラフの強連結成分は、そのグラフの極大かつ強連結な部分グラフです。今回のサンプルデータセットでは、図1に示すように、類似性グラフの強連結成分を色分けして確認できます。非常に大きな成分が数個、小さな成分が多数存在します。最も大きな成分は、記事の4%以上を占めます。これは、主に同じフォーマットで書かれた市場レポートの記事が含まれているためです。 図1: 類似性グラフの強連結成分 図2では、強連結成分と、それと交差する3つのコミュニティを表示しています。グラフのコミュニティ検出アルゴリズムは、グラフ内の密に結合された頂点をグループ化します。これは、ストックマークの場合には、強連結成分からノイズとなる記事を取り除くのに有効です。コミュニティ検出には、SCDアルゴリズムを使用しています。SCDアルゴリズムは貪欲なアルゴリズムであり、最初に密に結合しているノードをクラスタリングします。その後、最初のクラスタの精度を高めていきます。詳しくは論文と実装を参照ください。https://tech.stockmark.co.jp/blog/similar_articles/Thu, 14 Apr 2022 19:42:55 +0900https://tech.stockmark.co.jp/blog/similar_articles/Please refer here for a related post in Japanese. Introduction In Stockmark, we collect tens of thousands of news articles from thousands of different media sources every day. Articles with similar content may be crawled from different news media. It is vital to detect and group similar articles in order to provide better user experience by improving our news analytics services, such as Anews recommendations, Astrategy business activity comparisons, etc.https://tech.stockmark.co.jp/blog/more_like_this_opensearch/Mon, 11 Apr 2022 08:00:00 +0900https://tech.stockmark.co.jp/blog/more_like_this_opensearch/はじめに 本記事では、ストックマークのプロダクトの実装で工夫している類似記事集約という技術について紹介します。本技術により、多くのドキュメントを扱う機会がある場合に、お客様に高い価値を提供できるようになります。 ストックマークでは社内のResearchチームと連携して、類似記事集約において実装面での工夫をいくつか積み重ねています。本記事ではまずイントロダクションとして、特にコアとなる OpenSearch の More Like This Query について紹介します。今後公開する別記事では、さらに発展的な類似記事集約の仕組みを紹介予定です。 さて、本記事で扱う主なトピックはこちらです。 類似記事集約がなぜ必要なのか？ 類似記事集約の実装方法とロジック ストックマーク独自の工夫 過去記事を含む再適用 というわけで早速、本題に進みましょう！ 類似記事集約がなぜ必要なのか？ ストックマークのプロダクトは、世の中で大量に生成されるニュース記事を情報源として活用しています。ニュース記事は、各種メディアサイトに掲載されるため、ほとんど同一の内容が同日の記事として載ることがあります。たとえば、次の図では自社のプレスリリースが複数メディアで取り上げられており、全て同一記事であると判定している例です。 Astrategyにおける記事集約イメージ 仮に何の工夫もしないナイーブな状態で、ニュース記事をお客様に見せてしまうと、内容の重複する記事ばかりになってしまいます。そこで、類似の記事はまとめておいて、お客様には1つの記事を返すことでUXを向上できます。 どうやって実装しているのか？ 類似記事集約は、技術的には一種の文書クラスタリングであり、様々な実装方法があります。 ストックマークでは類似記事集約実装のために、Amazon OpenSearch Service (以下、OpenSearch) を利用しています。OpenSearchは、Elasticsearch からフォークされており、Elasticsearchの More Like This Query の機能を活用できます。今回の類似記事集約では、まさにこの機能を実現方法の一部として活用しています。 More Like This Query のロジック そもそも、ある文書Aと文書Bが同一であること(似ていること)をどのように判断すればいいのでしょうか？ OpenSearch Fork元の Elasticsearch の記事にて、tf-idf を活用していると説明があります。本記事ではtf-idfの詳細な説明はしませんが、簡単に言ってしまえば、 ある単語が多く出現している ある単語、文書群の中で、多くの文書に出現するわけではない という特徴を数値化して、積をとった数値になります。tf-idf のスコアが高い単語は、その文書の特徴を示している可能性が高いと解釈できます。 そこで、ある文書の特徴を示すtf-idfスコア上位k個を保持しておき、文書同士でそれらを比較することで類似度を計算できます。（詳細は Lucene の記事 をご覧ください） 類似度が高ければ同一の文書である可能性が高い、というわけです。ストックマークのプロダクトの類似記事集約では、まずこの機能を利用しています。 過去記事への再適用は大変… Stockmarkでは独自のクローラーにより、記事を数年分に渡って収集しています。今回の類似記事集約においては、関連する一連のアルゴリズムを見直しもしているため、過去のデータに遡って適用する必要がありました。 過去記事の件数は数千万件を対象とするため、単にシーケンシャル かつ スケールしない構成で類似記事集約を実施してしまうと、処理に非常に時間がかかっていまします。 そこで、 適用プログラムの並列化 レプリカシャードのスケールアップとスケールアウト More Like This Query のパラメータチューニング を併用して実施しました。 まとめと記事予告(ストックマーク独自の工夫) 本記事では類似記事集約の方法について紹介しました。 ストックマークの類似記事集約は OpenSearch の More Like This Query のみで実現しているわけではありません。こちらを説明すると長くなりますので、独自の工夫については別記事で紹介予定です。https://tech.stockmark.co.jp/blog/denshosen2021/Fri, 18 Mar 2022 12:00:00 +0900https://tech.stockmark.co.jp/blog/denshosen2021/こんにちは、Machine Learning部門の森長です。 昨年(2021年)の9月に開催されました、AWS Dev Day Online Japanのスペシャルプログラム #1：ボケて電笑戦に参加させていただきました。 そこで、本記事では、ボケて電笑戦で作成したお笑いモデルについて紹介いたします。 ボケて電笑戦とは ボケて電笑戦とは、「AIは人を笑わせられるのか？」という問いを解明すべく、アマゾンの奥地へ向かった膨大なボケのデータを学習させて新たな笑いを作り出せるのかを競い合う挑戦です。 今回のボケて電笑戦では、弊社を含め3企業がお笑いモデルを独自に作成して、人を笑わせるべく大喜利対決を行いました。 詳細は、スペシャルプログラム #1：ボケて電笑戦に以下のような記載されていますので、ご覧いただければと思います。 人間の喜怒哀楽に AI は影響を与えることができるのでしょうか。「ボケて電笑戦」はその命題に挑戦した AI 大喜利対決です。 国内最大級のお笑いメディア『ボケて』の約 100 万のお笑いのデータを利用して、人間が考え出したボケを上回る新たな笑いをAI が作り出せるのかを競い合う『ボケて電笑戦』。まさに新時代の笑いをテクノロジーで切り開くかもしれない壮大なチャレンジです。ぜひお見逃しなく！ 上記の本戦の様子は公開されておりませんが、テクニカルセッションが公開されています。 また、2020年に参加企業を含めた紹介記事(2020年当時のお笑いモデルの紹介)が以下にて公開されています。 ボケて電笑戦記事の1つ目 ボケて電笑戦記事の2つ目 ボケて電笑戦記事の3つ目 では、以降からこのボケて電笑戦で弊社が作成したお笑いモデルについて紹介していきます。 お笑いモデルの構築 まず、ボケの教師データとして、お笑いメディア『ボケて』の約100万のお笑いデータ(画像とその画像のボケテキスト)をご提供いただきましたので、教師あり学習でお笑いモデルを構築することにしました。 お笑いモデルの構築の流れはおおまかに分類すると以下の手順になります。基本的にはこの手順を何度も繰り返し、お笑いモデルをブラッシュアップしていきます。 教師データの準備 教師データの前処理 お笑いモデルの構成と学習 生成したボケの後処理 生成したボケの評価 では、最終的なお笑いモデルがどのように作成されたかを上記手順の流れで紹介していきます。なお、最終的なお笑いモデルが完了するまでに、何十個ものお笑いモデルが没になっています。 教師データの準備 まず、教師データとして約100万のお笑いデータを提供いただきましたが、これをそのまま使うわけにはいきません。おもしろいボケや感心するボケ、おもしろくないボケ等多数あります。 まずは、どのようなボケがあり、どのようなボケが評価(人による評価)されているのか等、ボケの特徴を確認します。 詳しくは記載しませんが、以下のような特徴がみられました。 説明口調の長いボケより、短文でインパクトのあるボケのほうが評価される傾向 シュール系よりも、王道のおバカ系ボケが大量に存在 画像を上手に曲解しているパターン多数 そもそも画像がおもしろい 上記を元に高評価となりうるボケを教師データとして抽出しました。 しかし、提供いただいたお笑いデータは参加企業3社に等しく提供されていますので、この教師データを使うだけですと他社さんのボケとの差別化が難しいです。なんとか弊社独自の特徴がだせないか。 そこで、提供いただいたお笑いデータ以外のデータの使用も許可されていましたので、弊社が保有しているビジネスニュースのタイトル及びその画像データを教師データとして、追加してみることにしました。 狙いとしては、ビジネスニュースの無機質?真面目な?データを学習することで、アンバランスなボケを生成できないかです。 この狙いは一部成功しました。なぜ一部なのかということは「モデルの評価」で後述します。 教師データの前処理 教師データの準備ができましたので、次に教師データの前処理です。 前処理の対象となるものは、「画像」と「ボケテキスト」の2種類です。 画像の前処理 提供いただいた画像データ及び弊社が準備した画像データは、画像サイズや表示形式がばらばらです。 人間であれば、画像を見るとどんなサイズの画像でも適切なサイズに拡縮し、画像の表示形式に関わらず網膜からの視覚データとして脳へインプットしています。 お笑いモデルも同様に、お笑いモデルが効率よく学習するためにも、インプットする画像のサイズや表示形式を統一する必要があります。 画像データの前処理も色々ありますが、今回は、画像サイズを統一してRGBのデータとしました。 テキストの前処理 テキストに対しても前処理を行います。 テキストに形態素解析を行い、以下のようにテキストを単語に分割していきます。 今日は良い天気です。 ↓ 今日 は 良い 天気 です 。 分割した単語を集計すると約25,000種類の単語となり、これがお笑いモデルの有する語彙となります。お笑いモデルはこの語彙から単語を選びながら、ボケるようになります。https://tech.stockmark.co.jp/blog/mobile-app-architecture-20211221/Wed, 22 Dec 2021 17:00:00 +0900https://tech.stockmark.co.jp/blog/mobile-app-architecture-20211221/はじめに こんにちは、Anewsのエンジニアリングマネージャーの山崎です。 この記事はストックマークアドベントカレンダーの22日目の記事です。 普段は、エンジニアリングマネージャーとして開発体制や中長期のエンジニア戦略を考えています。 またエンジニアリングマネージャーとは別にエンジニアとしてAnewsのFlutterアプリの開発を行なっています。 Anewsの開発組織では全員がフルスタックエンジニアとして働くことを推奨しており、 開発体制やプロセスについてもフロントエンド、バックエンドなどの領域を意識せず顧客への価値提供を最大化するためエンジニアが必要な開発を行うようにしています。 その中で、モバイルアプリだけは固定されたメンバーで開発を行うような体制になっています。 理由としては、 ・ モバイルアプリの開発経験が少ない ・ モバイルアプリのコードが複雑になっており、学習コストが高くなっている この問題を解決するために未経験者でも開発が行いやすいようにするため、モバイルアプリのアーキテクチャを見直すことにしました。 今回は現在行なっているアーキテクチャ刷新の全体像を紹介できればと思います。 現在の問題点 現在のアーキテクチャ問題点について ・開発ルールがないため個々のエンジニアの裁量で設計が決まっていく ・コード全体で依存関係が整理されておらず処理を追うことが難しい ・コードの結合度が高くコード改修での影響範囲が広くなる この問題を解決するためにレイヤードアーキテクチャを採用し、階層ごとに処理を分割しUI部分についてはAtomic Designのコンポーネント分割を参考に分割することで影響範囲や処理のルールがわかりやすいようにしています。 全体のアーキテクチャの方針 UI, Domain, Infrastructureの３層構造にすることにより、依存関係を整理し影響範囲をわかりやすくしました。 UI：表示処理を行うコンポーネント Domain：UIとは切り離されたビジネスロジックの集合 Infrastructure: 外部リソースとの接続処理の集合 ディレクトリ構成もレイヤーにより分割することにより、ディレクトリ内に含まれているコードの予想ができ探しているコードを見つけやすい状態にしています。 Domain, Infrastructureの方針 DomainとInfrastructureではAPIやSharedPreferenceなど外部リソースへのアクセスについての処理を全て担うことによりデータ生成の処理などを集約しAPIの変更を吸収できるようにしています。これにより、マスターデータの取得など各所で散らばりやすい処理の管理を容易にしています。 Domainに処理が集中することにより、UIでロジックを書くことが少なくなりUIでは表示のための処理に集中できるようになります。 UIアーキテクチャの方針 AnewsではAtomic Designを取り入れているため、Atomic DesignをベースにPage, Organism, Molecule, Atomの４つのコンポーネントでモバイルアプリ上でUIパーツを管理します。 依存関係は、Page → Organism → Molecule → Atomの順になっており、下位から上位のコンポーネントを見ないように依存関係が混沌としないようにしています。 また、更新、データ取得などページに関わるロジックについては、全てPageのコンポーネントが管理を行うようにしPageを見るとコンポーネントの更新とデータ取得について理解できるような設計を行なっております。この様にすることで、最初に見るべきコードをPageに絞ることでエンジニアがコードの全容を理解しやすいようにしています。 今後について 上記の設計をベースに、既存アプリの置き換え業務を行なっております。一筋縄ではいかない部分もありますが、アプリ開発を行なっているメンバーからも意見をもらいながら一緒に作り直しており、2022年初頭にはリリース予定となっております。 最後に ストックマークでは一緒に働くメンバーを絶賛募集中です！Anews開発メンバーも募集していますので、ご興味があれば採用ページをご覧いただければと思います！https://tech.stockmark.co.jp/blog/20211120_mind_discovery/Wed, 08 Dec 2021 12:00:00 +0900https://tech.stockmark.co.jp/blog/20211120_mind_discovery/ML事業部の金田です。今回はAnewsへの応用を見越して実施した、公開データセット（MINDデータセット）を用いた既存ニュース推薦手法の性能確認実験について紹介します。なお、実験で用いたコードはこちらに公開しています。 背景 当社の開発する法人向けサービスのAnewsには、ニュース推薦システムが実装されています（その概要は以前の記事で紹介したとおりです）。 このシステムは、製品開発の初期段階に構築されたものです。その際には顧客要求を素早く叶えることが優先されており、当時はニュース推薦システムの研究動向を十全にフォローアップできていませんでした。構築以降に実施されたシステム品質改善も、顧客から寄せられた問題の解消を目的としていたため、「そもそも技術的観点から現行システムにどの程度改善の余地があるのか？」という疑問に対して、これまで明確な回答を用意できていませんでした。 この問題を解消するため、現在R&Dユニットでは、製品で必要とされる機能プロトタイピング/機能改善の傍ら、ニュース推薦モデルに関する論文調査・社内データへの適用性確認（現行アルゴリズムとの比較評価）を試みています。このたび紹介する内容は、この調査の過程で生まれた、公開データセット（MINDデータセット）を用いた既存提案手法の性能確認結果になります。 MINDデータセット MINDデータセット1 2は2020年にMicrosoft社の公開した、ニュース推薦のためのデータセットです。このデータセットはMSNニュース（英語）の利用ログから構築されたもので、次のデータを含んでいます。 行動データ（behavior.tsv） あるクリック履歴（history）を持つユーザが行った、あるタイミングで提示されたニュースリストに対する反応（impressions）。データの概観は下図のとおりです。 図1. 行動データの概観 ニュース記事データ（news.tsv） 行動データに含まれるニュース記事の情報。各記事は以下の属性を持ちます。 記事ID タイトル アブストラクト 本文3 カテゴリ サブカテゴリ MINDデータセットには上記以外にもデータ/ニュース記事属性が含まれていますが、ここでは以降の実験に関係するものに絞って紹介しています。 （全容及び詳細に興味のある方は公式の説明をご確認ください）。 このデータセットで扱う問題は、「あるクリック履歴をもつユーザが、与えられたニュースをクリックするか否かの予測（2値分類問題）」です。 この問題を解くモデルを推薦システムとして応用する場合は、「モデルによる予測クリック確率が高いニュースをユーザに提示する」仕組みを作ることになります。 性能確認を行ったモデル 今回性能確認を行ったモデルは、NAML4・NRMS5の2つ及び、両者にいくつかの変更を加えたものになります。 モデルの選定背景には、ニュース推薦特有の問題があります。 ニュース推薦の特色は、推薦対象となるニュースが頻繁に入れ替わることにあります。このような状況では、次のような理由から他のユーザの行動を手がかりに使う推薦(協調型推薦)が難しくなります。 まず、ニュース推薦において推薦対象となる記事は、大抵の場合速報性を重視して最新のニュースになります。つまり、誰も読んだことがない記事を推薦する必要があります。 また、頻繁に配信対象が更新されてしまうので、似たような興味を持つユーザであっても、アクセスタイミングが異なる場合は読む記事が一致しない状況が起こりえます。 これは、「似たような興味を持つユーザは似たような行動履歴を持つ」という前提が成り立ちにくいことを意味します。 裏を返せば、ニュース推薦においては、配信されるニュース/ユーザが読んだニュースの意味を手がかりとして推薦を行う仕組み（コンテンツベース推薦）の構築が重要になります。 今回選定したモデルはどちらもコンテンツベース推薦を意識したモデルであり、MINDデータセットの論文2でもベースラインに選定されています。 ちなみに、どちらもMicrosoft社の研究機関が発表したモデルです。 モデルの基本構造 NAML, NRMSは似たような構造を持つモデルです。両者の構造は下図のように抽象化して表すことができます。 図2. モデルの基本構造（論文 6 より引用） 各モデルにおいて、News Encoderはニュース記事の属性（タイトル、本文、カテゴリ等）を入力とし、その意味を表現するようなベクトル（以降記事ベクトルと表記）を出力します。 一方、User EncoderはNews Encoderによってベクトル化されたクリックされた記事の履歴を受け取り、ユーザの興味関心を表現するようなベクトル（以降ユーザベクトルと表記）を出力します。 News EncoderとUser Encoderは、同じ次元数のベクトルを出力します。これにより、あるユーザがある候補記事をクリックする確率は、ユーザベクトルと記事ベクトルの簡単な計算によって表現することができます。 今回扱うモデルでは、「ユーザベクトルと記事ベクトルの内積をsigmoid関数に通す」ことによりクリック確率を表現しています。 つまり、「２つのベクトルの向きが近い」かつ「ベクトルが大きい」ほど、クリック確率は大きくなります。 概観を掴んだところで、以降では各モデルについて確認していきます。 NAML NAMLは2019年に発表されたモデルで、下図のような構造を持ちます。 図3. NAMLモデルの構造（論文 4 より引用） NAMLのUser EncoderはNews Encoderに比して簡潔な構造を持つため、User Encoder → News Encoderの順番で確認を行っていきます。 User Encoder (NAML) NAMLのUser Encoderは、News Encoderによってベクトル化されたクリック履歴をAttentionで重み付けして足し合わせることによりユーザベクトルを出力します。 「今まで読んできた記事をバランス良く考慮する（＝重みをつける）ことでユーザの嗜好を作る」仕組みになっているといえそうです。https://tech.stockmark.co.jp/blog/how-we-accelerate-development/Mon, 18 Oct 2021 12:00:00 +0900https://tech.stockmark.co.jp/blog/how-we-accelerate-development/ストックマークの開発体制は、プロダクトの成長フェーズに合わせて、2021年夏に大きく進化しています。本エントリでは、何が課題でどう進化したのか？を紹介いたします。本エントリを読むことで、スタートアップの開発体制で発生する課題と、その解決方法の1つを理解できます。 サマリ 開発チームのパフォーマンスが最大化できていなかった 開発チームに自由と責任を委譲し、より自律的な行動を促進した スクラムを辞めて、カンバンを主軸とする開発へ その結果、開発スピードが大きく向上し、より迅速にアウトカムを提供できるように どんな課題が存在していたのか？ 大きく分けて、開発チームに関する2つの課題が存在していました。 課題1: リソースの偏り ストックマークの以前の開発体制(〜2021年8月)では、Anewsの開発チームは大きく分けて、 以下の2つが存在していました。 情報収集機能を開発するチーム コミュニケーション機能を開発するチーム それぞれのチームが、常にパフォーマンスを最大化できていれば良いのですが、実際には片方のチームがビジーであり、もう片方のチームの負荷が軽い時期がある、などの状態が発生していました。 また、Slackなどで情報同期・可視化はしているものの、一部の仕事が重複しているケースもありました。 課題2: 余剰リソースが一時浮き 新しい価値を開発をすすめる場合に、プロダクトマネージャが主導権を握っており、開発チームが自律的に新価値開発を実施できていないケースがありました。 もちろん、機能の内容や優先度はプロダクトマネージャが責務を担っている点は自然ですが、プロダクトマネージャとの調整をしないと、一時的にリソースが浮くケースがあったのです。 Anewsというプロダクトは急速に成長を遂げている真っ只中であり、新価値を高速に提供するのが重要なフェーズです。そのため、ここまで述べた2つの課題は早急に解決する必要がありました。 どのような解決方法をとったのか？ 課題2冒頭で述べた、主導権を開発チームに移しました。言葉だけだとわかりにくいので、Before/Afteを簡易Value Stream Mapで説明します。 簡易Value Stream MapでのBefore/After 最大の違いは、Push型のフローから、Pull型のフローに変更したという点です。すなわち Before: プロダクトマネージャが起点となり、Push型で開発を進めていた After: 開発チームが自律的にバックログから開発項目を取得して開発をすすめる というように変更しています。技術的なメタファーを使うと、バックログを起点とした、PubSub型と捉えていただいても良いです。 バックログ以降についての意思決定については、開発チームに委ねられています。プロダクトマネージャとスケジュールなどの概要を合意してあるため、あとは開発チームがバックログを確認しながら自律的に開発を進めています。 今回の開発体制での想定課題 開発体制によって、全ての課題が解消されるわけではありません。むしろ、いくつかの想定課題もあります。 開発チームの責務が増えるため、責務をおっている部分の問い合わせがある場合に、開発チームへの割り込みが増えてしまう スケジュールを開発チームに任せるので、開発全体が遅れる可能性がある プロダクトマネージャと開発チームが分断されるため、コミュニケーションが疎になる可能性がある 1つ目の問い合わせについては、組織マネージャという役割をおいて対応しています。組織マネージャは、開発チームのリソースの集中について判断し、開発パフォーマンスを最大化することに責務を負います。スクラムにおける、スクラムマスタの役割を一部になっているような形になります。 2つ目については、スケジュールのアラートを出す、遅れるときは開発チームとマネージャでお互いに指摘しあえるような環境を作ることで対応しています。 3つ目については、潜在的な課題ではありますが、プロダクトマネージャともコミュニケーションが十分取れており、現時点では顕在化していません。プロダクトの成熟フェーズにあわせて、価値を早く創造する仕組みを優先しています。（なお常に開発体制も進化しており、エンジニア主体の価値創造も今後は増える予定です。一緒に進めてくれる方を募集中です！） 結果どうだったか？ 定性的な指標ではありますが、プロダクトオーナーからのコメントとして「開発が早くなったね」がありました。また、プロダクトオーナー以外のメンバーからも、開発チームの速度についてのポジティブコメントが増えています。 おわりに チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 アジャイル宣言の背後にある原則の1つです。今回の開発チームの体制見直しは、まさにその一例であり、さらに言えば組織学習で言及される「ダブルループ学習」を開発チーム自ら引き起こした事例といえます。すなわち、「そもそもこの開発フローがベストなのか？」という問いを起点に、高次の学習を進めた形になります。 ストックマークの開発チームは、もちろん開発チーム自体でふりかえりを進めて、パフォーマンスを高めるためにふりかえりを進めています。これらは主にシングルループ学習であり、これ自体の価値もあります。しかし、事業フェーズが高速に変化するスタートアップにおいては、シングルループ学習のみならず、ダブルループ学習が効果的なケースもあります。 ストックマークのValueの1つは、「仕組を革新する」です。今後も、自社の仕組を革新し続けていき、お客さまと一緒に進化のドラマを作り続けていきます。 興味を持っていただけた方は、採用ページもぜひご覧ください！https://tech.stockmark.co.jp/blog/vue2_performance_with_bigdata/Fri, 01 Oct 2021 12:00:00 +0900https://tech.stockmark.co.jp/blog/vue2_performance_with_bigdata/本エントリは2021年8月30日に開催されたNode学園 37時限目 オンラインにて、「Vue 2で大きなデータを扱うときの性能改善手法」というタイトルで発表させていただいた内容をテックブログ記事化したものです。発表当日の様子はYouTubeにアーカイブで公開されておりますので、そちらも合わせてご覧いただけましたら幸いです。 はじめに ストックマークでは、法人ユーザー向けに「Astrategy」というウェブサービスを開発・提供しています。Astartegyの詳細や技術的な全体構成についてはAstrategyを支える技術: gRPC, Elasticsearch, Cloud TPU, Fargate… SaaS型AIサービスの内側の世界というエントリで紹介しておりますのでそちらを参照いただくとして、本エントリではAstrategyのフロントエンドを構築する上で重要である性能改善手法について紹介したいと思います。 Astartegyでは大きなテーブルとして可視化されたデータをインタラクティブに操作する部分があり(図1)、そのため、大きなデータを一括で取得しフロントエンドで可視化するといったことをしています。ここの設計の是非については議論の余地がある部分かとも思いますが、本エントリではそこは一旦置いておき、1MB前後のJSONがバックエンドから返され、それを高速に取り扱う必要がある場面で、いかに性能改善するかをお伝えします。 図1: ドラッグ & ドロップでインタラクティブにデータを可視化 Astrategyで取り組んだ性能改善 前提として、本エントリのタイトルにもあるとおり、AstrategyではVue 2をフロントエンド構築のためのフレームワークとして採用しています(Vue 3への移行は絶賛準備中です)。また、一口に性能と言っても様々な切り口がありますが、本エントリにおいては大きいデータを取り回してインタラクティブなコンテンツを作るということで、いわゆるランタイム性能の話に着目します。 そして、Astrategyの開発においても「推測するな、計測せよ」の鉄則に従い、Chrome DevToolsでプロファイリングしてボトルネックを見つける、そのボトルネックを改善する、さらに計測する、といったことを何度も繰り返しています。なお、DevToolsの使い方そのものについての詳細は本エントリでは紹介しませんので、適宜公式ドキュメントなどを参照いただけましたらと思います。また、以降いくつかDevToolsによるプロファイリング結果を紹介しますが、以下の環境での計測結果であることに留意ください。 MacBook Pro (16インチ, 2019) 2.4 GHz 8コア Intel Core i9 メモリ 32GB macOS 10.15.7 Vue 2.6.11 サンプルアプリ ここで、Astrategyそのものを題材として取り上げても悪くはないのですが、複雑な構成になっていて性能改善だけに着目した説明の題材としてはふさわしくないため、性能改善の効果が分かりやすいサンプルアプリを使って以降の説明を行いたいと思います。サンプルアプリは https://github.com/tsukkee/vue2-handle-big-dataにて公開しており、GitHub pagesで動作も確認できますので、興味のある方は併せて参照ください。 このサンプルアプリでは、「データロード」ボタンを押すと、20,000件のダミーデータが表示され、チェックボックスを押すと対応する箇所がハイライトされるような動きになっています(図2)。この動き自体に深い意味はありませんが、大きなリストを表示しつつその一部を変更するようなサンプルになっていると思ってください。図2を見たり実際に動かしたりすると分かるのですが、単にチェックボックスを押すとリストの一部がハイライトされるだけなのにナイーブな実装(初期状態)だと体感できるレベルで遅いことが分かるかと思います。 図2: サンプルアプリの動作 測定と改善 その1 ということで、ともかくこの初期状態で、Chrome DevToolsでチェックボックスが押されてから画面に反映されるまでをプロファイリングしてみましょう。図3に、測定結果を示していますが、updateChildrenという部分など、処理全体の後半に時間が掛かっていることが分かります。このあたりはプロファイラで末端の方まで読み解いていくと分かるのですが、DOMの更新をしている部分です。 図3: 初期状態でのプロファイリング このようなときに最も良く行われる解決方法はVirtual Scrollの導入です。Virtual Scrollとは、画面上に表示されている部分にだけDOMを配置してDOMの更新を最低限にする仕組みで、さらに、同じDOMのインスタンスを何度も使い回すことによってDOMの生成・破棄のコストも削減しています。 Vue向けにもいくつかライブラリが存在するので(例えば以下)、ドキュメントを参照し、使い勝手やそれが自分たちの要件に合っているかなどを勘案して選定すれば良いかと思います。今回のサンプルアプリでは上のVue Virtual Scrollerを採用しています。 https://github.com/Akryum/vue-virtual-scroller https://github.com/tangbc/vue-virtual-scroll-list なお、実際のAstrategyで、図1の箇所など一部画面が複雑になっており既存のライブラリがそのまま適用できなかったので、IntersectionObserverを使って似たような仕組みを自作するなどの工夫を取り入れています。 Virtual Scroll導入時の注意 Virtual Scrollは導入するだけで大きなリストの描画を最適化できるので便利なのですが、いくつか利用上の注意点もあります。 まず、Virtual Scrollを導入すると、当然ながらスクロールアウトしてしまっているテキストが実際のDOM上には存在しなくなるため、ブラウザのテキスト検索で探せなくなってしまいます。そのため、ユースケースによっては別途リストに絞り込み機能や検索機能などを実装し、ユーザビリティを損なわないようにする必要があるかも知れません。 また、Virtual Scroll自体の初期化時間も無視できなくなってくるケースもあります。例えば、Astrategyだと一つの画面上に10〜20ぐらいのVirtual Scrollリストが配置されることがあり(図4)、この画面の表示が遅くなるという問題があります。この場合は例えば、初期状態では通常のv-forを使ったリストで上位10件程度のみを表示し、mouseoverで動的にVirtual Scrollに置き換えることによって、初期化を遅延させるなどの工夫が必要となります。https://tech.stockmark.co.jp/blog/gpu_translate/Tue, 15 Jun 2021 11:30:00 +0900https://tech.stockmark.co.jp/blog/gpu_translate/はじめに こんにちは、ストックマークでエンジニアをしている麻生です。ストックマークでは、「Anews」というウェブサービスを提供しています。この度、Anewsで新機能導入のために日次バッチの大規模なインフラ変更を行い、GPU並列処理環境を構築しましたのでご紹介します。 組織の自律化を支援するナレッジプラットフォーム「Anews」 Anewsは国内外30,000メディアのニュースを毎日収集し、最先端の自然言語処理で個人や組織のミッションに即したニュースをレコメンドします。コメント機能で簡単にチームにアイデアを共有でき、社内の知見者から学ぶことでチームの情報感度が底上げされます。 エンタープライズを中心に、累計1500社以上のお客様にご利用いただいているサービスです。 Anewsのプロダクトイメージ 英語記事をレコメンドする上での課題 Anewsでは、記事への行動履歴からユーザーや組織の好みを学習し、記事をレコメンドしています。ユーザーが記事に対してシェアやコメントをするほど行動履歴が蓄積され、記事のレコメンド精度が向上する仕組みです。 レコメンドについてはこちらの記事に詳しい解説があります。 アクションを取らなければ記事のレコメンド精度の向上が見込めないのですが、そこで問題になるのが英語記事です。日本語を母国語とする以上、英語記事を読むのは負荷のかかる作業で、どうしても記事へのアクションが少なくなってしまいます。そのため、英語記事のレコメンド精度は上がりにくく、精度が低いことでレコメンドに繋がる行動履歴も蓄積されない、という悪循環に陥っていました。 お客様によっては海外の情報が重要なケースもあり、英語記事のレコメンド精度をいかに上げるかが課題でした。 日本語記事への行動履歴活用によるレコメンド精度向上 そこで今回持ち上がったのが、日本語記事への行動履歴を元に、英語記事をレコメンドするというアイデアです。英語記事を読まないユーザーも日本語記事への行動履歴は蓄積されているため、それが使えれば英語記事のレコメンド精度を向上させられるはずです。 単純なアイデアですが、英語と日本語では文章の性質が全く異なるため、日本語記事への行動履歴をそのまま英語記事に活用できません。一度、日本語記事を英語記事に翻訳することで、あたかも英語記事へのアクションがあったかのようなデータを作成する必要があります。 レコメンドの流れ 社内の機械学習チームの検証結果を踏まえ、transformer-align というモデルによる翻訳処理をプロダクトに組み込むことにしました。 翻訳処理導入に向けたインフラの見直し 今回の施策によってワークフローが変更になります。新しいワークフローでは、英語記事のレコメンドの前に翻訳処理が入ります。 変更後のワークフロー この変更により、EC2インスタンス1台体制だったインフラを大幅に見直す必要が出てきました。 ポイントは以下の3点です。 翻訳処理用のGPU並列処理環境を用意する 翻訳処理をCPUで実行すると時間がかかりすぎて、ユーザーがアプリを使うまでに処理が終わりません。GPUが利用可能、かつ、記事量に応じて並列数を増やしていけるような環境が必要でした。 既存処理環境（CPU環境）と翻訳処理環境（GPU環境）を分離する GPUを必要としない既存処理もGPU環境で実行してしまうと、必要以上にコストが高くなってしまいます。そのため、既存処理と翻訳処理の環境を別々のサーバに分けることにしました。 ワークフローエンジンを導入する CPU環境とGPU環境を分離すると、サーバを跨いだワークフロー管理が必要になります。EC2インスタンス1台のときには不要だったワークフローエンジンを導入します。 翻訳機能導入後のインフラ 変更前後のインフラ構成は下図の通りです。選定理由を簡単にまとめていますが、ここに至るまでに動作確認とインフラの再構築を繰り返したり、AWSの方にアドバイスいただいたりと試行錯誤しながら進めました。 変更前後のインフラ構成 翻訳処理（GPU処理）の環境は AWS Batch + Amazon EC2 と AWS Lambda 翻訳処理には、GPUを利用可能、かつ、並列処理を実装しやすい AWS Batch + Amazon EC2 を採用しました。 並列処理は配列ジョブで実装しています。翻訳する記事数に応じて並列数が決まるように、一度 AWS Lambda で記事数をカウントして並列数を決定した後、ジョブキューにジョブを送っています。配列ジョブでは、各ジョブがAWS_BATCH_JOB_ARRAY_INDEXという環境変数を割り当てられます。各ジョブはこの環境変数によって自身が処理する記事を識別します。 翻訳処理の実行例がこちらで、10並列でジョブが走っています（キューのメッセージ取得、インスタンス起動、コンテナ起動とオーバーヘッドがあるため完全に同じタイミングにはなっていません）。最大32並列で実行可能な設定にしています。 並列処理実行例 既存処理（CPU処理）の環境は Amazon ECS + AWS Fargate 既存処理はEC2インスタンス1台で運用してきましたが、EC2 は他の AWS リソースとの連携が困難なため、翻訳処理と連携が取れるように環境を変更することにしました。 候補には AWS Lambda、Amazon ECS、AWS Batch が挙げられるのですが、既に一部のタスクを Amazon ECS+Fargate で実行できるようにしていたため、それベースに他のタスクに拡張することとしました。https://tech.stockmark.co.jp/blog/20210601_anews_recommendation/Mon, 07 Jun 2021 12:00:00 +0900https://tech.stockmark.co.jp/blog/20210601_anews_recommendation/ML事業部の金田です。今回は、ストックマークの提供する法人向けサービス「Anews」の裏側で動くビジネスニュース推薦システムについて、簡単に紹介いたします。 Anewsとは Anewsは組織変革のための情報収集＋コミュニケーションプラットフォームです。 情報収集のためのコア機能としては、国内外３万メディアから収集したビジネスニュースから、利用者の興味・関心に合わせて記事を配信するサービスを提供しています。日々配信されるニュースから業務ニーズに直結するインサイトを獲得し、これを話題にユーザ同士が交流することで、組織全体の情報感度やコミュニケーションを促進させるのが、サービスの狙いです。 Anewsのプロダクトイメージ 事前準備：ことばの定義 具体的な機能説明の前に、Anewsにおける基本的な概念について軽く整理します。 Anewsは1企業＝1集団としての利用を想定しています。以降ではこの集団をチーム、チームに所属する各利用者をメンバーと呼ぶことにします。ニュース配信の際に利用する情報は、基本的にチーム毎に独立しています。 各チームでは、特定の話題を追うためのチャンネルであるテーマを作成することができます。テーマに存在するテーマフィードには、設定されたキーワードにマッチするようなニュースリストが一日一回配信されます。 キーワード設定画面 テーマ画面。「関連ニュース」及び「新着ニュース」がテーマフィードに相当 一般に、レコメンデーションシステムではコールドスタート問題の解消が課題とされます。これは、サービスを初めて利用するユーザに発生してしまう、次のような問題です。 初利用するユーザからは興味・関心を表す手がかりが得られないため、よいレコメンドが行えない よいレコメンドが行われないため、ユーザが自身の興味・関心を提示する前に離脱してしまう テーマフィードでは初期設定時のキーワードを手がかりとすることで、この問題に対処しています。 メンバーはフィード上のニュースに対し、自由に閲覧、マーク、コメントといった行動をとることができます。これらの行動は、より良いニュースを配信するための手がかりとして利用されます。テーマフィードに配信されるニュースリストはメンバーに依らず同一であるため、これを共通の話題として扱うことができます。 行動履歴が一定以上蓄積したメンバーに対しては、一人ひとりの嗜好に合わせたニュースリストを、個人フィード上に一日一回配信しています。こちらは各メンバーの持つ興味/知識の更なる深堀りを意図した機能です。 このように、メンバーの興味・関心に合わせてコンテンツ配信を実現する推薦システムがAnews内部には組み込まれています。 Anewsのニュース推薦システム 基本コンセプト Anewsのニュース推薦システムでフィードに配信する記事を決定する際には、「行動がなされた記事の集合」を手がかりとして利用します。 個人フィードでは、「任意の場所で、該当メンバーによって行動がなされた記事」を手がかりとします。「メンバーは、自身の嗜好（＝興味・関心）にマッチした記事に対して行動する」と仮定すると、この記事集合は、「メンバーの嗜好を表す記事の集合」として捉えることができます。よって以降では、これを「メンバーの嗜好記事群」と呼ぶことにします。 メンバーの嗜好記事 一方テーマフィードでは、「該当フィード上で、任意のメンバーにより行動がなされた記事の集合」を手がかりとします。こちらは「テーマの嗜好記事群」と呼ぶことにします。 テーマの嗜好記事 記事をフィードに配信する際は、それぞれの嗜好記事群と意味的に近い記事を候補の中から選びます。これは、「過去に反応を示した記事と似ている記事に対しても、ユーザは同様の反応を示す」という仮定に基づいています。 このようにコンテンツ（記事）の内容比較による推薦は内容ベース推薦と呼ばれます。一方で、「この商品を買ったユーザはこのような商品も買っています」と言った文言に代表されるように、別のユーザの行動を参照して推薦を行う手法は協調型推薦と呼ばれます。toBサービスであるAnewsは、toCサービスに比してユーザ数が少なく、ユーザ毎の利用動機のばらつきも大きいため、協調型のアルゴリズムを利用する領域は一部に限られています（今回の紹介範囲には含まれていません）。 ただし、意味的な近さを考慮する際には注意点があります。嗜好記事群には、複数の話題が混在する場合があります。配信候補記事と嗜好記事群を比較する際には、嗜好記事群に暗黙的に含まれうる様々な話題を考慮した上で、意味的な近さを計算する必要があります（例えば、話題AとBの二つに興味のあるメンバーには話題AまたはBに関連する記事を配信したい）。 要素技術: 概要 上記コンセプトを実現する要素技術としては、次の3つが挙げられます。 記事の意味的な近さを定量的に計算するため、記事の意味をベクトルで表現する 嗜好記事群に混在しうる複数の話題を適切に分離するため、嗜好記事群をクラスタリングする クラスタリングされた嗜好記事群と配信候補記事の類似性を、いくつかの指標でスコアリングした上で各スコアを統合し、最終的なスコアの高い記事を推薦する 技術3. についてはやや職人芸的要素が強く話が複雑になってしまうため、以降では主に1.と2.について紹介します。 要素技術1. ニュース記事の意味をベクトルによって表現する 当社では、国内・国外合わせて約3万メディアから、日々数万〜十数万件のニュースを収集しています。収集された記事は解析、構造化の後データベースへ格納されます。アプリケーションで利用可能な記事の情報としては、次のようなものが挙げられます。 タイトル 本文 記事の公開日 サムネイル画像 etc 記事のベクトル化（記事ベクトル作成）に際しては、これら情報のうちタイトル及び本文、すなわちテキストデータのみを利用しています。テキスト（文章）の表す意味をベクトル化する手法は数多く提案されていますが、Anewsにおいては以下を採用しています。 テキストに含まれる単語にベクトルを割り当てる 割り当てられたベクトルを単語の重要度に準じて重み付けし、足し合わせる 具体的には、1.においてはWord Embeddingと呼ばれるモデルの一種であるfastTextを、2.の重みについてはSIFを利用しています。両者は近年隆盛を誇っているTransformerモデル以前の技術ですが、Anewsでは以下のような背景から、実装/運用コスト等を含め総合的に判断した上で採用しています。 Anewsは一度プロダクトの刷新を行っている。この際には推薦アルゴリズムも一から書き直すことになったが、検証〜実装に使える時間は限られていた。 word embeddingベースの手法はCPUで学習・推論が可能であり、アプリケーション応用のハードルが低い。また刷新前のAnewsでも利用実績があり、一定の知見・成果を得ていた。 社内データを利用してm~USE, LaBSE等の最新モデルとの性能比較を行ったところ、目立ったパフォーマンスの劣後は見られなかった。 以降では、軽くWord EmbeddingとSIFの性質についても触れてみます。 Word Embeddingは単語に対し、その出現文脈に依存せず一意のベクトルを割り当てます。つまり、これだけでは動物を指す「ライオン」と、企業を指す「ライオン」を区別することはできません。 しかし、語義が異なれば、文中に現れる単語も異なることが想定されます。企業の「ライオン」に言及した記事であれば、「歯ブラシ」、「新製品」といった単語が文中に現れるでしょう。一方、動物の「ライオン」に言及した記事であれば、「動物園」「サバンナ」といったような単語が文中に現れるでしょう。 これら文中に現れる単語のベクトルを適切に重み付けして足し合わせることで、「企業のライオンについて言及している記事」と「動物のライオンについて言及している記事」の区別が可能になります。 SIFはWord Embedding同様、単語に対し、出現文脈に依存せず、一意の重みを割り当てます。この重みは、高頻度で出現する単語ほど小さくなります。例えば助詞の「を」や「が」は、多くのニュースにおいて高頻度で出現する単語です。これらの単語に対する重みを小さくすることで、SIFは「不要な単語を無視する」ような働きをします。 ちなみに、これらの具体的な意味を持たない頻出単語は、自然言語処理において「ストップワード」と呼ばれます。古典的な自然言語処理において、ストップワードは前処理段階で除外されるのが理想とされます。しかし、SIFを利用する場合、この処理を挟まずとも高品質な記事ベクトルを作成することができるため、実装がシンプルになるというメリットがあります。 要素技術2. 嗜好記事群をクラスタリングする 記事をベクトルによって表現することで、一般的なクラスタリング手法をそのまま適用することが可能になります。ここでは、コサイン距離（=1-コサイン類似度）を用いたウォード法を採用しています。 ウォード法は次のような性質を持つクラスタリングアルゴリズムです。 各要素を、必ず特定のクラスタに結びつける（ハードクラスタリング） 各要素を独立したクラスタに入れ（N要素の場合はNクラスタができる）、終了条件を満たすまで近接クラスタ同士を結合していく（凝集型クラスタリング） 終了条件にはいくつか設定の余地があるのですが、嗜好記事群のクラスタリングにおいては「結合を許すクラスタ間距離にしきい値を設ける」方法を採っています。このしきい値を入力された記事群に応じて動的に調整することで、次のような要求に対応できるようにしています。https://tech.stockmark.co.jp/blog/astrategy_overview/Mon, 10 May 2021 00:00:00 +0900https://tech.stockmark.co.jp/blog/astrategy_overview/ストックマークでは、法人ユーザー向けの「Astrategy」というウェブサービスを開発、提供しています。 本エントリでは、Astrategyで使われている技術やシステム構成をご紹介したいと思います。 Astrategyとは Astrategyとは、AIがウェブニュースを解析してあらゆる市場の動向やトレンド、有力企業の経済活動を可視化し、ユーザーが市場調査や市場分析レポート作成を行うことができるウェブサービスです。 国内外約3万メディアから配信された約5000万件のビジネスニュースから、企業情報、言及されているニューストピック、業界や地域属性を抽出して分析に利用します。 抽出には汎用言語モデルBERTを用いており、その処理はCloud TPU上で動く重たい処理であるため、事前に全てのニュースデータに対して抽出処理をかけた状態で検索サーバーに登録しています。 ユーザーがAstrategyにアクセスし、欲しい記事の条件を入力すると、検索サーバーからその条件に合う記事を一度に取得し、そこにどのようなテーマが含まれているか、どのようなプレイヤー(企業、団体など)が存在するかなどを複数の切り口でインタラクティブに可視化します(図1)。 さらに、検索・分析の過程を保存する「ワークシート」と呼ばれる機能により、検索から分析の試行錯誤や定点観測をサポートしています。 図1: 「自然言語処理」についてテーマ x 企業で分析している様子 高速なデータ構造化とリアルタイム分析を行うアーキテクチャ アーキテクチャの全体像は図2のようになっており、AWSとGCPを利用しています。 図2: Astrategyのアーキテクチャ 記事検索機能にはElasticsearchを用いており、そこにアクセスする部分のほとんどがPythonで書かれたマイクロサービス（AWS Fargate）となっています。 フロントエンドと各マイクロサービスとの間にはRailsをAPIサーバとして配置し、BFF(Backend for Frontend)のような扱いで利用しています。 それによって、各マイクロサービスとRailsはgRPCによって高速に通信しつつ、フロントエンド向けにデータを加工して返しています。 もう一台あるElasticsearchは、検索キーワード等の自動補完用です。 マイクロサービス（Fargate）からアクセスされているS3は、オンライン処理に利用される辞書データなどが入っており、Fargateの起動時にアクセスされそのFargateのメモリにロードされます。 ワークシート機能はAWSのDynamoDBを使って実現しています。 これによってフロントエンド主導でデータ構造を決めることができるため、高速な仮説検証と機能追加・改善が可能となっています。 それ以外のデータはMySQLに保存されており、オーソドックスにRailsのActive Recordから利用しています。 クローラーがその日に取得した数万件の記事は、記事検索に利用するElasticsearchにバッチ処理で登録します。 バッチ処理はAWSとGCPによるマルチクラウド構成となっています。 数万件に及ぶ大量の記事を時間内に処理するため、まずAWSでは、Cloudwatch Eventで定時起動したFargateやAWS BatchをStep Functionsで制御してGPUインスタンスを並列稼働させてElasticsearchへ登録しています。 さらに、企業名抽出、キーワード抽出など特段時間のかかる処理はGCPのCompute EngineとCloud TPUで個別に処理しています。 また、Lambdaで構成したバッチ処理を別時間帯に起動するなど、提供する形式に合わせてバッチ処理を分割して記事配信時間までに処理が完了することを担保しています。 フロントエンドの構成 フロントエンドは、スピーディな検索体験を提供するため、いわゆるSPA(Single Page Application)として構築されています。 フレームワークとしてVue.jsを採用し、コンポーネントは全てSFC (Single File Component) で構成しています。 scriptにはJavaScriptは使わずTypeScriptのみを用い、型のある開発を行っています。 CSSには、import機能や変数、ネスト機能などの機能の恩恵を受けるためにSassを使用しています。 Astrategyの特徴として、一度に大きいデータをバックエンドから受け取り、それらをインタラクティブに可視化することが重要な要件であることがあげられます。 そのため、データ可視化部分の信頼性を担保するテスタビリティの高い設計と、大量のデータを扱うためにパフォーマンスを重視した実装を指向するようにしています。 具体的には、例えば以下のような取り組みを続けています。 テスタビリティを上げる取り組み 純粋な関数で表現できるデータの変換部分をコンポーネントから切り離す 状態を持つ部分(特に上記「ワークシート」を実現する部分)はVuex or Provide/Injectされたモデルに集約する パフォーマンス向上に繋がる取り組み (特にVue 2では)Vueのリアクティブな変数は性能面の課題が大きいため、巨大なオブジェクトや配列はコンポーネントに渡す前に処理したり、リアクティブな変数に変換させないように設定する 大量に項目があるリストや表については、画面内に描画するコンポーネントのみDOMを生成するようにする DOMの階層が深くなったり、レイアウト用のDOMが増え過ぎないように、CSSのGrid/Flexboxを活用する これらのほか、PrettierやESLintを用いたコード品質の向上にも取り組みました。 以上の取り組みから、例えば図3のように滑らかな操作が可能となり、 ユーザーからUIの重さに起因する不満が挙がることはほぼなくなってきました。 さらに、フロントエンドでのより複雑な分析や可視化にも取り組めるようになってきています。 図3: ドラッグ & ドロップをサポート またデザイン面では、ストックマーク社内でdonguriと名付けられた共通のデザインシステムを運用しており、Astrategyにも適用しています。 これによって、他プロダクトとのUIの一貫性を保てるほか、開発効率の向上にも繋がっています。 ユーザーの皆様からもUIの使い勝手についても良いフィードバックをいただくことが多くなっています。https://tech.stockmark.co.jp/blog/gpt2_ja/Wed, 03 Feb 2021 12:00:00 +0900https://tech.stockmark.co.jp/blog/gpt2_ja/はじめに Machine Learning部門の江間見です。ストックマークでは、自然言語処理技術の研究開発を行っています。 昨今、OpenAIからGPT-3が発表され、生成系モデルが大きな注目を集めています。 そこで、本記事では、弊社で作成している生成系モデルの紹介をいたします。 自然言語処理におけるテキスト生成 自然言語処理（NLP）は、人間の言語（自然言語）とコンピュータの相互理解、特に大量の自然言語データをコンピュータに処理および分析させるための研究分野です。 今回紹介するテキスト生成は、この自然言語処理の研究分野の一つです。 テキスト生成の応用例の一つは、スマートフォンのキーボードでの次の単語の予測です。このタスクはまさに​​言語モデルが行うことと同様です。言語モデルは、単語のリストを受け取り、次の単語を予測します。 図1の例では、言語モデルが「今日は」という単語を受け取り、次の単語である可能性の単語リストを返すシステムと考えることができます（図では、「良い」が最も可能性が高い単語です）。 図1. スマートフォンでの次単語予測の一例 テキスト生成モデルは、基本的に次の単語の予測を自動的に繰り返してテキストを生成する言語モデルです。 テキスト生成モデルにも多種多様なモデルがありますが、本記事では、OpenAIから発表されました「GPT-2」を取り扱います。 GPT-2とは 2019年2月にOpenAIからGPT-2が発表されました。 本モデルは、発表時にOpenAIの開発陣から「あまりにも高度な文章が作成でき、危険過ぎる」と危惧されGPT-2の論文公開が延期され、また、開発された4つのモデルも一気に公開せず、2019年2月、5月、8月と段階的に公開されました。 現在では、さらにバージョンアップされたGPT-3も発表されています。 GPT-2はTransformerをベースとしたテキスト生成モデルであり、与えられたテキストの単語を元に、逐次的に次の単語を予測します(図2は、「今日は」と「良い」という単語がGPT-2に与えられて、その単語群に続く単語を予測し、予測した単語とその前までに出現していた単語を元にさらに次の単語を予測しています)。 図2. GPT-2でのテキスト生成イメージ GPT-2の詳細について今回は割愛しますが、興味がある方は、Jay Alammar氏が公開しているThe Illustrated Transformerというサイトにイラスト付きで説明されていますので、参照してみてください。 GPT-2には、OpenAIで公開された4つのバージョン(Small、Medium、Large、X-Large)があります。 それぞれ、異なるレイヤー数（デコーダーブロック）、アテンションヘッドの数、および埋め込みサイズとなります。モデルが巨大になるほど、パフォーマンスが向上しています。 図3. OpenAIから公開されているGPT-2のモデルの種類 StockmarkのGPT-2 弊社でも、ビジネスニュースを学習データとして、日本語のGPT-2を作成しました。 弊社のGPT-2は、EleutherAIのGPT Neoを参考にパラメータをセットしています。 GPT-2のMedium モデルに似ていますが、レイヤー数（24レイヤー）とアテンションヘッド（アテンションヘッド16）がMediumモデルと同等、埋め込みサイズ（1536）とコンテキストサイズ（2048）がMediumより大きくなっています。これらの違いにより、GPT-2のLargeのパラメータ数と同じ最大760Mにパラメータの数が増加しています。 そして、学習には、Adamオプティマイザーを使用して、TPUv3で、バッチサイズは2048、学習率は2.5e-4で、16日間トレーニングしました。 最終的にモデルを約9000イテレーションでトレーニングした後、lossが約2.8に収束しています。 テキスト生成 弊社のGPT-2でテキスト生成をしてみます。 以下のテキストをGPT-2へ入力してみます。ちなみに、このテキストは弊社HPに記載している取締役CTO有馬のメッセージです。 入力テキスト 「ビジネスとは本来クリエイティブで楽しいものであり、最大のエンターテイメントの1つであると考えています。50年来のブレイクスルーを得た機械学習技術でならば、単なる生産性向上や後ろ向きなコストカットだけでなく、ビジネスにおける創造性の幅を極大化させ、人々の勇気ある挑戦を後押しできると考えております。」 上記のテキストから以下のテキストがGPT-2によって生成されました。 出力テキスト 「私はこの点について非常に強い確信を持っています。 開発者・技術者双方にとって大変面白いプロジェクトだと言えるのではないでしょうか。まず、私たちの仕事をする言語は、コンピュータネットワークよりも文章を素早く正確に翻訳する特性があります。処理が自動化され、人間がより早く、より効率的に判断できるように進化しているからです。 ディープラーニングは、人間や機械が人間と対話できるよう、自動的に能力を向上させたことで大きな成功を収めましたが、近年さらに人間の感情を理解できるよう、ディープラーニングは進化を続けています。 互いに考えを巡らせることも非常に難しく、人とやり取りする際の妙な問題が発生したり、データと実世界をつなぐことができなくなっています。だからこそ、我々がこうした歴史的瞬間を切り開くことで、未来のビジネスが発展する可能性を持ちたいです。 私たちの50年の歴史は、ビジネスの成功、クリエイティビティ、社会実装の3点の軸で成り立ちます。この3軸の中で、いまやIT革命と呼んでいいでしょう。あらゆる分野に進化した者がそのことを忘れがちなのです。 (以下、省略)」 生成されたテキストが事実かどうかは置いておいて、入力テキストに続くそれらしいテキストが生成されているように見えます。 なお、実際はこの10倍くらいのテキストが生成されていますが、長文で読み辛いので、省略しています。 また、生成されたテキストの最終部分(今回は省略部分)は、最初の話題からかけはなれ、学習塾業界の話になっていました。これは長文を生成することで少しずつ本来のテキスト意図から離れていってしまったことが原因です。 もう一つ以下のテキストを試してみます。ストックマーク株式会社についてテキストを生成してもらいましょう。 入力テキスト 「ストックマーク株式会社は」 出力テキスト 「1961年の創業以来、事業領域を拡大し、独自のビジネスモデルを確立してきました。本年度は収納グッズのシェアリングサービス[Reliable(リーリーブル)]、リユースの[Rival(再)」]、スマートフォンサイト[Rakugeki(らくエビ)]の3分野への拡大、収納支援ツール[Rakote(ラクット)]の拡販に注力します。リユースは今後も積み重ねることで集積される時代で、ロイヤリティの高い商品、価値ある商品を適切かつお得に購入・販売することができるようになると考えています。 日本では1990年代後半から2000年代前半に、都市化に伴う住宅ローンや住宅ローン問題の不満から、新築住宅の購入を躊躇し始める人が多くいました。加えて、その後のバブルな住宅ブームは、世帯数の減少や新築住宅の価格変動など、消費者が住まいを気にする方向に、大きな影響を与えるようになりました。 暮らしに課題を抱える消費者の中からは、中古住宅購入以外の利用に抵抗感をもつ声も多く、既存住宅の流通は活発ではなくなってきています。移動時の転勤や女性が家を持つのに手間、家は実需に比べて購入期間が圧倒的に短く、中古住宅の場合は購入まで後々の維持管理や修繕費で時間が掛かるという声をよく聞きます。当社は、中古住宅購入の機会と住宅購入の選択肢を広げることで、住宅購入の選択肢を広げたくています。 当社では、長期優良住宅や民間住宅、中古住宅の仲介プラットフォームを通じ、大手流通企業の参入のみならず、自治体や金融機関向けの住宅ローンサービスなどを行うことで、中古住宅市場の活性化につなげたかったと考えています。 昨年6月、住宅購入検討者はクロスマッチ(機会損失)を避け、住宅購入の“選択肢”として、戸建て住宅や借り換え住宅よりも、流通企業の新築住宅や賃貸住宅ブランドを用いた住宅選びをあわせて選択する時代となり、当社は、住宅購入処理精度の向上により住宅購入をスムーズに検討している消費者に対し、住宅メーカーと連携して提案できる環境を整備することで、CBRE(住宅金融支援機構)への関心を高めていくことを目指します。(以下、省略)」 完全なフェイクテキストですが、生成されました。どうやら住宅関係の会社のようですね。 「スマートフォンサイト[Rakugeki(らくエビ)]」等は実際のサービスのように見えるので、Webで検索しましたが、見つけることができませんでした。似たような文章からGPT-2が生成したように見受けられます。 上記の2つの例では日本語としてはそれらしきテキストを生成することができました。 もちろん、上手くいかないパターンもありますが、自動でここまで生成できること自体、驚くべき結果です。 本記事を読んでいただいた方も試せるようにGoogle Colaboratoryを作成しましたので、Google Colaboratoryの使い方をご存じの方は以下リンクからぜひ試してみてください。 なお、弊社のGoogle Cloud Storageからモデルをロードするために、アクセス数によって夜間の停止等の可能性がありますので、ご了承ください。https://tech.stockmark.co.jp/blog/flutter/Wed, 23 Dec 2020 12:00:00 +0900https://tech.stockmark.co.jp/blog/flutter/はじめに 2020年11月にリリースされた、ストックマークのAnewsのモバイルアプリケーションにはFlutterが利用されています。本記事では、Flutterをなぜ採用したのか、どのような点に課題があり、どのように工夫していったのか、という開発現場の知見について紹介いたします。(本記事は、実際に開発を行った祖父江 聡士さん・海老原 隆太さんへの社内インタビューを元に執筆されています） Flutterで開発されたAnewsの画面イメージ Flutterとは Google社によって開発されているオープンソースのフレームワークです。クロスプラットフォーム向けの開発が可能であり、iOSやAndroidといったモバイルアプリケーションに多く利用されますが、Windows/Mac/Linuxといったプラットフォームのアプリケーションも開発可能です。 StockmarkにおけるFlutterの適用領域 Anewsは日々のニュースをユーザの趣向にあわせて提供するプロダクトです。システム構成は、バックエンドに備えるREST APIをフロントエンド側から叩いて、ユーザ側の画面を生成する、というシンプルな構成となっています。この、AnewsのモバイルアプリケーションにFlutterを利用しています。 AnewsのWebアプリケーションでは、ユーザがブラウザ上でURLをクリック/タップした場合に、別タブで表示しますが、モバイルアプリケーションでは内部のWebViewに表示するようにしています。これは、見ているページをマークする・ページに対してコメントするなどの付加機能を、ユーザが簡単に利用できるためであり、ユーザ価値を高めています。 技術選定の経緯 もともと、以下の方針が候補として上がりました。 WebView Native + WebView Native また、同じく iOS -> Android といったように別々に作るか、クロスプラットフォームで同時に作るかという観点がありました。 このときの社内体制として、iOS/Androidのネイティブ開発の経験が十分にあるメンバーはいませんでした。そのため、Nativeで別々に作る場合には、学習コスト含め、ある程度の期間が必要な点が見込まれます。 クロスプラットフォームで開発する場合も、専用の言語やフレームワークの学習コストが発生しますが、仮にクロスプラットフォームで上手くいけば、短期間で複数のアプリケーションを開発可能です。 そこで、クロスプラットフォーム開発の候補としてReact Native、Flutterなどが意見としてあがり、社内に経験者がいたFlutterの技術調査・検証から開始しました。その結果、今回の要求実装として、Flutterで実現困難な箇所は無い(例: GPSなどOS特有の機能を必要としない、非常に複雑なUIなど)と判断できたため、Flutterで進めています。 最終的に開発はスムースに進み、iOS/Androidのアプリケーションを両方ともリリースできています。 上手くいったコツ 以下で、上手くいった要因について3点ほど紹介いたします。 1. モブプログラミングの活用 Flutterに関する技術知見をメンバ間で効果的に展開するために、開発の序盤では、毎日Discordで集まりつつ、モブプログラミングを実施していました。 モブプログラミングでは、スキルトランスファーという観点以外にも、問題に対面した場合に気軽にメンバと話をしながら、問題解決を高速に進められています。 2. 学習と実装の並行 UIを構築する部分、UIの状態変化を担う部分と構成を分けていた点があります。前者のUI構築部分は比較的容易であり、ある程度の前提知識を身につければ、開発を進められます。そこで、UI部分についてメンバの1人が早期に学習し、別メンバへノウハウを展開しました。 その後、別メンバがUI実装をメインに実装している間に、もともとUIについて早期に取り組んでいたメンバが、状態変化のロジックを学習を進め、開発が並行して効率的に走るように工夫しています。 3. 体制構築上の工夫 経験豊富な方に業務委託として一時的にジョインしていただきました。理由などの詳細は後述します。 大変だったところはあったのか？ ここは非常に大変だった、という箇所はありませんでした。 計画の段階でiOSのビルドやアプリのCIに課題があると感じていたのですが、経験豊富なメンバに一時的に参加いただいて、その箇所を対応いただきました。(CIは速度面から、Bitriseを最終的に活用しています) また、Dartという言語を新たに学ぶ必要もありますが、もともとDartは、AltJSとして利用されていることもあり、フロントエンドエンジニアであればかなり学習コストは低いです。（メソッドの名前が違う点は、覚える必要があります） FlutterのUIを組むのも、Widgetの組み合わせで実現可能であり、概念自体はVueなどのComponentを組み合わせるのと似ています。 強いていえば、状態管理のプラクティス動向が安定していない点があります。プロジェクト内で技術調査し、今回のプロジェクトではRiverpodを採用しています。最初は、状態管理の考え方を理解する必要がありますが、慣れてしまえば、特にハマる箇所もなく進めていけました。 今振り返って開発してみてよかったこと リリーススケジュール上、iOS版を先行でリリースしています。 そのためテストはiOSでのみ行っていたのですが、その後のAndroid版リリース時にもほとんどの機能がそのまま動作しており、 開発者体験がとても良かったです。 一般に、モバイルアプリケーション開発は大変という話も聞きますが、今回はFlutterが上手く大変な部分を隠蔽してくれていました。 また、部分的にSwiftやKotlinで個別対応が必要かもしれない、とも考えていました。しかし結局、ほぼ触らずに進められており、こちらも開発全体として良かった点になります。 今後の開発体制について フロントエンドエンジニアのスキルがあれば、Flutter開発向けのオンボーディングが迅速に実現できます。Flutterも書けるスキルを身に着け、チーム全体として分担して開発できるような体制を実現していきます。https://tech.stockmark.co.jp/blog/202012_ner_dataset/Tue, 15 Dec 2020 12:00:00 +0900https://tech.stockmark.co.jp/blog/202012_ner_dataset/ML事業部の近江崇宏です。 ストックマークではプロダクトで様々な自然言語処理の技術を用いていますが、その中のコア技術の一つに固有表現抽出があります。固有表現抽出はテキストの中から固有表現（固有名詞）を抽出する技術で、例えば「Astrategy」というプロダクトでは、固有表現抽出を用いてニュース記事の中から企業名を抽出しています。（企業名抽出については過去のブログ記事を参考にしてください。） 一般に、固有表現抽出を行うためには、大量のテキストに固有表現をアノテーションした学習データをもとに機械学習モデルの学習を行います。今回、ストックマークは固有表現抽出のための日本語の学習データセットを公開いたします！ご自由にお使いいただければと思います！ レポジトリ：https://github.com/stockmarkteam/ner-wikipedia-dataset 固有表現をハイライトしたサンプル：https://stockmarkteam.github.io/ner-wikipedia-dataset/index.html このデータセットは日本語版Wikipediaから抜き出した文に対して、固有表現のタグ付けを行なったもので、全体で約4千件ほどとなっています。アノテーションを行なった固有表現のカテゴリーと固有表現数は下のようになっています。分類は関根の拡張固有表現階層を参考にしました。 タイプ 固有表現数 備考 人名 2382 法人名 2311 法人または法人に類する組織 政治的組織名 707 政治的組織名、政党名、政府組織名、行政組織名、軍隊名、国際組織名 その他の組織名 658 競技組織名、公演組織名、その他 地名 1443 施設名 512 製品名 576 商品名、番組名、映画名、書籍名、歌名、ブランド名等 イベント名 526 今後、このデータセットを用いた実験やスクリプトなども公開できればと考えています。https://tech.stockmark.co.jp/blog/202010_tpu_gcp_system/Wed, 04 Nov 2020 12:00:00 +0900https://tech.stockmark.co.jp/blog/202010_tpu_gcp_system/ML事業部の近江崇宏です。 Stockmarkでは日々、膨大な数のニュース記事に対してBERTの推論処理を行なっています。このような重いタスクを効率的に処理するために、最近、TPUを用いたBERTの推論処理基盤をGoogle Cloud Platform上に構築し、運用を開始しました。その結果として、これまで1週間程度かかっていた、数千万件のデータの処理を1日以内で完了できるようになるなどの大きな効果を得られました。今回はこの取り組みについて紹介します。 はじめに 近年のニューラルネットワークの研究の発展により、画像認識や自然言語処理の様々なタスクを人間と同等もしくはそれ以上のレベルで処理できるようになりました。その結果として、ビジネスでのニューラルネットワークの利用が進んでいます。その一方で、ニューラルネットワークには、モデルの巨大さに起因して処理時間が長いという大きな問題があります。そのため、それらを適切にコントロールすることが、プロダクトでのニューラルネットワークの活用が成功するかどうかの重要な鍵になっています。 一般的には、モデルを学習するときの処理時間の長さが問題とされることが多いですが、これは推論でも大きな問題となり得ます。特にStockmarkでは、BERTと呼ばれる自然言語処理のためのニューラルネットワークを用いて、膨大な数のニュース記事に対して分類や抽出などの推論処理をしており、これにかかる時間の削減がプロダクトでの大きな課題になっています。具体的には、 新規のニュース記事（数万件）に対する日次のバッチ処理 新たなモデルがプロダクトに追加された場合や、アルゴリズムの変更や学習データの追加により既存のモデルが更新された場合に行われる、データベースに保存されている過去のニュース記事（数千万件）に対する全件処理 などの日々のオペレーションでBERTの推論処理を行なっています。そのため、このような大規模なデータに対して効率的に推論処理をするための強力な処理基盤が必要になりました。 StockmarkではこれまでBERTの推論を主にGPUを用いて行なってきましたが、Googleが開発した行列演算などの機械学習の処理に特化したチップであるTPUを用いて、データ処理を効率化する取り組みを最近始めました。そして、新たな処理システムをGoogle Cloud Platform(GCP)上に構築し、日々のオペレーションで運用しています。今回のブログでは、これについてのStockmarkの取り組みについてご紹介します。 Cloud TPUを用いた推論処理基盤 システム概要 ここでは、GCPに構築したBERTの推論処理のためのシステムの概要について紹介します。 GCP上でCloud TPUを用いるためには、まずTPUのノードを別途起動させる必要があります。その後にCompute EngineのインスタンスからTPUにアクセスするような形で、TPU上で計算ができます。 日次のバッチ処理では、ニュース記事をデータベースから取得し、BERTによる推論処理をし、その結果をデータベースに返すという一連の流れが実行されます。このために、以下のようなアーキテクチャーを用いました。 毎日指定された時間になると、Cloud Schedulerが起動し、Pub/Subを通して、Cloud Functionsをトリガーする。 Cloud Functionsはワークフローを管理するためのインスタンスを作成する。 このワークフローを管理するインスタンスが以下のタスクを順次実行する。 Cloud Runを用いてデータベースから処理するニュース記事のデータを取得し、Cloud Storageに保存。 推論処理のためのインスタンスとTPUのノードを作成する。このインスタンスはContainer Registryから取得したコンテナ上でBERTの推論処理をTPUで行い、処理結果をCloud Storageに保存。タスク完了後にインスタンスを削除。 Cloud Runを用いて処理結果をデータベースに返す。 全ての処理が完了後、処理結果をSlackに通知し、自身のインスタンスを削除。 ** 参考までにCloud Runはサーバレスの計算環境でコンテナ上のアプリケーションを実行することができ、自動スケーリングなどにも対応しています。 MLOps 以前、ブログで紹介したようにStockmarkではMLOpsの考えを取り入れたシステム開発を行なっており、今回の開発でもMLOpsの概念に基づき、以下のようにCI/CDをできる限り自動化しました。 GitHubの特定のレポジトリにコードがpushされると、GitHub Actionsを通じて自動的にCloud Storageの特定のバケットにコードがアップロードされる。各インスタンスは起動時に、そこからコードを取得し、タスクを実行する。 Cloud buildを用いたCloud Functions、Cloud Run, Container Registryへのデプロイ。 Cloud Runを用いた全件処理時の工夫 全件処理の際にも、上をベースとしたシステムを用いますが、さらなる処理の高速化を図りました。 数千万件のニュース記事の処理する際には、データの前処理や後処理にも、かなりの時間がかかります。そこでデータ処理のワークフローを(i)形態素解析などのデータの前処理、(ii)BERTによる処理、(iii)後処理の3段階に明確に分離しました。そして、CPUで計算を行うデータの前処理と後処理はCloud Runを用いて最大で100程度のインスタンスを用いて並列しました。Cloud Runはリクエストに応じて自動的にインスタンスが増えるので（自動スケーリング）、多数のインスタンスでの効率的な並列処理が可能になりました。さらにBERTの処理では2つのTPUのノードを用いました。このようにして、処理全体を高速化しました。 Cloud TPU導入の効果 Cloud TPUを導入することで、特に全件処理時のパフォーマンスが著しく向上しました。GPUサーバを用いて処理を行なっていた時には、1週間程度の時間がかかっていましたが、Cloud TPUを用いることにより1日以内に処理を終えることができるようになりました。 以前は、日々のオペレーションの課題は、新規のニュース記事に対する日次のバッチ処理をいかに安定的に行うかということにありました。しかし、最近ではチームの人数の増加やプロダクトの成長により、新しいモデルを開発したり、既存のモデルを改善をする頻度が増えており、この際に発生するデータの全件処理をいかに早く行い、開発サイクルを早く回すかが重要な課題になっています。処理時間が大幅に短縮されたことで、お客様に新しい機能をより迅速に提供できるようになるといった効果が期待されます。 TPUとGPUのパフォーマンス比較 BERTの推論処理を行う上で、TPUがGPUに比べるとどの程度、処理時間やコストを削減できるかについても検証しました。ここでは、ベンチマークとして約50万のニュース記事を用いて、BERTの推論処理にかかる時間とコストをTPUとGPUで比較しました。タスクとしては、文章中から企業名を抽出するタスク（詳しくは過去の記事をご覧ください）を用いました。結果は下のようにまとめられ、TPUを用いるとGPUと比較して処理時間が73%、コストが51%削減することができることがわかり、大規模なデータの処理でのTPUの優位性がわかりました。 ** 学習時のTPUとGPUの性能比較については過去のブログをご覧ください。 TransformersのBERTをTPUで動かす。 今回はTransformersのTensorFlowのBERTを用いました。まず、GPUを用いる場合には、モデルのロードは例えば以下のような感じです。 from transformers import TFBertForTokenClassification model = TFBertForTokenClassification.https://tech.stockmark.co.jp/blog/tpu_vs_gpu_en/Fri, 30 Oct 2020 12:00:24 +0900https://tech.stockmark.co.jp/blog/tpu_vs_gpu_en/Introduction In this era, any machine learning enthusiast who has been trying to catch a good performance by training neural networks on a huge amount of data has struggled with the amount of time that the deep neural network models take for training. In addition, deep learning models are in dire need of hardware resources. Further, it is better to use Graphics Processing Unit (GPUs) instead of Central Processing Unit (CPUs), since they are faster than CPUs for training deep neural networks.https://tech.stockmark.co.jp/blog/tpu_vs_gpu_ja/Fri, 30 Oct 2020 12:00:24 +0900https://tech.stockmark.co.jp/blog/tpu_vs_gpu_ja/はじめに (この記事の英語版はTPU VS GPU(English Edition)にあります。) Machine Learning部門の江間見です。ストックマークでは、自然言語処理技術の研究開発を行っています。 昨今、大規模データでニューラルネットワークを訓練し良い結果を得ようとするならば、深層学習モデルの訓練にかかる時間の膨大さに誰もが悩まされたことがあるかと思います。さらに、深層学習モデルはハードウェアのリソースを多く必要とします。 深層学習モデルの学習では、計算の特性上、CPU（Central Processing Unit）より GPU（Graphics Processing Unit）が高速であるため、GPUが推奨されます。しかし、GPU以外の選択肢として、TPU(Tensor Processing Unit)があります。 そこで、本記事では、自然言語処理のタスクで深層学習モデルの学習におけるTPUとGPUを比較していきます。 Processsing Unitの紹介 GPU GPUは、グラフィック処理や数値計算等で使用される専用メモリを備えた特殊なプロセッサです。GPUは単一処理に特化しており、SIMD（Single Instruction and Multi Data）アーキテクチャ用に設計されています。そのため、GPUは同種の計算を並列に実行(単一の命令で複数のデータを処理)します。 特に深層学習ネットワークでは数百万のパラメータを扱うので、多数の論理コア（演算論理ユニット（ALU）制御ユニットとメモリキャッシュ）を採用しているGPUが重要な役割を果たします。GPUには多数のコアが含まれているため、複数の並列処理を行列計算で高速に計算可能です。 TPU TPUは、Google社から2016年5月、Google I/O（Google社が毎年開催している開発者向けカンファレンス）で発表されました(すでに同社のデータセンター内で1年以上使用されていたとのことです)。 TPUは、ニューラルネットワークや機械学習のタスクに特化して設計されており、2018年からはサードパーティでも利用可能です。 Google社は、Googleストリートビューのテキスト処理にTPUを使用してストリートビューのデータベース内のすべてのテキストを5日間で発見し、Google Photosでは単一のTPUで1日で1億枚以上の写真を処理できたと発表しています。また、同社の機械学習ベースの検索エンジンアルゴリズム「RankBrain」でも、検索結果を提供するためにTPUを利用しています。 TPUは深層学習タスクを高速化するために設計されたコプロセッサです。図1にTPUブロック図を示します。 図1. TPUブロック図 (Jouppi, et al., 2017) データ転送遅延の可能性を削減するために、TPUはCPUと密接に統合するのではなく、PCIe I/O バス上のコプロセッサとして設計されており、GPU と同様にサーバに接続可能です。 また、ハードウェアの設計とデバッグを簡素化するために、ホストサーバがTPUの命令を自身で実行するのではなく、実行するための命令をTPUへ送信します。つまり、TPUはGPUと比較して、FPU（浮動小数点ユニット）コプロセッサに近い考え方を持っています（Jouppi, et al., 2017）。 図1に示すように、右上隅にある黄色の行列演算ユニットがアーキテクチャの主な計算部分と考えられます。一般的に、CPUは1サイクルあたり数十回の操作を、GPUは1サイクルあたり数万回の操作を、最後にTPUは1サイクルあたり最大128000回の操作を行うことができます。 ハードウェアリソース 比較のために、利用したハードウェアは以下の通りです。 TPU/GPU Hardware Memory GPU GeForce RTX 2080 Ti 11GB GDDR6 RAM TPU Cloud TPU v3 128GB タスク 自然言語処理タスクにおけるTPUとGPUの比較のために、以下の2タスクを行いました。 Wikipediaの日本語データによるBERT (Bidirectional Encoder Representations from Transformers)の事前学習 livedoor ニュースコーパスを用いた日本語テキスト分類問題に対する事前学習済みBERTのファインチューニング TPUとGPUの比較 Task 1: BERTの事前学習 TPUとGPUの両方で、日本語のwikipediaデータを用いてBERTの事前学習を行いました。 今回選択したTPUとGPUでは搭載メモリが異なるため、ミニバッチサイズはTPUで256で、GPUで4としました。https://tech.stockmark.co.jp/blog/how_we_succeeded_in_big_rewriting/Tue, 15 Sep 2020 12:00:00 +0900https://tech.stockmark.co.jp/blog/how_we_succeeded_in_big_rewriting/はじめに ストックマークが提供するプロダクトであるAnewsにおいて、ビッグリライトによるフロントエンド・バックエンドの両方を含むアーキテクチャ刷新を成功させました。一般にビッグリライトは、ハイリスク・ハイリターンであり、難易度も高いと言われていますが、大きなトラブルもなく、かつお客様評価も高い状態を実現しています。 Anewsリニューアル後の画面イメージ 本記事では、なぜビッグリライトを選択したのか、何が要因となって成功に至ったのか、といった事項について、開発チームで振り返りした中からいくつかの要因を紹介いたします。 アーキテクチャ刷新の背景 Anewsは、新規Feedを最適化して提供するプロダクトで、2020/8時点では累計1500社のお客様に利用されています。(参考：導入事例) スタートアップのプロダクトでは、顧客の声に耳を傾けながら、大小あるピボットを積み重ねて、洗練されたプロダクトを開発・提供していきます。Anewsも例にもれず、細かな変更の積み重ねを繰り返してきました。幸いなことに多くのお客様に利用いただいておりましたが、より高い価値を提供するためには、プロダクトを大きく変更する必要がでてきました。 そこで、2020/1に大規模なシステムリニューアルを決断しました。 なぜビッグリライトの選択したのか？ 基本的なプロダクトのベース機能は、リニューアル前後で同一です。ベース機能は同一ですが、今回のリニューアルでは、ニュースフィード画面の大きな変更を加えます。 このような状況下でのベースアーキテクチャ刷新の方法には、ビッグリライト・リアーキテクティング・リファクタリングなどいくつかのアプローチがあります。（参考：レガシーソフトウェア改善ガイド） Anewsでは前述の通り、ハイリスク・ハイリターンであるビッグリライトを選択しました。一般に、ビッグリライトは、既存プロダクトと並行開発・運用する必要もあるため、リソース的な制約もあり、難易度があがります。しかし、成功した場合には、顧客向けの提供したい価値の最大化に加えて、これまでの技術的負債の解消も狙えます。 そこで、Anewsではビッグリライトを選択しました。もちろん、単に選択したのではなく、いくつかの工夫を加えることによって、成功確度を戦略的に高めています。以下ではそのアプローチについて紹介いたします。 ビッグリライトの成功確度を上げた工夫 ビッグリライトの成功確率を上げた工夫のうち、代表的なものは次のとおりです。 難易度の高いところから着手・実験する スコープをコントロールする 旧プロダクトのアーキテクチャをベースに、かつデータストアにRedisを使って仮説検証する 本番を見据えてしっかり作るというよりはとにかく動くことを優先して作る 以下でそれぞれを解説します。 難易度の高いところから着手・実験する Anewsの最大の価値は、機械学習から生成するコンテンツ品質です。コンテンツ品質が悪ければ、プロダクト価値は非常に低下します。 今回のリニューアルでは、機械学習のモデル作り直しをスコープに入れており、かつその作成難易度は非常に高いものでした。仮にモデル作成と、同時並行で他の開発も進めて、モデル作成で失敗してしまうと、並行開発分が無駄になる可能性があります。 そのため、まずは難易度の高いモデル作成の部分に開発リソースを投下して検証しました。結果的に、非常に高いレベルのMLエンジニアの力もあり、検証で良い結果が出たため、サンクコストが大きくなるリスクを最小限に抑えて開発をすすめることができました。 スコープをコントロールする システム開発における概念に、鉄の三角形という概念があります。鉄の三角形では、Scope/Time/Costの三要素のうち2つまでを固定可能です。 Anewsの開発チームは、開発プロセスとしてアジャイル開発を採用しており、上記三要素のうちScopeのコントロールによって、開発チームに負荷のかかりすぎない開発をすすめることができました。（負荷がかかりすぎると、バーンアウトしてしまう） 旧プロダクトのアーキテクチャをベースに、かつデータストアにRedisを使って仮説検証する 開発をミニマムに抑えた状態でユーザ検証することで、迅速なフィードバックサイクルを実現できます。もし、アーキテクチャを細部まで作り込んだあとに、ユーザ検証で価値がないことがわかると、サンクコストが発生します。そのため、いかにシステムを作らずに、価値検証するかが重要となります。 Anewsのリニューアルにおいて、作り込みすぎないという点で工夫した点は、旧プロダクトのアーキテクチャをベースにしつつ、データストアにRedisのみを用いた点です。 従来、Webアプリケーションを作る場合にはRDBを用いるのが基本的なパターンかと思います。RDBはACID属性を持っており、堅牢なデータストアとして利用可能です。しかし、ちょっとしたデータ構造の変更を加えようとすると、テーブル定義を変更する必要があります1。 そこで、今回はRedisのみをデータストアとして利用しています。RedisはシンプルはKVSを提供しており、かつスキーマを容易に変更できるため、ちょっとした変更にも柔軟に対応できます。また、今回は、データ永続化の要件などもないため、AOFなどの設定も不要です。 結果的に、Redisを利用したプロトタイプでユーザ価値を検証できました。続いて、RDBも利用する本格的な開発へ進んでいきます。 本番を見据えてしっかり作るというよりはとにかく動くことを優先して作る 前述のRedisをメインデータストアとしたプロトタイプは、本番を見据えてしっかり作るのではなく、とにかく動くことを優先して開発を進めました。データストアとしてRedis単体をそのまま使う想定ではありませんでしたが、本番でも使える部分は使う、ぐらいの想定です。 システム開発において、一度目からクリーンな設計ができるわけではなく、実際にコードをある程度書き進めてから、課題などに気づくことは多くあります。実際に今回のリニューアルにおいても気づきが多く、本番向けの開発ではより洗練された設計・実装を実現しています。 また副次的な効果として、チームにいるエンジニアの成長につながっています。捨てるつもりのプロトタイプとはいえ、0からシステムをチームで作り上げる経験、また得意でない分野にもチャレンジできる機会が得られるためです。次の画像は、実際にRetrospectiveで上がった声です。 その他の成功要因 ここまでは、開発プロセスにおいて工夫した点を述べてきました。開発プロセスにおける要因以外で、成功に寄与した最大の要因は人だったと思います。 運の良かったことに、スキルが高く開発経験の多いメンバもストックマークにJoinしてくれています。このようなチームメンバに恵まれたからこそ、ビッグリライトが成功できたと考えております。 上手くいかなかったこと ここまでの記事で、全てが上手くいったように見えておりますが、もちろんそんなことはなく、課題も多くありました。一例を紹介すると、 コロナでフルリモートになった時期だったので、コミュニケーションが難しかった 新しいアーキテクチャで作ったこともあり見積もりが難しく、実際にかかった工数と乖離してしまった スコープ調整を行うのが遅く、着手したが結局リリースに含めなかった機能もあった といった内容になります。この辺りは、今後の開発に向けて課題として解決していきます。 さいごに ストックマークでは、スキルの高い開発チームで一緒に働いてみたい方を募集しております。Wantedlyに募集職種を載せておりますので、ぜひご覧いただいてまずはカジュアル面談からでもお話しましょう！ JSON型などを利用する場合は、この限りではないです。 ↩︎https://tech.stockmark.co.jp/blog/security_efforts/Thu, 03 Sep 2020 12:00:00 +0900https://tech.stockmark.co.jp/blog/security_efforts/こんにちは、ストックマークでSREを担当している松下です。 ストックマークでは企業向けの情報収集・企業分析・営業支援サービス(Anews, Astrategy, Asales)を運営しており、導入を検討されているお客様よりセキュリティの取り組みに関してお問い合わせをいただくことが多々あります。 お客様のセキュリティ基準をプロダクトが満たせるかどうかは、ストックマークにとっても最重要課題であり、ストックマークのセキュリティ向上への姿勢をより分かりやすく示すために、8月にはISMS認証を取得しました。 今回はISMS認証取得を記念して、私が担当しているAsalesを例にしながら、これまでにストックマークが行ってきたセキュリティ対策の一部をざっくりとご紹介させていただこうと思います。 Asalesについて Asalesはセールスなどの提案資料や社内資料を自然言語処理技術で学習・解析し、売上拡大のために必要な社内ナレッジを共有・レコメンドする営業支援サービスです。 蓄積された提案書を"言葉のAI"が解析することで、提案経験のある社内エキスパートを見つけ出せたり、顧客に響く提案を作成するヒントを得る機会を創出します。 図1: Asalesの機能 提案資料の作成をイメージして「Asalesを利用する流れ」を簡単にご説明すると、 エンドユーザーはAsalesに提案資料や社内資料をアップロードする。 アップロードされたファイルは機械学習処理により学習・解析され、その結果が保存される。 エンドユーザーがAsalesからキーワードや作成者、商材、業界などを指定して検索を行うと、保存された学習・解析結果から最適なスライドを探し当てることができる。 となりますが、Asalesを利用して作成した資料をAsalesにアップロードして、それがまた誰かの役に立って新しい資料がAsalesにアップロードされて、というサイクルが続けば、学習・解析の効果がより高まって「セールスの永久機関になり得るな」と考えたりしています。 セキュリティ対策の検討ポイント そんなAsalesですが、お客様から「クラウドにアップロードしたデータに第三者がアクセスできない仕組みがあるか」というお問い合わせをよくいただきます。 お問い合わせをいただく中には施設・設備などへの物理的なアクセスを含んでいることがありますが、こちらはAsalesでクラウド基盤として利用するAWSの責任共有モデルという考え方に則って、AWSが行っている対策などを確認して回答しています。 図2: AWSの責任共有モデル AWSがクラウドのセキュリティに責任を持つのに対して、Asalesはデータの保護や仮想ネットワーク、ミドルウェアの設定・管理など、クラウド内のセキュリティに責任を持って対応しています。 下記のアーキテクチャ図はAsalesのアーキテクチャを5つの層に分けたものですが、「Asalesを利用する流れ」を当てはめてデータ保護の観点からセキュリティ対策の検討ポイント考えるのに利用しました。 図3: セキュリティ対策の検討ポイント アップロード (1) エンドユーザーはAWS Elastic Beanstalkで構築したWebサーバーにアクセスし、 (2) 提案資料や社内資料をAWS S3にアップロードする。 学習・解析 (3) アップロードされたファイルはAWS Batchで構築した機械学習処理により学習・解析され、 (4) その結果がAmazon RDS、Amazon Elasticsearch Serviceに保存される。 スライド検索 (5) エンドユーザーがAsalesからキーワードや作成者、商材、業界などを指定して検索を行うと、 (6) 保存された学習・解析結果から最適なスライドを探し当てることができる。 対応したセキュリティ対策の一例 上記の検討ポイントに対して行った、セキュリティ対策の一例をご紹介します。 ネットワーク アクセス制御（IPアドレス制限） 企業向けのサービスとして接続元を限定できる手段を検討しました。AWS Elastic Beanstalkの前に置いたAmazon CloudFrontに、AWS WAFを紐付けることでIPアドレスの制限を可能とし、SaaSのメリットとセキュリティ性を両立しています。 通信暗号化 AWS Certificate ManagerにてSSL/TLS証明書を発行して通信を暗号化してます。 ウェブ・アプリケーション アクセス制御（SAML認証） ウェブ・アプリケーションの認証はアプリケーションロジックで対応していましたが、SSOに対応するため、Amazon Cognitoを導入してSAML認証に対応しました。SSO非対応のお客様も認証機能はAmazon Cognitoに集約していますが、認可機能は細やかな対応を可能とするため、引き続きアプリケーションロジックで対応しています。 Webサーバーのウイルスチェック オープンソース（GPL）のアンチウイルスソフトウェアであるClam AntiVirusをインストールしたカスタムAMIを用意し、ウイルス定義ファイルの更新とウイルスチェックを日次起動する設定を行ってAWS Elastic Beanstalkにて利用しています。https://tech.stockmark.co.jp/blog/202007_company_entities_recognition/Wed, 15 Jul 2020 12:00:00 +0900https://tech.stockmark.co.jp/blog/202007_company_entities_recognition/はじめに Machine Learning部門の近江です。ストックマークでは、自然言語処理技術の研究開発を行っています。 先日、弊社のTech Blogにて弊社が公開している言語モデルを紹介しました。 ストックマークが公開した言語モデルの一覧と振り返り 今回は、言語モデルがプロダクトにおいて実際にどのように利用されているかについての一例を紹介します。 ニュース記事の構造化 マーケティング、新規事業開発などの調査業務では、調査を行う人が書籍、ニュース記事、ホームページなどの情報を網羅的に調べ、整理し、報告書などにまとめていきます。その際に扱う情報は膨大であり、そのため調査業務には多くの時間と労力がかかります。 弊社のプロダクトである「Astrategy」は機械学習を用いてニュース記事から特徴となる情報を抽出し、構造化することで、大量のニュース記事を効率的に俯瞰し、さらに新規事業開発などに繋がりうる情報の発見を促進することを目的としたものです。 Astrategyではニュース記事の構造化の一つとして、ニュース記事に現れる企業の名称を抜き出すということを行っています。これは、市場調査において市場にどのようなプレイヤー（企業）が存在するのかという情報は、非常に重要であるからです。今回は、この「ニュース記事からの企業名抽出」を例にして、言語モデルを用いた機械学習についての弊社の取り組みを紹介します。 企業名抽出の難しさ 機械学習でニュース記事から企業名を抽出すると聞いて、多くの人は「これは簡単なタスクだ」と思うのではないでしょうか？このタスクは人間にとっては非常に簡単です。しかしながら、以下でわかるように、これをコンピュータにやらせるのは意外と難しいものです。 企業名をテキストから抽出する最も単純なアプローチは、企業名を集めた辞書を用意しておき、辞書に含まれている企業名が文章中に含まれていれば、それを企業名と見なすというものです（辞書方式）。企業名の辞書としては、国税庁が公開している日本に存在する全ての法人を登録したデータベース（https://www.houjin-bangou.nta.go.jp/）があります。これを用いて、実際に次の文章に対して辞書方式の企業名抽出をしてみましょう。 「ストックマーク株式会社では現在、エンジニアを募集しています。」 これを見た時、多くの人は「ストックマーク株式会社」が企業名であり、それ以外に企業名は含まれていないということは簡単に分かるでしょう。しかし、実際に辞書方式を用いると、 「ストックマーク株式会社」、「エンジニア」、「集」、「てい」、「ます」 の5つが抜き出されます。「ストックマーク株式会社」は正しく抽出されている一方で、「エンジニア」、「集」、「てい」、「ます」のように、このような名前の企業は実際には存在するものの、この文章では企業名ではない文字列まで誤って抽出してしまっていることがわかります。これは企業名として、ありとあらゆる言葉が使われているため、文章中の企業名以外の文字列が辞書に存在する企業名に意図せず一致してしまうことで起こります。このように、辞書方式だと企業名を正しく抽出できる場合もある一方で、人には企業名ではないと容易に判断できる文字列まで誤って抽出してしまい、結果としてうまくいきません。 また別の例ですと、米IT企業のAppleの動向を追いたい人が、企業名の「Apple」が含まれている記事を集めるとします。この時に各記事から辞書方式で「Apple」を抽出した記事を集めてくると、「Apple」が食べ物のりんごの意味で使われている記事まで含まれてしまい、全く関係のない記事まで含まれるというような問題も起こってしまいます。 さらに、辞書方式の別の欠点として、辞書に存在していない未知の企業は原理的に検出できないという問題もあります。しかしながら、まだあまり知られていないスタートアップ企業などの動向を認知することはビジネス上とても重要であり、未知の企業名を正しく抽出することは重要な課題です。 辞書方式に形態素解析やパターンマッチングを組み合わすことで幾分精度は向上するでしょうが、様々な文脈や表記の揺らぎなど多様な状況に網羅的に対応できるようになることは期待できません。 機械学習を用いた企業名抽出 辞書方式の問題は与えられた文字列のみから、それが企業名かどうかを判断する点です。それに対して、人は文脈（周辺の単語）に基づいて、それぞれの文字列が企業名かどうかを判断しています。コンピュータに文脈を読ませることは最近まで非常に難しい問題でしたが、近年、機械学習を用いて文脈を考慮する手法の研究が大きく進みました。機械学習を用いて企業名抽出を行う場合には、事前に文章と、文章中のどの箇所が企業名なのかをラベル付けした大量のデータをまず用意します。そしてその学習データを用いて、パターンをモデルに学習させることで、企業名抽出モデルを構築します。 一般に、文章に現れる人名、組織名、地名などの「固有名詞」を抜き出し、分類する問題は「固有表現抽出」と呼ばれています。Googleは汎用の固有表現抽出を行うためのAPIを有料で提供しており、デモは無料で試すこともできます。 https://cloud.google.com/natural-language?hl=ja#natural-language-api-demo このGoogleのAPIを用いて、先ほどの「ストックマーク株式会社では現在、エンジニアを募集しています。」という文章を解析してみると、めでたく「ストックマーク株式会社」のみが組織名として抽出されました。（下図） BERTを用いた企業名抽出に関する私たちの取り組み 今回、私たちはGoogleのAPIのような汎用の固有表現抽出エンジンではなく、企業名抽出に特化した機械学習モデルの開発を行うことで、企業名抽出を高い性能で行えるようにすることを目指しました。 私たちが用いた言語モデルは汎用モデルの「BERT」です（原論文：BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding）。ここではBERTについては詳しくは説明しませんので、詳しく知りたい方は、自然言語処理の王様「BERT」の論文を徹底解説、「イラスト付き解説」BERTとELMo等（NLPはどうやって転移学習を突破できたのか）などを参考にしてください。 BERTを用いた文章の解析では、まず文章をトークンと呼ばれる文字列の単位に分割します。例えば「ストックマーク株式会社では現在、エンジニアを募集しています。」をトークンに分けると 「ストック」, 「マーク」, 「株式会社」, 「で」, 「は」, 「現在」, 「、」, 「エンジニア」, 「を」, 「募集」, 「し」, 「て」, 「い」, 「ます」, 「。」 のように分割されます。BERTはトークンの列を入力として与えると、それぞれのトークンを他のトークンを考慮して何らかの数値ベクトルに変換するようなモデルだと思ってください。図で表すと以下のようになります。（簡単のため[CLS], [SEP]などの特殊トークンは除いています。 ） 次にBERTを用いて、どのように企業名抽出を行うかを説明します。このための方法としては色々なやり方が考えられますが、ここでは単純に以下のような方法を用いました。それぞれのトークンに対するBERTの出力（ベクトル）に「0」または「1」のラベルを出力する識別器を新たに付けます。ここでラベルが「1」のトークンは企業名に含まれており、ラベルが「0」のトークンは企業名には含まれていないことを表すことにします。そして、ラベルが連続して「1」であるトークンをひとまとまりとして、それを1つの企業名として扱います。下の図の例では、「ストック」, 「マーク」, 「株式会社」の連続する3つのトークンのラベルが「1」になっているので、それを連結した「ストックマーク株式会社」が企業名として抽出されます。 実際には、BERTは最初から企業名を正しく抽出できるわけではありません。 そのため、BERTが正しく企業名を抽出できるようにするために、BERTの学習（Fine-tuning）を行います。 BERTを学習させるために、まず大量の文章に対して、企業名のトークンを「1」、それ以外のトークンを「0」とラベル付けした学習データを用意します（次節参照）。 そして、学習データをもとにBERTができるだけ正確にラベルを出力できるように、つまり企業名のトークンに対して「1」をそれ以外のトークンに対しては「0」を出力するように、モデルのパラメータを更新していきます。 学習が進むにつれて、BERTは正しくラベルを出力できるようになり、正しく企業名を抽出できるようになります。 この学習が終われば、企業名抽出モデルの完成です。 今回は下の4つの例を試してみたいと思います。 文章例 1 ストックマーク株式会社 では現在、エンジニアを募集しています。 2 ことし10月を予定していた、ヤフー とLINE の経営統合が遅れる見通しになりました。 3 クーマクットス では現在、エンジニアを募集しています。 4 ことし10月を予定していた、アハハハハ とENIL の経営統合が遅れる見通しになりました。 それぞれ太字が企業名を表しています。2番目の例は実際のニュース記事(出典：NHK NEWS WEB)を用いた例です。3と4番目の例は未知の企業名に対しても文脈から判断して正しく抽出して欲しいという要請から、それぞれ1と2番目の例から企業名を架空の企業名に置き換え、さらに「株式会社」という分かりやすい企業名の目印がない状況でも対応できるかを調べるために、「株式会社」を取り除きました。https://tech.stockmark.co.jp/blog/aws_denshosen_aiboke/Thu, 02 Jul 2020 00:00:00 +0900https://tech.stockmark.co.jp/blog/aws_denshosen_aiboke/こんにちは、ストックマークでPR担当している中野です。 AIに人は笑わせられるのか…。 9月開催の「AWS Summit」で行われる 「電笑戦 ~ AI は人を笑わせられるのか ?」の挑戦者 として、当社のAIが出場します！ 1枚の画像に対して一言コメントでボケて、笑いを取るコンテンツです。 「AWS Summit」の開催に先駆けて、画像に対してAIがボケてる様子を記事にして頂きました！ 弊社 森長が、技術解説とともに、実際にAIが繰り出すボケをいくつか紹介します！ぜひチェックしてみてください。 9月8日(火)～9月30日(水)に開催される「AWS Summit Online」の本番もご期待ください！ 記事掲載：AWSウェブマガジン「builders.flash」　電笑戦 ~ AIは人を笑わせられるのか 第 2 回　電笑戦の背景と挑戦者https://tech.stockmark.co.jp/blog/list_of_the_published_learning_models/Fri, 26 Jun 2020 12:00:24 +0900https://tech.stockmark.co.jp/blog/list_of_the_published_learning_models/こんにちは、Machine Learning部門の森長と申します。 Machine Learning部門は、プロダクト適用を目指した基礎研究&基礎研究のプロダクト適用の二軸を担当しています。基礎研究では、言語モデルの作成、文章のカテゴリ分類・クラスタリング、要約の検証等、プロダクトへの適用を見据えて研究テーマを設定しています。また、自然言語処理の盛り上がりに少しでも貢献できればと考え、言語モデルの公開を行っていますので、もしよろしければ使ってみてください。 今回は、弊社で公開している言語モデルについて書いていきます。 言語モデルとは 言語モデルにも色々な種類のモデルがあり、一口でこれというのは難しいですが、簡単に言うとすると、「単語列に対して確率を計算するモデル」です。 厳密には各言語モデルで目的が違うため、呼称が少しずつ異なりますが、本投稿では言語モデルという表現で統一させていただきます。 言語モデルを利用することで、例えば、文章の生成や単語の意味的な近さの計算を行えます。 弊社では、これらの言語モデルを組み合せることで、ビジネス文章の解析・構造化(文の分類やクラスタリング、企業名抽出等)を行っています。 弊社で公開している言語モデル一覧 弊社では、Qiitaで紹介記事を書き、以下の言語モデルを公開しています。 言語モデル Qiita公開リンク ELMo 大規模日本語ビジネスニュースコーパスを学習したELMo（MeCab利用）モデルの紹介 BERT 大規模日本語ビジネスニュースコーパスを学習したBERT事前学習済（MeCab利用）モデルの紹介 XLNet 大規模日本語ビジネスニュースコーパスを学習したXLNet（MeCab+Sentencepiece利用）モデルの紹介 ALBERT 大規模日本語ビジネスニュースコーパスを学習したALBERT（MeCab+Sentencepiece利用）モデルの紹介 公開している学習モデルの詳しい説明はQiita記事を参照いただければと思います。 今回はせっかくなので、言語モデル作成当時の経緯等を順に振り返ります。 ELMo 2018年11月某日.. 森長：「記事の分類の分類タスクの精度向上が頭打ちになってきた。。。記事中の「ライオン」という文字列が「企業のライオン」さんなのか「大西ライオン」さんなのか「百獣の王のライオン」さんなのか分からない。日本語が分からなくなってきた。。」 CTO有馬：「半年前に発表されたELMoを使うと文脈に応じた単語ベクトルを生成できるようだ。」 森長:「それだ!」 という会話のように、ビジネスニュースにおける日本語の語義曖昧性に悩まされていました。 弊社では「記事データの情報源自体の絞り込み」や「個人の嗜好に近い文章ベクトルによる絞り込み」等を行い、プロダクト側で語義曖昧性を解消していました。 ですが、個人の嗜好等によらず記事を構造化することを考えると、人と同様に文脈から語義を判断させる必要があります(人は文脈と自身の知識・常識を使って語義を判断していますが)。 そこで、文脈に応じた単語ベクトルを生成できるというELMoに着目しました。 ELMoとは ELMoは双方向LSTMを用いて学習させた言語モデルです。 ELMoによって、文脈を考慮した単語分散表現(単語ベクトル)を生成可能です。 例えば、以下の「人気」という単語のように、文脈によって意味が異なる単語でも、ELMoでは文脈を考慮して文脈ごとの「人気」の単語ベクトルを生成可能です。 あのキャラクターは人気がある。 この道路は、夜に人気がなくて、危ない。 ELMoの単語ベクトルの具体的な利用方法としては、ELMoで生成した単語ベクトルをfastText等の他の手法で生成した単語ベクトルと連結し、その単語ベクトルを用いてタスクを解くことで、精度の向上が見込めます。 ELMo日本語モデルの作成 2018年末頃に調査した範囲では、実用できそうなELMoの日本語モデルが公開されていませんでした(語彙の漢字に日本外の漢字が含まれる日本語モデルは存在※1)ので、弊社で作成することにしました。 ※1 現在(2020/6)はAllenNLPでの公開や日本語モデルを学習して公開されている方々がいらっしゃいます。 作成には、AllenNLP(オープンソースの研究用ライブラリ)を継承した以下のコードをベースに作成しました。 https://github.com/HIT-SCIR/ELMoForManyLangs さっそく、ビジネスニュース40万記事を教師データとして、学習してみたところ、CPU処理ではいつまでたっても終わらない。。。 今まで言語モデル(主にfastTextのモデル)を作成する際は、CPUのみで作成していましたが、この時からGPUを使って言語モデルを作成するようになりました。 ELMoの効果 弊社は、ELMoの日本語言語モデルを作成することで、文脈に応じて単語ベクトルを生成する武器を手に入れました。 と言ってもこの武器を使いこなすのがまたまた難しく、試行錯誤し、以下のような対応で、ELMoを用いてタスクの精度向上を実現しました。 文脈から単語ベクトルを生成するため、生成に時間がかかる GPUを使用 単語ベクトルの次元数が1024次元あるため、演算に時間がかかる(fastTextの単語ベクトルの次元数は100-300程度) GPUを使用 同じ単語を同じ意味で使用していても、文脈に応じて単語分散表現が変わる 他の手法で獲得した単語ベクトルにELMoの単語ベクトルをconcatして使う(ELMoの論文で示されている本来の使い方) 学習の実行時の制約上(tokenサイズを固定)、隠れ層の出力結果を記憶するため、同じテキストを入力しても、単語ベクトルが異なる。(参考リンク) ここに記載があるように、同一ELMoインスタンスを必ず使い、最初に数回空回しすることで、単語ベクトルを安定させる この時からBERTの日本語モデルを作成するまでは、弊社の分類タスクにおいて、「fastText + ELMo + Attention」の組み合わせがベースラインになりました。 BERT 2018年12月某日.. 森長：「ELMoのモデル作成には、GPU使っても時間かかるなぁ。GPUの並列化等、検討しないと。」 CTO有馬：「話は変わるけど、ELMoが終わったら、transformerを調査して、BERTにトライしよう。GPUでも学習がなかなか終わらないらしいけど。」 森長:「うん…(白目)」 2018年10月頃から話題になっていたBERTですが、2018年11月頃にGoogle社から言語モデル(正確には事前学習済モデル)が公開されました。 当時は英語モデル、中国モデル、マルチリンガルモデルが公開されていました。https://tech.stockmark.co.jp/blog/mlops/Mon, 01 Jun 2020 06:00:00 +0900https://tech.stockmark.co.jp/blog/mlops/こんにちは、Development部門に所属しているSREの佐藤と申します。 Development部門では複数プロダクト共通の基盤構築や、新技術の検証、インフラ整備などを幅広く担当しています。これまでストックマークではCI/CD基盤の構築やAWS上で構築するインフラのコード化、ニュース収集基盤のアーキテクチャの改善や運用負荷軽減から、製品利用状況のデータ分析基盤構築などに取り組んできました。 今日はAstrategyという製品でのMLOpsの取り組みについて話します。 Astrategyについて Astrategyは国内外Webメディアを対象として情報を収集・構造化し、調査・報告業務を包括的にサポートする検索プラットフォームです。 図1: 「言葉のAI」自然言語解析を用いたオープンデータ解析ツール 複数の分析画面を提供しており、目的に応じて異なる観点で市場変化や競合動向を可視化できます。 図2: Astrategyの分析画面 人力では約50~100記事（期間:1カ月）の調査が限界ですが、Astrategyを利用することで約5,000記事を俯瞰し構造化することでこれまでにたどりつけなかった情報の調査が可能になります。 図3: Astrategyが提供する価値とは Astrategyのシステム構成 以下がAstrategyのシステム構成です。 ユーザーがアクセスした時に動作する「オンライン処理」システムと、夜間や早朝にオンライン処理から参照するデータ生成する「バッチ処理」システムで構成されています。 図4 Astrategyのシステム構成 今日私が話すのは機械学習バッチ処理（以降MLバッチ処理）システムのMLOps取り組みについてです。 MLバッチ処理 Astrategyのバッチ処理では、弊社の独自クローラーが約3万メディアから収集した1日約30万件、合計約2000万件のニュース記事を、「業界」、「地域」などの分類、「企業名の抽出」など10種類の機械学習ジョブで推論を行い、記事にラベル付けをします。 図5: バッチ処理概要 ラベル付けされた記事データは検索サーバー (Elasticsearch)のインデックスに登録され、アプリケーションの各分析画面 (図2)から呼び出されます。 MLモデルについて バッチ処理ではBERTを応用して作成したMLモデルを各タスク用にチューニングしたものを使っています。モデルの開発については本記事のスコープ対象外としますが、興味がある方は弊社森長が大規模ニュースコーパスで事前学習させたモデルを公開しているので、そちらを参照いただければと思います。 MLOpsとは MLOpsの定義はGoogle社のドキュメントがわかりやすいかと思います。 以下は日本語翻訳記事からの引用です。 MLOpsは、MLシステム開発（Dev）とMLシステムオペレーション（Ops）を統合することを目的としたMLエンジニアリングの文化と実践です。MLOpsを実践するということは、統合、テスト、リリース、デプロイ、インフラストラクチャ管理を含む、MLシステム構築のすべてのステップで自動化とモニタリングを提唱することを意味します。 要はDevOpsのML版といった感じです。MLシステムは構成要素が多く、通常のソフトウェア開発に加えて特有の難しさがあり、技術的負債が蓄積しやすいことなどがHidden Technical Debt in Machine Learning Systemsで説明されています。 図6: MLシステムの構成要素 Hidden Technical Debt in Machine Learning Systemsから転載. また、What is ML Ops? Best Practices for DevOps for ML (Cloud Next ‘18)では、複雑なMLシステム開発・運用を1人できる人（ML superhero）に任せてしまうスケールしなくなるため、アンチパターンとして紹介されています。 図7: ML superhero What is ML Ops? Best Practices for DevOps for ML (Cloud Next '18)から転載.https://tech.stockmark.co.jp/blog/blogstart/Mon, 01 Jun 2020 00:00:00 +0900https://tech.stockmark.co.jp/blog/blogstart/こんにちは、ストックマーク CTO有馬です。 この度、テックブログをはじめることにしました。 創業してからあっという間に3年半が経ち、Anewsに至ってはおかげさまで1500社様に活用いただけるような大きなAI SaaSプロダクトにまで成長しました。 AIという高次元でハイカロリーな計算処理をSaaS内で実用化し顧客価値につなげるには、不断の学習と成長痛が伴います。 サービス立ち上げ当初は、精度がなかなか出ず赤子のような出力になったり、急増するユーザ数にアーキテクチャが追いつかず復旧のために3日間徹夜してしまったり、深夜にAIが暴走していて朝起きたら100万円規模のサーバー費課金をくらったり・・・ ただ、やればやるほど、これまでのITにはない価値と興奮をAIは創出できるという手応えを感じるようになりました。 創業時点からは考えもつかなかったほどの優秀なメンバーが集まり、予想の斜め上を行くような技術知見が多く集まるようになりました。社内だけにとどめておくのは勿体無いと感じ、公開したいと思うに至りました。 隔週程度を目標に、投稿していきたいと思いますので、よろしければ読んでいただければと思います。 よろしくお願い致します。