2023年の4月から、プロダクト開発チームのEMを務めている岩谷です。本記事では、当時プロダクトエンジニア13人中3人の退職が重なる中々しびれる状況から、エンゲージメントや開発品質の改善に向き合い、怒涛の半年間が過ぎ、現在21人の組織になるまでに取り組んできたことや学びについてご紹介できればと思います。事業背景 2023年3月以前、以下のような組織体制で、私はML Engineering / MLOpsを推進する基盤チームのEMを勤めておりました。プロダクト開発チームは、いわゆるマトリクス組織で、３つの職能横断のフィーチャーチームを構成し１つのAnewsというプロダクトを開発していました。エンジニアは全体でEMが1名、チームごとにエンジニアのリーダーがおり、開発の運用方法は全て各チームに委ねられている状態でした。そんな中、EM1名、リーダー１名、エンジニア1名が新しいチャレンジの場を求める形で、3~4月の間に退職が重なってしまいました。退職理由は、全員と深く話せたわけではありませんが、例えば社員ではなく個人として社会で自律していきたいなど、真剣に自身に合った生き方やキャリアを考えて下した結論でした。私としては一定仕方の無いことと捉えていましたが、事象だけを見るとネガティブに捉えられる可能性もあり、残されたメンバーは役割の穴埋めだけでなく、精神的な部分のフォローアップも重要であったと思います。私は過去にAnewsの開発チームでチームリーダー・テックリードを担っていた時期もあり、マネジメント職の中では、メンバー・システムの両面で解像度を最も高く持っていたため、プロダクト開発チームのEMを兼務し本イシューに取り組むことになりました。これまではプレイングマネージャーとしての仕事がメインであり、チームから一歩離れた立場で開発チームに関わっていくというのは初めての経験だったため、本当にできるのか不安はありました。ただ、客観的に見ても自身が適任者だと思い使命感を感じていたことと、自身のキャリアを広げるチャンスとも捉えており、当時はポジティブな気持ちで走り出していたと思います。やったこと 責務・課題の把握責務・課題の把握を進めるにあたり、まず、コアとなる役割が抜けたことから、主要なステークホルダから複数の視点での情報を得て、責務の棚卸しが必要があると考えました。加え、人間関係的な問

はじめに この記事では、私たちが開発している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'; 本格的に移行プロジェクト

エンジニアリングユニットの酒井といいます。 昨年の9月に入社し、Anewsの開発に従事しつつ時々SREっぽいこともしています。 今回は、自分が入社当初から改善したいなぁと考えていたAnewsのドキュメントについて、これまでやってきた取り組みについてお話しできればと思います。取り組みを始めたきっかけ そもそも自分は組織開発において、ドキュメントが重要だという認識がありました。それはこれまでの経験則によるところもありますし、『Googleのソフトウェアエンジニアリング』中で以下のような言及があり、重要性を再認識したというのもあります。10.2 何故ドキュメンテーションが必要なのか p220: ドキュメンテーションは長期的に見ると決定的に重要であり、決定的に重要なコードにとっては特に、組織がスケールするのに伴い途方もない恩恵をもたらす。 テストを書くことは普通になりつつありますが、ドキュメントに関してはまだまだな印象が個人的にはあります。書籍では以下のように言及されており、テストと比べると優先順位が下がってしまうのが理解いただけるのではないでしょうか。10.2 何故ドキュメンテーションが必要なのか p218: ドキュメンテーションの恩恵は全て下流で生じるため、ドキュメンテーションの作者は通常、直に恩恵にあずかれるわけではない。[…]すぐにプログラマーの利益になるテストと違い、ドキュメンテーションは通常、より多くの労力が前もって必要で、後になるまで作者に明確な利益をもたらさない。しかしテストへの投資同様に、ドキュメンテーションに行われる投資は、長期的には回収できる。 またStockmark内部の話でいうと、比較的短いスパンで組織の動きが発生しており（ちなみに自分はこれまで4チームに在籍していました）、他方エンジニアも徐々に増えてきていました。それもあって、そう遠くないうちにドキュメントの重要性が高くなるなと自分は考えていました。 また元々Anewsの開発においては、PRDは作成されており、エンジニアが設計書を書くこともそれなりに行われていました。オンボーディング時も丁寧にフォローしていただいて困ったことはなかったのですが、開発を進めていくにつれて、欲しい情報にアクセスしにくいと感じることが徐々に増えてきていることに気づきました。こういった状況もあり、まずは自分だけでちょっと

こんにちは、エンジニアリングユニットの飯森です。先日、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月を最後に更新が止まっており、長期的に使用するには不安がありました。 このため、バッチ処理のテストフレームワークを刷新することが改善施策として挙げられていました。改善施策のプランニング 次に、ストックマークにおける改善施策のプランニングについて説明します。ここでの「改善施

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 英語のデータセ

ストックマークで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ユーザーとして手放せないサービスになっています。）しかし、個人のニー

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のスナップショットを用いました。評価 ビジネスに関連した知識 今回開発したモデルが実際にビジネスのドメインに関連した知識を獲得しているかどうかを

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 はテキストで言及されている概念間の関係を推定するタスクです。 例えば以下のニュース文を考えてみます。トヨタでは新たな生産方式によって部品点数の大幅な削減を図ることができ、生産

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をいくつか教えてください。」 当社のモデル

こんにちは、エンジニアリングユニットの岩谷と申します。今回はエンジニア組織と、採用の観点について記載していきたいと考えています。動機は２つあり、選考プロセスを進めた上で組織・人の面を見て魅力的に感じていただけることが多く、選考前の方にもしっかり発信していきたい 文面だけでは見えないカルチャーやマインド面での相互不一致を減らしたい 何かしらのきっかけでストックマークにご興味を持っていただいた方（まだ興味がない方も！）には、是非１度読んでいただけると幸いです。組織の特徴（仕組みの面） 現在20名ほどのエンジニアが所属しており、プロダクト開発２チーム、ML処理基盤、オープンデータ、SREの５チームにわかれています。プロダクト開発チームはPdM・Designerとの一体チームで運用しており、チーム内の運用方法は各チームに委任されていますが、スクラムに近い運用で、KPTAなどしながらチームの運用自体も自己改善していくようにしています。開発内容の流れとしては、PdM・BizDevを中心に作成する大枠のロードマップと、エンジニアが主体的に計画する改善施策の２つがメインで、これらを具体的にどのように進めていくかはPdM・Engineer間で定期的にすり合わせを行い決めていきます。 よくある「改善施策」と「新規開発」の優先度問題は割り切りで考えており、エンジニア全体の２、３割を目安に改善活動にリソースを当て続ける大方針を置いており、改善稼働は確保する前提で新規開発の計画も調整をしていきます。エンジニア内でのタスク分担については、得意スキルと伸ばしたい領域を考慮した上で、専門領域は決めずにチーム内で調整して新しいことにもチャレンジできるようにしています。これは本人のためもありますが、マルチスタックなエンジニアが増えることが組織全体の生産性を上げることに繋がると考えているからです。（最近Joinしたメンバーの入社前後ギャップとして、「マルチスタックに開発に携われるという点は、想像以上に徹底されていてびっくりした」という声もあったので、客観的にもちゃんと運用できていると思います笑）組織の特徴（文化面） 現在エンジニアリングユニットのバリュー制定を進めており、その中で全エンジニアから声を集めました。全体を俯瞰する中で見えてきた組織の文化について記載していきます。顧客・プロダクト志向研究日（月

はじめに どのスタートアップ企業でも、プロダクトリリースサイクルの高速化・最適化を心がけているかと思います。本記事では、ストックマークのプロダクトである Anews の新機能（論文配信）を例にとって、ストックマークの開発の実際について紹介いたします。本記事から学べる点は大きく 3 点です。高速な価値提供を実現するために意識すべきこと フロー効率の極大化によりユーザー価値へつなげる方法 中期目線で開発速度を保つ方法 それでは、それぞれ個別に 1 つ見ていきましょう。高速な価値提供を実現するために意識すべきこと どんなプロダクトであっても、実装しようとしている機能は、何らかの方法で検証してみるまで顧客にとって必要なものか分かりません。本記事のテーマである論文配信機能についても同様ですが、少なくともユーザーインタビューなどの仮説検証で一定のニーズは確認できていました。ニーズまでは確認できているので、実際にミニマムな機能を提供することで、仮説検証を進めます。ミニマムといっても、開発着手時点で実装可能な候補がたくさんあります。その候補の中から、いかに何も作らずに仮説検証できるか、そのために仮説検証対象を削ぎ落としていくのが重要です。今回はその実現のために、”最新データの追従” を最初は盛り込まずに検証する、というアプローチを取りました。こう書くと簡単なように見えますが、機能追加先のプロダクトである Anews は、毎日最新の情報を提供するプロダクトであるため、最新情報が届かないことはユーザーにとって違和感があるかもしれません。しかし、まずユーザーに価値があるかどうか判断するために、最新データを常に追従を当初から実装しないという意思決定をしています。（さらにいえば、最新データをどの程度の頻度で取得・更新すべきか、も検証する必要があります）論文データを取得する方法もいくつかありますが、今回は SemanticScholar に決定しました。SemanticScholar は検索による科学文献のデータ提供および、API により 2 億件以上の論文を含む科学文献のデータを無料で取得可能な機能を提供しています。こちらの決定要因も、まず仮説検証が迅速にできることを重要視した点にあります。このように、高速な価値提供を実現するために徹底的に価値の本質を見極めることを重視しています。なお、Se

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.

本記事執筆時点の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タグが利用されていると、記事中の重要コンテンツを落としてしまうことすらあります。そこで別の方法として、HT

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.

クラウドインフラに関わるコストは、各企業にとって1つの重要テーマかと思います。毎月、支払うコストであり、数％の増減であったとしても最終的にかなりの金額になります。昨今の為替事情もあり、そんなクラウドインフラのコストを弊社で削減してきた方法を本記事で紹介いたします。本記事を読むことで、実例と共に手法を学んでいただけます。何を実施したか？ ストックマークでは、クラウドインフラに AWS を活用しています。AWS のコスト削減のプラクティスは広く知られており、公式からもドキュメントが提供されています。具体的な方法の中からいくつか代表的なものを取り上げると次のような項目があります。コスト分析と監視 リザーブドインスタンス、スポットインスタンスの活用 オートスケーリングの活用 ストレージの最適化 データ転送の最適化 リソースの削除や停止 たとえばリザーブドインスタンスの導入といったすでに利用中なものもあります。本記事では、昨年度下期に実施した以下の3つ、特にストレージの最適化に焦点を当てて紹介します。コスト分析と監視 ストレージの最適化 リソースの削除や停止 （本記事では割愛） コスト分析と監視: コストが高い要素の把握 「推測するな、計測せよ」という格言があるとおり、パフォーマンスのみならずコストについても、まずは実測されているデータに注目するのが第一です。コストは自動的にAWS側で計算されているため、そのコストの内訳を確認するのが初手になります。ストックマークでも、コストを定期的に確認しています。本記事では、一定のインパクトのあった S3 のコスト削減について紹介していきます。ストレージの最適化 今回のコスト削減では、クラウドストレージとして利用していた AWS S3(Simple Storage Service) のストレージクラスを AWS S3 Glacier へと変更しました。Glacier はアクセスが遅い、という欠点があるもののコストは非常に安価です。そこで、ユースケースがハマれば、コスト削減につながる有力な手段になり得ます。もちろん、結論だけ切り取ってしまえば、非常に簡単な処理であるため「単にちょっとした変更をするだけでは？」とお考えになるかもしれません。しかし、現実には S3 に蓄積しているデータを活用する業務フローがいくつかあるため、既存業務にインパクト

本記事では、ストックマークで2022年の12月に実施した、6千万件を超える記事レコードの大規模データ基盤マイグレーションについて紹介いたします。本記事を読むことで、大規模データマイグレーションの勘所を実例から学べます。本記事でお伝えする内容は以下の4点となっています背景 検討の進め方 大変だったこと 再現可能な知見 背景 ストックマークでは大量の記事データを利用するプロダクトとして、AnewsとAstrategyの2つのプロダクトがあります。どちらのプロダクトも共通の記事データストアにある内容に、プロダクトごとの弊社独自の自然言語処理を加えたものを活用しています。アーキテクチャを簡単に表すと次のようになっています。移行前のアーキテクチャ AnewsとAstrategyでは解決する顧客課題が異なります。それぞれのプロダクト観点ごとに、顧客価値のディスカバリーを最優先としたことから、お互いのプロダクトで独自に進化してきた結果、本構成になっています。もちろん、当時の時点でプロダクト開発に着手する最初の段階から将来を見据えて基盤を共通化する、という考え方も存在します。しかし、そもそも共通化の必要性が明らかでない状態で着手しても、無駄に機能を作りこんでしまう可能性が高いため、スタートアップとしては不適と判断しています。やがて事業そのものが進化するにつれて、2つのプロダクト価値の接続の重要性が高まってきました。今後も両プロダクトが大きく成長していくことを考えると、このタイミングでのデータストアのマイグレーションへの着手を判断して実行したのが3ヶ月ほど前です。検討の進め方と移行後の方式 マイグレーションを進めるにあたり、重要な観点を2つ定めました。弊社の強みであるデータと自然言語処理技術が進化し続けられるデータ基盤となること 各プロダクトの開発のアジリティを落とさないこと 今できていることからデグレが起きないこと 上記を満たすように、移行方式を数パターン考えて、移行コスト、移行後の運用性・拡張性などの観点から、最終的に以下のアーキテクチャとしました。移行後のアーキテクチャ 本アーキテクチャでは、記事マスタを元に、AnewsとAstrategyが参照するデータ基盤を別々に構築しています。ただし、データ基盤を構築するまでのパイプラインを共通化することで、2プロダクト間のデータ整合性を

はじめに 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日間です。事前学習済モデルの

本記事は、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, 脆弱性 食品 代替肉, 食品ロス, 陸上養殖, 生分解, 国産大豆 エネルギー 太陽光発電, 洋上風力, バイオマス, 再エネ, 燃料電池 銀行・金融 暗号資産,

はじめに こんにちは、Researcherの北山です。今回は自然言語処理技術を用いてAstrategyにおける顧客体験向上のための取り組みを行ったので、その内容を共有したいと思います。 本内容は弊社のTech Meetup #04でも発表した内容になりますので、ご興味のある方はそちらもご覧いただけますと幸いです。自然言語処理とは 自然言語処理とは、我々が日常のコミュニケーションで用いている言語（自然言語）を機械で処理する技術のことです。情報系の分野では単に言語というとプログラミング言語を連想する方も多いため、それと区別するために自然言語という用語が使われています。自然言語処理が活用されている事例としては、例えば以下のようなものがあります。 弊社では、そういった自然言語処理を活用し、ニュース記事内の情報を構造化することによって顧客体験の向上に取り組んでいます。例えば、以下の例ではニュース記事から主題企業とその取り組み、またそれがどのフェーズにあるのかといった情報を抽出して構造化しています。こうした情報を蓄積して構造化しておくことで、その後の分析や情報提供に活用することができます。 出典[1]構造化事例: 定義文抽出 今回は構造化の一つとして、定義文抽出に取り組みました。ここでは、以下の図に示すようにニュース記事から単語の定義を説明している文（定義文）を抽出しています。 出典[2][3][4]定義文のニーズ そもそも、なぜ定義文が必要になるのでしょうか？これまで、Astrategyを利用していただいているお客様がトレンドなどに分からない単語が出てきた際に、外部サービス（Google検索など）で調べなければならなかったり個別のニュース記事を見にいって中身を確認しなければいけなかったという課題がありました。定義文抽出によって予め用意された定義文をAstrategy内で提示することができれば、そういった課題を解決することができます。 出典[2]定義文抽出の流れ ここからは、実際の定義文抽出の流れについて説明します。以下の図のように、ニュース記事を定義文判定器と主語抽出器の2種類によって処理した後、抽出された定義文をデータベースに保存することによって構造化が行われます。そうして保存されたデータベースにアクセスすることによって、必要な時に定義文の情報を利用することができます。 2

ストックマーク 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として括りだして使うなど、保守性を高めています。価値のベースラインを保つリグレッションテスト プ

はじめに 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万記事をスクレイプできるこ...

ストックマークではプロダクト開発の方法として、プレスリリース駆動開発を採用しています。このアプローチは Amazon で Working Backwards と呼ばれる方法に類似した方法です。本記事では、実際にプレスリリース駆動開発を実施すると何が起こるのか？という点について紹介します。今後、プロダクト開発においてプレスリリース駆動開発を採用してみようかな？という方には、有益な情報になると思います。先に実物を紹介 本記事でベースとしているプレスリリースは Astrategy というプロダクトの新機能になります。実際のプレスリリース 詳細は実物をご覧いただければと思いますが、内容草案はまさにプロダクトのPRD(Product Requirements Document)や、実装が進む前からプロダクトオーナーが書いていたものです。では、詳細検討が進む前にプレスリリース案を作成すると、社内では何が起こるのでしょうか？プレスリリース駆動開発を起因とした3つの変化 社内で起きた変化のうち、ここでは3つを取り上げます。顧客のアトラクト強化 プロダクトオーナー自身の気づきによる新機能の洗練化 より効果的な画像が作成できるように 以下でそれぞれを説明していきます。1. 顧客のアトラクト強化 ビジネスサイドからすると、プレスリリースの内容を先に見ておくと、具体的に機能のイメージをつかみやすくなります。もちろん、ロードマップの内容から、この先に出てくる機能を理解することも可能ですが、プレスリリースは顧客向けの表現になっていることから、より解像度高く自社プロダクトを理解できるようになります。その結果、顧客とのタッチポイントがあった際に、「この課題を解決するために、こういう機能を作っているんです。こんなイメージです。…」と具体的に説明できるようになります。顧客へより魅力的な説明が可能となるわけです。2. プロダクトオーナー自身の気づきによる新機能の洗練化 プロダクトに新機能を追加する場合、当然のことながら具体的な顧客を意識して、何らかの課題を解決しにいきます。ただ、プロダクトオーナーは顧客インタビューや指標確認など様々な業務を並行していることが多く、頭の中のメモリをフルに活用していることが多く、ふとした瞬間に検討の抜け漏れが発生することがあります。プレスリリースはこの抜け漏れを気づかせてく

概要 組織の拡大に伴う開発チームの分割、独立性向上のためにGitHubの運用フロー見直しと同時にFeature Flagの導入を行いました。 結果として、独立した開発をしてもコンフリクトが発生しづらくなったことにより生産性が向上、副次的効果として部分リリースにより問題の先行発見をしやすくなり、品質向上にもつながりました。背景：GitHubのブランチ戦略がチームスケールの弊害に プロダクトや会社の成長に伴い、開発チームにはスピードと安定性の両面が求められるようになっていきますが、少人数のメンバーだと限界がやってきます。実際に、小さな改善はできるけど、ソフトウェアアーキテクチャ自体を見直すような大きな改善施策は、新規開発もある中で中々優先度を上げられないような状態が起きていました。このような状況下で、開発組織としては総スループットを向上させる必要がありますが、単純に同じプロダクトの開発人数を増やしていくと、調整コストの増大、コンフリクトの発生などにより生産性が思うように上がりません。Anews開発チームでは３人の小さなチームに分割して独立性を高め調整コストを下げる方針をとりましたが、時に大きなコンフリクが発生してしまい、これを防ごうとすると調整コストが発生する状況にあり、両立が課題になっていました。変更前の運用：コンフリクトと調整コストのトレードオフ 運用方法開発項目毎にmasterからfeatureブランチを派生する １開発が大きい場合、サブタスク用のブランチをfeatureブランチから派生する（図中feature/greenの例） 開発項目毎に、サブタスク全てが完了してからdevelopment環境にリリースし受け入れレビューを行う リリースは毎週実施しており、火曜日に受け入れレビューが完了している全てのfeatureブランチをreleaseブランチにマージし、staging環境にリリースしてテスト 木曜日にstagingブランチをmasterブランチにマージし、production環境にリリース 発生していた課題規模の大きな開発の場合、コード変更がベースブランチであるmasterにマージされるまでの期間／規模が大きくなり、大きなコンフリクトが発生するリスクが高い（図中feature/greenとfeature/redをrelease/2にマージするタイミング） し

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: 役割の一部を明確化 ここで、まず取り組んだのはそれぞれのチームの適任メンバー数人が掛け持ちで分担するス

グローバル化が進む現代において、様々な言語で情報収集を行う必要性がこれまで以上に高まっています。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) (F

本記事は Grouping Similar Articles with Search Engine More-Like-This Queries and Graph Algorithms の翻訳記事です。以前の記事である More Like This Query を活用した類似記事集約 入門 から、より踏み込んだ内容になっています。はじめに ストックマークでは、毎日数千のメディアから数万件のニュース記事を収集しています。そのときに、異なるメディアから類似した内容の記事がクロールされることもあります。その一方で、これらの内容の重複した記事をそのままユーザに表示してしまうと、ユーザの情報収集体験を損ねてしまう可能性があります。そのため、ストックマークのプロダクトであるAnewsので記事推薦や、Astrategyでの事業活動比較などのニュース分析サービスにおいて、より良いユーザー体験を提供するためには、類似記事を検出して集約するのが重要です。全く同じ内容の記事を集約するのは比較的簡単です。難しいのは、同じ内容の記事ですが、表現のやや異なる記事も集約する必要がある点です。類似記事の多くは、同じ文章を複製しているのではなく、同じ記事を別の著者が書いたという形になっています。ストックマークでは、文書の類似性を見つけるために検索エンジンを利用しています。また、類似した記事をグループ化するためにグラフアルゴリズムを利用しています。以降で、詳細は説明していきましょう。類似性グラフの構築 記事を集約する前に、類似性グラフを最初に構築します。グラフの各ノードは記事を表しており、2つのノードが類似していると判断された場合、2つのノード間にエッジが存在しています。類似性定義のためのメトリックによって、グラフは有向もしくは無向になります。今回の場合は有向グラフになります。記事が固定次元のベクトルで表現できれば、doc2vec や S-BERT を利用して、ベクトル距離を計算して記事の類似性を計算できます。今回のプロジェクトでは、これとは異なる方法を利用しています。すなわち、記事の類似性取得に全文検索エンジンを利用しています。実際に、全文検索エンジンを利用したアプローチの方が、高精度で柔軟な検索が可能であることがわかりました。ストックマークでは、ニュース記事のインデクシングに Elasticse

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.

はじめに 本記事では、ストックマークのプロダクトの実装で工夫している類似記事集約という技術について紹介します。本技術により、多くのドキュメントを扱う機会がある場合に、お客様に高い価値を提供できるようになります。ストックマークでは社内の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が同一であること(似ていること)をどのように判断すればいいのでしょ

こんにちは、Machine Learning部門の森長です。昨年(2021年)の9月に開催されました、AWS Dev Day Online Japanのスペシャルプログラム #1：ボケて電笑戦に参加させていただきました。そこで、本記事では、ボケて電笑戦で作成したお笑いモデルについて紹介いたします。ボケて電笑戦とは ボケて電笑戦とは、「AIは人を笑わせられるのか？」という問いを解明すべく、アマゾンの奥地へ向かった膨大なボケのデータを学習させて新たな笑いを作り出せるのかを競い合う挑戦です。今回のボケて電笑戦では、弊社を含め3企業がお笑いモデルを独自に作成して、人を笑わせるべく大喜利対決を行いました。詳細は、スペシャルプログラム #1：ボケて電笑戦に以下のような記載されていますので、ご覧いただければと思います。人間の喜怒哀楽に AI は影響を与えることができるのでしょうか。「ボケて電笑戦」はその命題に挑戦した AI 大喜利対決です。 国内最大級のお笑いメディア『ボケて』の約 100 万のお笑いのデータを利用して、人間が考え出したボケを上回る新たな笑いをAI が作り出せるのかを競い合う『ボケて電笑戦』。まさに新時代の笑いをテクノロジーで切り開くかもしれない壮大なチャレンジです。ぜひお見逃しなく！上記の本戦の様子は公開されておりませんが、テクニカルセッションが公開されています。また、2020年に参加企業を含めた紹介記事(2020年当時のお笑いモデルの紹介)が以下にて公開されています。ボケて電笑戦記事の1つ目 ボケて電笑戦記事の2つ目 ボケて電笑戦記事の3つ目 では、以降からこのボケて電笑戦で弊社が作成したお笑いモデルについて紹介していきます。お笑いモデルの構築 まず、ボケの教師データとして、お笑いメディア『ボケて』の約100万のお笑いデータ(画像とその画像のボケテキスト)をご提供いただきましたので、教師あり学習でお笑いモデルを構築することにしました。お笑いモデルの構築の流れはおおまかに分類すると以下の手順になります。基本的にはこの手順を何度も繰り返し、お笑いモデルをブラッシュアップしていきます。教師データの準備 教師データの前処理 お笑いモデルの構成と学習 生成したボケの後処理 生成したボケの評価 では、最終的なお笑いモデルがどのように作成されたかを上記手順の流れで紹介してい

はじめに こんにちは、Anewsのエンジニアリングマネージャーの山崎です。 この記事はストックマークアドベントカレンダーの22日目の記事です。普段は、エンジニアリングマネージャーとして開発体制や中長期のエンジニア戦略を考えています。 またエンジニアリングマネージャーとは別にエンジニアとしてAnewsのFlutterアプリの開発を行なっています。Anewsの開発組織では全員がフルスタックエンジニアとして働くことを推奨しており、 開発体制やプロセスについてもフロントエンド、バックエンドなどの領域を意識せず顧客への価値提供を最大化するためエンジニアが必要な開発を行うようにしています。その中で、モバイルアプリだけは固定されたメンバーで開発を行うような体制になっています。 理由としては、 ・ モバイルアプリの開発経験が少ない ・ モバイルアプリのコードが複雑になっており、学習コストが高くなっているこの問題を解決するために未経験者でも開発が行いやすいようにするため、モバイルアプリのアーキテクチャを見直すことにしました。今回は現在行なっているアーキテクチャ刷新の全体像を紹介できればと思います。現在の問題点 現在のアーキテクチャ問題点について ・開発ルールがないため個々のエンジニアの裁量で設計が決まっていく ・コード全体で依存関係が整理されておらず処理を追うことが難しい・コードの結合度が高くコード改修での影響範囲が広くなるこの問題を解決するためにレイヤードアーキテクチャを採用し、階層ごとに処理を分割しUI部分についてはAtomic Designのコンポーネント分割を参考に分割することで影響範囲や処理のルールがわかりやすいようにしています。全体のアーキテクチャの方針 UI, Domain, Infrastructureの３層構造にすることにより、依存関係を整理し影響範囲をわかりやすくしました。UI：表示処理を行うコンポーネント Domain：UIとは切り離されたビジネスロジックの集合 Infrastructure: 外部リソースとの接続処理の集合ディレクトリ構成もレイヤーにより分割することにより、ディレクトリ内に含まれているコードの予想ができ探しているコードを見つけやすい状態にしています。Domain, Infrastructureの方針 DomainとInfrastructureで

ML事業部の金田です。今回はAnewsへの応用を見越して実施した、公開データセット（MINDデータセット）を用いた既存ニュース推薦手法の性能確認実験について紹介します。なお、実験で用いたコードはこちらに公開しています。背景 当社の開発する法人向けサービスのAnewsには、ニュース推薦システムが実装されています（その概要は以前の記事で紹介したとおりです）。このシステムは、製品開発の初期段階に構築されたものです。その際には顧客要求を素早く叶えることが優先されており、当時はニュース推薦システムの研究動向を十全にフォローアップできていませんでした。構築以降に実施されたシステム品質改善も、顧客から寄せられた問題の解消を目的としていたため、「そもそも技術的観点から現行システムにどの程度改善の余地があるのか？」という疑問に対して、これまで明確な回答を用意できていませんでした。この問題を解消するため、現在R&Dユニットでは、製品で必要とされる機能プロトタイピング/機能改善の傍ら、ニュース推薦モデルに関する論文調査・社内データへの適用性確認（現行アルゴリズムとの比較評価）を試みています。このたび紹介する内容は、この調査の過程で生まれた、公開データセット（MINDデータセット）を用いた既存提案手法の性能確認結果になります。MINDデータセット MINDデータセット1 2は2020年にMicrosoft社の公開した、ニュース推薦のためのデータセットです。このデータセットはMSNニュース（英語）の利用ログから構築されたもので、次のデータを含んでいます。行動データ（behavior.tsv） あるクリック履歴（history）を持つユーザが行った、あるタイミングで提示されたニュースリストに対する反応（impressions）。データの概観は下図のとおりです。 図1. 行動データの概観 ニュース記事データ（news.tsv） 行動データに含まれるニュース記事の情報。各記事は以下の属性を持ちます。 記事ID タイトル アブストラクト 本文3 カテゴリ サブカテゴリ MINDデータセットには上記以外にもデータ/ニュース記事属性が含まれていますが、ここでは以降の実験に関係するものに絞って紹介しています。 （全容及び詳細に興味のある方は公式の説明をご確認ください）。このデータセットで扱う問題は、「ある

ストックマークの開発体制は、プロダクトの成長フェーズに合わせて、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: プロダクトマネー

本エントリは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の使い方そのものについての詳細は

はじめに こんにちは、ストックマークでエンジニアをしている麻生です。ストックマークでは、「Anews」というウェブサービスを提供しています。この度、Anewsで新機能導入のために日次バッチの大規模なインフラ変更を行い、GPU並列処理環境を構築しましたのでご紹介します。組織の自律化を支援するナレッジプラットフォーム「Anews」 Anewsは国内外30,000メディアのニュースを毎日収集し、最先端の自然言語処理で個人や組織のミッションに即したニュースをレコメンドします。コメント機能で簡単にチームにアイデアを共有でき、社内の知見者から学ぶことでチームの情報感度が底上げされます。エンタープライズを中心に、累計1500社以上のお客様にご利用いただいているサービスです。Anewsのプロダクトイメージ 英語記事をレコメンドする上での課題 Anewsでは、記事への行動履歴からユーザーや組織の好みを学習し、記事をレコメンドしています。ユーザーが記事に対してシェアやコメントをするほど行動履歴が蓄積され、記事のレコメンド精度が向上する仕組みです。レコメンドについてはこちらの記事に詳しい解説があります。アクションを取らなければ記事のレコメンド精度の向上が見込めないのですが、そこで問題になるのが英語記事です。日本語を母国語とする以上、英語記事を読むのは負荷のかかる作業で、どうしても記事へのアクションが少なくなってしまいます。そのため、英語記事のレコメンド精度は上がりにくく、精度が低いことでレコメンドに繋がる行動履歴も蓄積されない、という悪循環に陥っていました。お客様によっては海外の情報が重要なケースもあり、英語記事のレコメンド精度をいかに上げるかが課題でした。日本語記事への行動履歴活用によるレコメンド精度向上 そこで今回持ち上がったのが、日本語記事への行動履歴を元に、英語記事をレコメンドするというアイデアです。英語記事を読まないユーザーも日本語記事への行動履歴は蓄積されているため、それが使えれば英語記事のレコメンド精度を向上させられるはずです。単純なアイデアですが、英語と日本語では文章の性質が全く異なるため、日本語記事への行動履歴をそのまま英語記事に活用できません。一度、日本語記事を英語記事に翻訳することで、あたかも英語記事へのアクションがあったかのようなデータを作成する必要があります。レ

ML事業部の金田です。今回は、ストックマークの提供する法人向けサービス「Anews」の裏側で動くビジネスニュース推薦システムについて、簡単に紹介いたします。Anewsとは Anewsは組織変革のための情報収集＋コミュニケーションプラットフォームです。情報収集のためのコア機能としては、国内外３万メディアから収集したビジネスニュースから、利用者の興味・関心に合わせて記事を配信するサービスを提供しています。日々配信されるニュースから業務ニーズに直結するインサイトを獲得し、これを話題にユーザ同士が交流することで、組織全体の情報感度やコミュニケーションを促進させるのが、サービスの狙いです。Anewsのプロダクトイメージ 事前準備：ことばの定義 具体的な機能説明の前に、Anewsにおける基本的な概念について軽く整理します。Anewsは1企業＝1集団としての利用を想定しています。以降ではこの集団をチーム、チームに所属する各利用者をメンバーと呼ぶことにします。ニュース配信の際に利用する情報は、基本的にチーム毎に独立しています。各チームでは、特定の話題を追うためのチャンネルであるテーマを作成することができます。テーマに存在するテーマフィードには、設定されたキーワードにマッチするようなニュースリストが一日一回配信されます。キーワード設定画面 テーマ画面。「関連ニュース」及び「新着ニュース」がテーマフィードに相当 一般に、レコメンデーションシステムではコールドスタート問題の解消が課題とされます。これは、サービスを初めて利用するユーザに発生してしまう、次のような問題です。初利用するユーザからは興味・関心を表す手がかりが得られないため、よいレコメンドが行えない よいレコメンドが行われないため、ユーザが自身の興味・関心を提示する前に離脱してしまう テーマフィードでは初期設定時のキーワードを手がかりとすることで、この問題に対処しています。メンバーはフィード上のニュースに対し、自由に閲覧、マーク、コメントといった行動をとることができます。これらの行動は、より良いニュースを配信するための手がかりとして利用されます。テーマフィードに配信されるニュースリストはメンバーに依らず同一であるため、これを共通の話題として扱うことができます。行動履歴が一定以上蓄積したメンバーに対しては、一人ひとりの嗜好に合わせた

ストックマークでは、法人ユーザー向けの「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）からアクセス

はじめに 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氏が公開しているTh

はじめに 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で別々に作る場合には、学習コスト含め、ある程度の期間が必要な点が見込まれます。クロスプラットフォームで開発する場合も、専用の言語やフレームワークの学習コストが発生しますが、仮にクロスプラ

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 今後、このデータセットを用いた実験やスクリプトなども公開できればと考えています。

ML事業部の近江崇宏です。Stockmarkでは日々、膨大な数のニュース記事に対してBERTの推論処理を行なっています。このような重いタスクを効率的に処理するために、最近、TPUを用いたBERTの推論処理基盤をGoogle Cloud Platform上に構築し、運用を開始しました。その結果として、これまで1週間程度かかっていた、数千万件のデータの処理を1日以内で完了できるようになるなどの大きな効果を得られました。今回はこの取り組みについて紹介します。はじめに 近年のニューラルネットワークの研究の発展により、画像認識や自然言語処理の様々なタスクを人間と同等もしくはそれ以上のレベルで処理できるようになりました。その結果として、ビジネスでのニューラルネットワークの利用が進んでいます。その一方で、ニューラルネットワークには、モデルの巨大さに起因して処理時間が長いという大きな問題があります。そのため、それらを適切にコントロールすることが、プロダクトでのニューラルネットワークの活用が成功するかどうかの重要な鍵になっています。一般的には、モデルを学習するときの処理時間の長さが問題とされることが多いですが、これは推論でも大きな問題となり得ます。特にStockmarkでは、BERTと呼ばれる自然言語処理のためのニューラルネットワークを用いて、膨大な数のニュース記事に対して分類や抽出などの推論処理をしており、これにかかる時間の削減がプロダクトでの大きな課題になっています。具体的には、新規のニュース記事（数万件）に対する日次のバッチ処理 新たなモデルがプロダクトに追加された場合や、アルゴリズムの変更や学習データの追加により既存のモデルが更新された場合に行われる、データベースに保存されている過去のニュース記事（数千万件）に対する全件処理 などの日々のオペレーションでBERTの推論処理を行なっています。そのため、このような大規模なデータに対して効率的に推論処理をするための強力な処理基盤が必要になりました。StockmarkではこれまでBERTの推論を主にGPUを用いて行なってきましたが、Googleが開発した行列演算などの機械学習の処理に特化したチップであるTPUを用いて、データ処理を効率化する取り組みを最近始めました。そして、新たな処理システムをGoogle Cloud Platform

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.

はじめに (この記事の英語版は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では単一のTP

はじめに ストックマークが提供するプロダクトであるAnewsにおいて、ビッグリライトによるフロントエンド・バックエンドの両方を含むアーキテクチャ刷新を成功させました。一般にビッグリライトは、ハイリスク・ハイリターンであり、難易度も高いと言われていますが、大きなトラブルもなく、かつお客様評価も高い状態を実現しています。Anewsリニューアル後の画面イメージ本記事では、なぜビッグリライトを選択したのか、何が要因となって成功に至ったのか、といった事項について、開発チームで振り返りした中からいくつかの要因を紹介いたします。アーキテクチャ刷新の背景 Anewsは、新規Feedを最適化して提供するプロダクトで、2020/8時点では累計1500社のお客様に利用されています。(参考：導入事例)スタートアップのプロダクトでは、顧客の声に耳を傾けながら、大小あるピボットを積み重ねて、洗練されたプロダクトを開発・提供していきます。Anewsも例にもれず、細かな変更の積み重ねを繰り返してきました。幸いなことに多くのお客様に利用いただいておりましたが、より高い価値を提供するためには、プロダクトを大きく変更する必要がでてきました。そこで、2020/1に大規模なシステムリニューアルを決断しました。なぜビッグリライトの選択したのか？ 基本的なプロダクトのベース機能は、リニューアル前後で同一です。ベース機能は同一ですが、今回のリニューアルでは、ニュースフィード画面の大きな変更を加えます。このような状況下でのベースアーキテクチャ刷新の方法には、ビッグリライト・リアーキテクティング・リファクタリングなどいくつかのアプローチがあります。（参考：レガシーソフトウェア改善ガイド）Anewsでは前述の通り、ハイリスク・ハイリターンであるビッグリライトを選択しました。一般に、ビッグリライトは、既存プロダクトと並行開発・運用する必要もあるため、リソース的な制約もあり、難易度があがります。しかし、成功した場合には、顧客向けの提供したい価値の最大化に加えて、これまでの技術的負債の解消も狙えます。そこで、Anewsではビッグリライトを選択しました。もちろん、単に選択したのではなく、いくつかの工夫を加えることによって、成功確度を戦略的に高めています。以下ではそのアプローチについて紹介いたします。ビッグリライトの成功確度を上

こんにちは、ストックマークでSREを担当している松下です。ストックマークでは企業向けの情報収集・企業分析・営業支援サービス(Anews, Astrategy, Asales)を運営しており、導入を検討されているお客様よりセキュリティの取り組みに関してお問い合わせをいただくことが多々あります。お客様のセキュリティ基準をプロダクトが満たせるかどうかは、ストックマークにとっても最重要課題であり、ストックマークのセキュリティ向上への姿勢をより分かりやすく示すために、8月にはISMS認証を取得しました。今回はISMS認証取得を記念して、私が担当しているAsalesを例にしながら、これまでにストックマークが行ってきたセキュリティ対策の一部をざっくりとご紹介させていただこうと思います。Asalesについて Asalesはセールスなどの提案資料や社内資料を自然言語処理技術で学習・解析し、売上拡大のために必要な社内ナレッジを共有・レコメンドする営業支援サービスです。蓄積された提案書を"言葉のAI"が解析することで、提案経験のある社内エキスパートを見つけ出せたり、顧客に響く提案を作成するヒントを得る機会を創出します。図1: Asalesの機能提案資料の作成をイメージして「Asalesを利用する流れ」を簡単にご説明すると、エンドユーザーはAsalesに提案資料や社内資料をアップロードする。 アップロードされたファイルは機械学習処理により学習・解析され、その結果が保存される。 エンドユーザーがAsalesからキーワードや作成者、商材、業界などを指定して検索を行うと、保存された学習・解析結果から最適なスライドを探し当てることができる。 となりますが、Asalesを利用して作成した資料をAsalesにアップロードして、それがまた誰かの役に立って新しい資料がAsalesにアップロードされて、というサイクルが続けば、学習・解析の効果がより高まって「セールスの永久機関になり得るな」と考えたりしています。セキュリティ対策の検討ポイント そんなAsalesですが、お客様から「クラウドにアップロードしたデータに第三者がアクセスできない仕組みがあるか」というお問い合わせをよくいただきます。お問い合わせをいただく中には施設・設備などへの物理的なアクセスを含んでいることがありますが、こちらはAsalesでクラウ

はじめに Machine Learning部門の近江です。ストックマークでは、自然言語処理技術の研究開発を行っています。先日、弊社のTech Blogにて弊社が公開している言語モデルを紹介しました。ストックマークが公開した言語モデルの一覧と振り返り今回は、言語モデルがプロダクトにおいて実際にどのように利用されているかについての一例を紹介します。ニュース記事の構造化 マーケティング、新規事業開発などの調査業務では、調査を行う人が書籍、ニュース記事、ホームページなどの情報を網羅的に調べ、整理し、報告書などにまとめていきます。その際に扱う情報は膨大であり、そのため調査業務には多くの時間と労力がかかります。弊社のプロダクトである「Astrategy」は機械学習を用いてニュース記事から特徴となる情報を抽出し、構造化することで、大量のニュース記事を効率的に俯瞰し、さらに新規事業開発などに繋がりうる情報の発見を促進することを目的としたものです。Astrategyではニュース記事の構造化の一つとして、ニュース記事に現れる企業の名称を抜き出すということを行っています。これは、市場調査において市場にどのようなプレイヤー（企業）が存在するのかという情報は、非常に重要であるからです。今回は、この「ニュース記事からの企業名抽出」を例にして、言語モデルを用いた機械学習についての弊社の取り組みを紹介します。企業名抽出の難しさ 機械学習でニュース記事から企業名を抽出すると聞いて、多くの人は「これは簡単なタスクだ」と思うのではないでしょうか？このタスクは人間にとっては非常に簡単です。しかしながら、以下でわかるように、これをコンピュータにやらせるのは意外と難しいものです。企業名をテキストから抽出する最も単純なアプローチは、企業名を集めた辞書を用意しておき、辞書に含まれている企業名が文章中に含まれていれば、それを企業名と見なすというものです（辞書方式）。企業名の辞書としては、国税庁が公開している日本に存在する全ての法人を登録したデータベース（https://www.houjin-bangou.nta.go.jp/）があります。これを用いて、実際に次の文章に対して辞書方式の企業名抽出をしてみましょう。「ストックマーク株式会社では現在、エンジニアを募集しています。」これを見た時、多くの人は「ストックマーク株

こんにちは、ストックマークでPR担当している中野です。 AIに人は笑わせられるのか…。9月開催の「AWS Summit」で行われる 「電笑戦 ~ AI は人を笑わせられるのか ?」の挑戦者 として、当社のAIが出場します！ 1枚の画像に対して一言コメントでボケて、笑いを取るコンテンツです。「AWS Summit」の開催に先駆けて、画像に対してAIがボケてる様子を記事にして頂きました！弊社 森長が、技術解説とともに、実際にAIが繰り出すボケをいくつか紹介します！ぜひチェックしてみてください。 9月8日(火)～9月30日(水)に開催される「AWS Summit Online」の本番もご期待ください！ 記事掲載：AWSウェブマガジン「builders.flash」 電笑戦 ~ AIは人を笑わせられるのか 第 2 回 電笑戦の背景と挑戦者

こんにちは、Machine Learning部門の森長と申します。Machine Learning部門は、プロダクト適用を目指した基礎研究&基礎研究のプロダクト適用の二軸を担当しています。基礎研究では、言語モデルの作成、文章のカテゴリ分類・クラスタリング、要約の検証等、プロダクトへの適用を見据えて研究テーマを設定しています。また、自然言語処理の盛り上がりに少しでも貢献できればと考え、言語モデルの公開を行っていますので、もしよろしければ使ってみてください。今回は、弊社で公開している言語モデルについて書いていきます。言語モデルとは 言語モデルにも色々な種類のモデルがあり、一口でこれというのは難しいですが、簡単に言うとすると、「単語列に対して確率を計算するモデル」です。厳密には各言語モデルで目的が違うため、呼称が少しずつ異なりますが、本投稿では言語モデルという表現で統一させていただきます。言語モデルを利用することで、例えば、文章の生成や単語の意味的な近さの計算を行えます。 弊社では、これらの言語モデルを組み合せることで、ビジネス文章の解析・構造化(文の分類やクラスタリング、企業名抽出等)を行っています。弊社で公開している言語モデル一覧 弊社では、Qiitaで紹介記事を書き、以下の言語モデルを公開しています。言語モデル Qiita公開リンク ELMo 大規模日本語ビジネスニュースコーパスを学習したELMo（MeCab利用）モデルの紹介 BERT 大規模日本語ビジネスニュースコーパスを学習したBERT事前学習済（MeCab利用）モデルの紹介 XLNet 大規模日本語ビジネスニュースコーパスを学習したXLNet（MeCab+Sentencepiece利用）モデルの紹介 ALBERT 大規模日本語ビジネスニュースコーパスを学習したALBERT（MeCab+Sentencepiece利用）モデルの紹介 公開している学習モデルの詳しい説明はQiita記事を参照いただければと思います。今回はせっかくなので、言語モデル作成当時の経緯等を順に振り返ります。ELMo 2018年11月某日..森長：「記事の分類の分類タスクの精度向上が頭打ちになってきた。。。記事中の「ライオン」という文字列が「企業のライオン」さんなのか「大西ライオン」さんなのか「百獣の王のライオン」さんなのか分からない。日本語

こんにちは、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モデルを各タスク用にチューニングしたものを使っています。モ

こんにちは、ストックマーク CTO有馬です。この度、テックブログをはじめることにしました。創業してからあっという間に3年半が経ち、Anewsに至ってはおかげさまで1500社様に活用いただけるような大きなAI SaaSプロダクトにまで成長しました。AIという高次元でハイカロリーな計算処理をSaaS内で実用化し顧客価値につなげるには、不断の学習と成長痛が伴います。サービス立ち上げ当初は、精度がなかなか出ず赤子のような出力になったり、急増するユーザ数にアーキテクチャが追いつかず復旧のために3日間徹夜してしまったり、深夜にAIが暴走していて朝起きたら100万円規模のサーバー費課金をくらったり・・・ただ、やればやるほど、これまでのITにはない価値と興奮をAIは創出できるという手応えを感じるようになりました。創業時点からは考えもつかなかったほどの優秀なメンバーが集まり、予想の斜め上を行くような技術知見が多く集まるようになりました。社内だけにとどめておくのは勿体無いと感じ、公開したいと思うに至りました。隔週程度を目標に、投稿していきたいと思いますので、よろしければ読んでいただければと思います。よろしくお願い致します。