コネヒト開発者ブログ

コネヒト開発者ブログ

「スマイル制度」を利用してBabelのスポンサーになりました

こんにちは、エンジニアの富田です! 今回は社内制度を利用して、Babelのスポンサーをした事例を紹介したいと思います。

Babelが資金難であることを知った

時は遡ること1年前ですが、当時以下の記事からBabelが資金難で困っていることを知りました。

www.publickey1.jp

コネヒトのフロントエンド開発でもBabelを使っているため、なんとか支援できないかなと考えてみたものの、「会社での支援って大変そう?」という思いから具体的なアクションに結びつけられませんでした。

支援したいという気持ちの再燃

何もできないまま時は流れていましたが、たまたまトヨクモさんのOSSに関する支援活動を知って、素晴らしい活動をされていると共感しました。

oss.toyokumo.co.jp

上記をきっかけになんとか小さく始められないかと模索し見つけたのが、コネヒトの「スマイル制度」です。

スマイル制度を使って支援

コネヒトには「スマイル制度」という制度があります。これは開発組織のインプットとアウトプットの活性化を促進する制度です。とてもコネヒトらしい制度になっているので、詳しくはスマイル制度をご覧ください。

tech-vision.connehito.com

上記の制度を活用して少額ではありますが、Babelスポンサーをさせていただきました!

github.com

最後に

1年越しに支援できたことを嬉しく思うのと同時に、コネヒトは他にも様々なOSSを利用しているので、私たちが使っているOSSに関して支援できることがないか引き続き考えていきたいと思います。

Xcode14対応

こんにちは!コネヒトでiOSエンジニアをやっていますyanamuraです。

ママリのiOSアプリでXcode14でビルドが通るように対応を行いました。そんなに大変ではありませんでしたが、多少修正するところがあったのでまとめてみました。

やったこと

ライブラリのアップデート

ママリではRealmを使っていて、バージョンを上げる必要がありました。RealmSwiftを10.28.1、RxRealmを5.0.4にアップデートしました。

また、Xcode14にするとSwiftのバージョンが5.7になります。ママリではswift-formatを使っていて、こちらのバージョンを0.50700.1にアップデートしました。

ソースコードの修正

以下のようなエラーがコンパイル時に出るようになったので修正を行いました。

The compiler is unable to type-check this expression in reasonable time: try breaking up the expression into distinct sub-expressions

コンパイルエラーが発生した箇所はcombilneLatestでネストしている部分でした。

このようにcombineLatestの数の制限を突破するためにネストしている箇所が!

Observable.combineLatest(
    Observable.combineLatest(
      x,
      y
    ),
    a,
    b,
    c,
    …
    )
)

このようにネストしている箇所を外に出してやることでエラーは解消できました。

let xy = Observable.combineLatest(
      x,
      y
)

Observable.combineLatest(
    xy,
    a,
    b,
    c,
    …
    )
)

archiveに失敗する問題対応

上記対応でビルドはできるようになったのですが、archiveで失敗するようになりました。

CocoaPodsで追加しているライブラリで署名のエラーが出ました。

Signing for “XXX” requires a development team. Select a development team in the Signing & Capabilities editor

CocoaPodsのほうでもissueとしてあがっていました。 https://github.com/CocoaPods/CocoaPods/issues/11402

解決方法としてはこちらのようにTeam IDを設定するか https://github.com/CocoaPods/CocoaPods/issues/11402#issuecomment-1149585364

post_install do |installer|
  installer.generated_projects.each do |project|
    project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings["DEVELOPMENT_TEAM"] = " Your Team ID  "
         end
    end
  end
end

CODE_SIGNING_ALLOWEDをNOにすることで解決できました。 https://github.com/CocoaPods/CocoaPods/issues/11402#issuecomment-1201464693

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
      target.build_configurations.each do |config|
          config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
      end
    end
  end
end

まとめ

Xcode14にあげることで、iOS16の実機デバッグができるようになりますし、Swift5.7の新機能が使えるようになります。

Swift5.7ですぐに使いたいのがif letなどの短縮で

var startDate: Date?

if let startDate = startDate {
…

と書いていたのが以下でよくなりますね!

var startDate: Date?

if let startDate {
…

Swift 5.7については公式のだとSwift language announcements from WWDC22 が見やすい感じになっていますのでXcode14対応が終わったら見てみると良いかなと思います。

例年春頃にはXcode14にあげないとAppStoreに申請できなくなってしまうのでお気をつけください。


コネヒトでの開発に興味を持っていただいた方はカジュアルにお話しましょう〜 TwitterのDMなどでも大丈夫ですのでお気軽にどうぞ www.wantedly.com

3年ぶりにCTO Night & Dayに参加してきました!

こんにちは。CPOをやっている@itoshoです。

先日AWSさん主催のCTO Night & Day 2022 in 長崎(以下、CTO Night)に参加させていただきましたので、簡単にレポートをお届けします。*1

長崎とCTO Nightと私

CTO Nightとは技術の立場から経営に参画するリーダーが一堂に会する招待制カンファレンスですが、今年は3年ぶりにオフサイト開催となりました。僕自身も前回参加させていただいたのが、3年前の京都開催のCTO Nightでしたので、久しぶりのオフサイト開催は"くる"ものがありました。*2

CTO Night and Day 2019 | AWS Startup ブログ

長崎については、僕は初上陸で観光はほとんど出来なかったのですが、随所に異国情緒を感じさせる建造物があったり、レトロな路面電車が走っていたりと歴史を多層的に感じられる素敵な街でした。また、ワークショップで軍艦島ツアーに参加させていただいたのですが、悪天候*3で残念ながら上陸できなかったため、再チャレンジするためにもまた長崎を訪ねたいなと思いました。

長崎駅前の様子荒波から臨む軍艦島CTO Night参加の証
長崎の思い出

偶発性の高いセッション

クローズドな内容もあるため詳細を語ることは出来ませんが、今回も非常に学びのあるセッションが数多くありました。例えば、Diversity, Equity & Inclusionについてはコネヒトの事業柄、より意識して行動していく必要があると感じました。

Web3に関しても様々な議論が巻き起こっていますが、Web3の真のビッグウエーブが来たとき"沖"に立っていられるよう、一人の技術者として要素技術をしっかり理解しておく必要性があると感じたので、手始めにDAppの個人開発をはじめてみようと思いました。

また、CTO Nightのような大規模なカンファレンスのセッションは一方向のコミュニケーションになりがちですが、今回のCTO Nightでは感想戦が用意されていたり、セッション自体もオーディエンスを巻き込んだりしていたのが印象的で、ネットワーキングの時間を含めて偶発的なコミュニケーション機会が多く、対面の良さを十二分に感じることが出来ました。

僕も有り難いことに登壇の機会をいただいたのですが*4、そこでも短時間ではあるものの参加者の方と対話をすることが出来たので、非常に"お土産"の多い3日間となりました。

ちなみに、僕の登壇の様子はAWSの畑さんのレポートにチラッと掲載していただいております。

note.com

3年ぶりの参加で感じたこと

今回、本当に多くのCTOの方が参加しており、良い意味でCTOという役割がコモディティ化しているなと感じました。その中で飽くなき挑戦を繰り返している参加者の方からは良い刺激をたくさんいただきました。一方で、僕も3年ほどCTOを務めて、コミュニティへ還元できる部分も出来てきたので、改めてCTOないしは技術コミュニティを盛り上げていくぞ!という気持ちを新たにしました。*5

というわけで、コネヒトはTech Visionでも「技術コミュニティになくてはならない開発組織をつくる」という方針を掲げているので、他社やコミュニティの方々と手を組んだ形でのイベントも一緒に出来ればと考えています。一緒にやってもいいぞ!という方や少しでも興味のある方はTwitterFacebookまでお気軽にご連絡いただければと思います。

最後に

最高の場を用意してくださったAWSさん、本当にありがとうございました!

DAY1の集合写真(撮影:漆原未代さん)
DAY1の集合写真(撮影:漆原未代さん)

*1:現職はCPOですので、ex-CTOとして参加させていただきました。

*2:もちろん、感染対策は丁寧に施されており、安心して参加することが出来ました。

*3:船の揺れと水しぶきと寒さが本当にヤバかったので、2022年トップクラスの"ハードシングス"でした。

*4:余談ですが、前回の京都開催に引き続きチャペルでの登壇となりました。

*5:個人的には今回改めてSaaS系スタートアップの盛り上がりを感じたので、争うわけではありませんが、toC系のインターネット企業も盛り上げていきたいです。

コネヒトは DroidKaigi 2022 に協賛します!

こんにちは!Android アプリエンジニアの富田 です。

本日は、Android アプリ開発者の祭典 DroidKaigi 2022 に協賛するお知らせです。

コネヒトは DroidKaigi 2022 に協賛いたします!

DroidKaigi 2022に、サポータースポンサーとして協賛いたします。

droidkaigi.jp

スポンサーするにあたって、コネヒトは「人の生活になくてはならないものをつくる」というミッションを掲げているので、技術コミュニティについても同様に、サポートして一緒に盛り上げていくことができたら、と思っております。

イベント概要

  • 日時 2022年10月5日(水)〜10月7日(金)
  • 場所 東京ドームシティ プリズムホール (Day 1, Day 2)、ベルサール飯田橋ファースト (Day 3) および YouTube
  • 主催 DroidKaigi 実行委員会
  • 公式HP https://droidkaigi.jp/2022/
  • タイムテーブル https://droidkaigi.jp/2022/timetable

今回はオフラインでの参加も可能ということで、盛り上がりそうですね!

個人的に楽しみなセッション

全体的に Jetpack Compose のセッションが多い印象で、特に以下の 3 セッションが気になっているのでチェックしていきます!

最後に

みなさん楽しんでいきましょ〜!

コネヒトでは Android エンジニアを積極採用中です!

hrmos.co

オンボーディング改善に機械学習を活用する〜Graph Embedding(node2vec)による推薦アイテム計算〜

みなさんこんにちは。MLチームのたかぱい(@takapy0210)です。

本日は、コネヒトの運営するママリのオンボーディング改善に機械学習を活用した事例のパート2をお話をしようと思います。

パート1については以下エントリをご覧ください(取り組んだ背景なども以下のブログに記載しています)

tech.connehito.com

(おさらい)
今回実施しているオンボーディング改善には大きく分けて以下2つのステップがあります。
ステップ1:興味選択にどのようなトピックを掲示したら良いか?(前回のブログ参照)
ステップ2:興味選択したトピックに関連するアイテムをどのように計算(推薦)するか?

本エントリでは主にステップ2の内容についてお話しできればと思います。
(※本記事で添付している画像に関しては、開発環境のデータとなっています)


目次


はじめに

前回の記事で触れたように、2022年09月時点では以下のようなトピックがオンボーディングで表示され、ユーザーの好みを取得しています。

オンボーディングで表示されるトピック選択画面

ここで選択されたトピックに対して、どのようにしてアイテムを推薦すれば良いでしょうか?

まず最初に考えられるのはルールベースによる推薦だと思います。

ルールベースの推薦

一般的に、機械学習をプロダクトへ導入する際、まずはシンプルなベースラインを作成してそこから徐々に改善していく、というフローを踏むと良いと言われています。

今回も例に漏れず、まずはルールベースのアプローチでベースラインを作成しました。

このルールベースによるアプローチでは機械学習は一切使わず、オンボーディング時に選択したトピックに対して、そのトピックが付与されているアイテム(質問のこと。以降アイテム = 質問として記載します)を新着順に推薦する、というものです。

例えば、「つわり」を選択したユーザーに対しては、「つわり」タグが付与されているアイテムを新しい順に推薦します。

以下にあるように、ママリでは各アイテムごとに紐づくタグデータを保持しています。このタグは正規表現で付与されているため、アイテム本文に該当文字列がある場合に付与されます

ルールベースの課題

上記画像の文章を見ていただくとわかると思うのですが、このアイテムの主題は「保育園」ではなく「仕事」です。例えばこのアイテムが「保育園」に興味のあるユーザーに推薦された場合、ユーザー体験はあまり良くないと考えられます。

このように、単純なルールベースでアイテムを推薦すると、ユーザーが期待しているアイテムとは異なるアイテムが推薦される可能性があり、これが1つの課題となっていました。

これを改善すべく機械学習を用いたアプローチの検証をしていきました。

機械学習を用いたアプローチ

今回は、各タグのEmbeddingが計算できればタグ同士の類似度を計算することができ、そこからタグとアイテムとの類似性も良いものが計算できるのではないか、という仮説のもと、Graph Embedding(後述)を用いて実験していきました。

Embeddingは、レコメンデーションをはじめとして活用できる幅が広いというのも採用理由の1つです。
以下のブログではEmbeddingの様々なメリットが述べられています。

blog.twitter.com

Graph Embeddingとは

Graph Embeddingとはグラフをベクトル空間に落とし込む手法のことで、大きく以下の2つに分けられます

  • ノード埋め込み
  • グラフ埋め込み

詳しく知りたい方は以下の記事が参考になると思います。

towardsdatascience.com

今回はnode2vecというアプローチを用いて、前述した「タグ」の埋め込み表現を計算していきます。
参考にした論文は以下になります。

arxiv.org

node2vecの概略

今回の手法では、大きく分けて以下のステップでノードのベクトルを計算します。

  1. グラフ上をランダムウォークし、シークエンスデータを生成する
  2. 生成したシークエンスデータを学習データとして、教師なし学習を行う
  3. 学習した結果からノードのベクトルを取得する

ざっくり以下のようなイメージです。

https://towardsdatascience.com/graph-embeddings-the-summary-cc6075aba007 より

本論文のオリジナルな部分はステップ1の部分で、「どのようにランダムウォークしてデータをサンプリングするか」という部分にあります。

詳細はGMOさんの記事が分かりやすいので、是非こちらをご覧いただければと思います。

recruit.gmo.jp

node2vecの実装

実際にPythonを用いて実装していきます。

使用データ

今回使用したデータは以下のような形式になっています

  • id:アイテムID
  • tag_id:タグID
  • tag:タグの名称

1つのアイテムIDに複数のタグが紐づいているイメージです

1. グラフ上をランダムウォークし、シークエンスデータを生成する

まずはNetworkXを用いてグラフを生成します。

今回は前述した「タグ」をノードとしてグラフを生成していきます。同じアイテムに紐づくタグがある場合は、それらのノードをエッジで接続してグラフを生成していきます。

ただ、関連性の薄い(自己相互情報量が少ない)タグ同士についてはグラフに追加しないように調整しています。

def create_tag_graph(input_df: pd.DataFrame) -> Any:
    """タググラフの構築
    エッジの重みは、2つのタグ間の点ごとの相互情報に基づいており、次のように計算されます
        log(xy) - log(x) - log(y) + log(D)
            xy は、タグ x とタグ y の両方が付与されているアイテムの数
            x は、タグ x が付与されているアイテムの数
            y は、タグ y が付与されているアイテムの数
            D は、タグの総数
    """

    # Step1: タグ間の重み付けされたエッジを作成する
    pair_frequency = defaultdict(int)
    item_frequency = defaultdict(int)
    tags_grouped_by_qid = list(input_df.groupby("id"))

    for group in tqdm(tags_grouped_by_qid, position=0, leave=True, dynamic_ncols=True, desc="Compute tag frequencies"):
        current_tags = list(group[1]["tag"])
        for i in range(len(current_tags)):
            item_frequency[current_tags[i]] += 1
            for j in range(i + 1, len(current_tags)):
                x = min(current_tags[i], current_tags[j])
                y = max(current_tags[i], current_tags[j])
                pair_frequency[(x, y)] += 1

    # Step2: ノードとエッジを含むグラフを作成する
    D = math.log(sum(item_frequency.values()))
    tags_graph = nx.Graph()

    # タグ間に加重エッジを追加する
    for pair in tqdm(pair_frequency, position=0, leave=True, dynamic_ncols=True, desc="Creating the tag graph"):
        x, y = pair  # タグの組み合わせを取得
        xy_frequency = pair_frequency[pair]  # 2つのタグの組み合わせが両方付与されたアイテム数
        x_frequency = item_frequency[x]  # タグ x を参照しているアイテムの数
        y_frequency = item_frequency[y]  # タグ y を参照しているアイテムの数

        # 自己相互情報量の計算
        pmi = math.log(xy_frequency) - math.log(x_frequency) - math.log(y_frequency) + D
        weight = pmi * xy_frequency  # エッジの重みを設定

        # 関係性の薄いタグのエッジは追加しない
        if weight >= 10:
            tags_graph.add_edge(x, y, weight=weight)

    return tags_graph

# グラフの作成
tag_graph = create_tag_graph(input_df=df[['id', 'tag']])

print(f"Total number of graph nodes: {tag_graph.number_of_nodes()}")
print(f"Total number of graph edges: {tag_graph.number_of_edges()}")
>> Total number of graph nodes: 7276
>> Total number of graph edges: 312634

生成されるグラフは以下のようなイメージです

生成されるタググラフイメージ

次にこのグラフを、前述したnode2vecで提案された手法でランダムウォークし、シークエンスデータを生成します。

def next_step(graph: Any, previous: str, current: str, p: int, q: int) -> str:
    """ランダムウォークで次に進むノードを選択する
    """

    neighbors = list(graph.neighbors(current))  # 近傍ノード
    weights = []  # 重み
    # pとqを基準にして、近傍へのエッジの重みを調整する
    for neighbor in neighbors:
        if neighbor == previous:
            # 前のノードに戻る確率
            weights.append(graph[current][neighbor]["weight"] / p)
        elif graph.has_edge(neighbor, previous):
            # ローカルノードを訪問する確率
            weights.append(graph[current][neighbor]["weight"])
        else:
            # 確率をコントロールして前に進む確率
            weights.append(graph[current][neighbor]["weight"] / q)

    # それぞれのノードを訪問する確率を計算する
    weight_sum = sum(weights)
    probabilities = [weight / weight_sum for weight in weights]

    # 訪問するノードを確率的に選択する
    next = np.random.choice(neighbors, size=1, p=probabilities)[0]
    return next

def random_walk(graph: Any, num_walks: int, num_steps: int, p: int, q: int) -> list:
    """グラフをランダムウォークし時系列データを取得する
    """

    walks = []
    nodes = list(graph.nodes())

    for walk_iteration in range(num_walks):

        # ランダムに最初のノードを決定するためにシャッフル
        random.shuffle(nodes)
        for node in tqdm(nodes, position=0, leave=True, dynamic_ncols=True,
                         desc=f"Random walks iteration {walk_iteration + 1} of {num_walks}"):
            # ノードを選んで歩行を開始
            walk = [node]

            # num_stepsの間、ランダムに進む
            while len(walk) < num_steps:
                current = walk[-1]
                previous = walk[-2] if len(walk) > 1 else None

                # 次に訪問するノードを計算する
                next = next_step(graph, previous, current, p, q)
                walk.append(next)

            walks.append(walk)

    return walks

# ランダムウォークを使って時系列データを生成する
tag_series = random_walk(graph=tag_graph, num_walks=10, num_steps=10, p=2, q=3)

ここで生成されるデータは以下のようなリストとなっています。

node2vecで生成されるデータイメージ

ニュアンスの似ているタグが近傍に存在していることが定性的に見て分かると思います。

2. 教師なし学習でノードの情報をベクトル化する

今回はgensimを用いて、自然言語処理ではおなじみのskip-gramという手法でベクトル化していきます。

tag_embedding_model = Word2Vec(
    tag_series,
    vector_size=100,
    window=3,
    hs=1,
    min_count=1,
    sg=1,
    workers=multiprocessing.cpu_count(),
    seed=42
)

定性的にチェックしてみる

ここまででタグのベクトルが計算できたので、類似タグを見ながらモデルの良し悪しを定性的にチェックしてみます。

つわり

ベビーグッズ

練馬区

生後1ヶ月

定性的には良さそうなベクトルが計算できていそうです。

ランダムシークエンスとnode2vecの比較

ランダムにシークエンスデータを生成した場合と、node2vecの手法でシークエンスデータを生成した場合にできるモデルにどのくらい違いがあるのか?という部分についても簡単に触れておこうと思います。

同じデータを使用し、アイテムに紐づくタグをそのままリストに変換します。(これでランダムシークエンスデータが生成できる)

sequence_df = pd.DataFrame(df.groupby(['id'])['tag'].apply(list)).reset_index()
sequence_df['tag_length'] = sequence_df['tag'].apply(lambda x: len(x))

# タグの数が3個未満のデータは除外する
sequence_df = sequence_df[sequence_df['tag_length'] > 3].reset_index(drop=True)
tag_series = sequence_df['tag'].tolist()

先ほど同様、リスト形式のデータを生成しました。

ここで生成されたデータは以下のようになっています。

ランダムに作成したシークエンスデータ例

このデータを同じようにskip-gramモデルで学習させて、モデルの定性チェックをしてみます。

tag_embedding_model = Word2Vec(
    tag_series,
    vector_size=100,
    window=3,
    hs=1,
    min_count=1,
    sg=1,
    workers=multiprocessing.cpu_count(),
    seed=42
)

左がnode2vecのシークエンスデータで学習させたもの、右がランダムシークエンスデータで学習させたものになります。

つわり

ベビーグッズ

練馬区

生後1ヶ月

「つわり」や「ベビーグッズ」に関してはそこまで差分がないですが、「練馬区」や「生後1ヶ月」といったタグに関しては、大きな差分が見られます。

今回はskip-gramというアルゴリズムを利用している性質上、シークエンスデータで見た時に周辺にくる単語が似ているものであれば、類似度が高くなる傾向にあります。

例えば、ランダムシークエンスデータで生成した「練馬区」ベクトルに関しては、東京都内の市や区が類似タグとして計算されていますが、ここで計算されてほしいのは「練馬区に関連するタグ」なので、node2vecの方が良いベクトルを計算できていることが分かります。(桜台マタニティクリニック / 久保田産婦人科病院 / 練馬病院 はどれも練馬区にあるクリニックであり、大塚産婦人科は練馬区からちょっとだけ離れた場所にあるクリニックです)

ママリで投稿されるデータには以下のようなものも多く、そのままアイテムに紐づくタグを用いてデータを生成すると、どうしても地理的に近くの区や市が類似タグとして計算される傾向にあります。
このようなことが起こる可能性を減らすためにも、今回はnode2vecを採用しました。

タグとアイテムの類似度算出

最後に、タグとアイテムの類似度を計算し、オンボーディングで選択した興味トピックに対して、どのアイテムを推薦するかを算出します。

アイテムのベクトル計算にはSWEMを利用し、アイテムに紐づくタグベクトルから、アイテムのベクトルを算出しました。

これらを用いて、タグベクトルとアイテムベクトルのコサイン類似度を計算し、オンボーディングで選択した興味トピックと類似しているであろうタグが付与されているアイテムを推薦するようにしました。

例えば、2022年09月現在「つわり」を選択したユーザーに対しては以下のようなアイテムが推薦されます。

「つわり」を興味選択したユーザーに推薦するアイテム例

ここではサラッと「タグとアイテムの類似度を計算して推薦しています」と書いていますが、実際はPdMとデータを泥臭く見ながらパラメータの調整などをしていきました。

最終的には以下のようなスプレッドシートが数枚できあがり、どのパラメータで生成されたアイテムが良いのだろうか、というのを定性的にチェックしていきました。

どのトピックを選ぶとどんなアイテムが推薦されるのか?を泥臭くチェックしている様子

結果はどうだった?

抽象的な数値になってしまいますが、アプリインストール初日ユーザーのアイテムクリック系の指標が、ルールベースと比較して1.5倍ほど向上しました 🎉

現在は機械学習のロジックを全ユーザーに適用し運用しています。

最後に

オンボーディング改善の内容は、PyCon 2022でも詳細をお話する予定なので、興味がある方は是非観にきてください! (登壇日時は10月14日(金)の17時10分〜17時40分に決まりました!)

2022.pycon.jp

We Are Hiring !!

コネヒトでは一緒に働く仲間を募集しています!

www.wantedly.com

機械学習に関しては、過去の取り組み事例などを以下にまとめていますので、是非見てみてください!

tech.connehito.com

そして興味持っていただけた方はカジュアルにお話しましょう! (TwitterのDMでもMeety経由でも、気軽にご連絡ください)

AWS Step Functionsに新たに14個追加された関数をいくつか使ってみた

こんにちは、インフラエンジニアのささしゅう(@sasashuuu)です。 本日は最近アップデートされ、新たに14個追加されたStep Functionsの組み込み関数について、いくつか活用事例を交えてご紹介したいと思います。

アップデートの概要

Step Functionsの組み込み関数アップデートに関するアナウンスは以下になります。 aws.amazon.com

また、組み込み関数のドキュメントは以下になりますが、日本語版のドキュメントにはまだアップデートされた関数の情報の記載が見当たらなかったため、英語版の方を貼っておきます。 docs.aws.amazon.com

配列操作、UUIDの作成、JSONオブジェクトの結合など計14個の組み込み関数のアップデートがありました。これらの組み込み関数はASL(Amazon States Language)というStep Functionsのリソースを定義するのに使用するJSONベースの構造化言語に直接追加されているため、そのまますぐにでもStep Functionsから利用することができます。

アップデートされた組み込み関数の種類や挙動に関してはクラスメソッド様が以下の記事で網羅的に取り上げられているので、こちらが参考になります。 dev.classmethod.jp

活用事例

ここからは、具体的な活用事例をご紹介します。 今回ご紹介するのは以下の5つです。

States.UUID

まずは1つめの States.UUID です。これは、v4 UUIDの乱数を返してくれる関数です。

活用事例としては、ワークフロー上で作成するAuroraクラスターとそれに紐づくインスタンスについて、既存リソースの識別子の命名をベースにしたいが、サフィックスとしてランダムな識別子を入れて被らないように命名したいというケースで活用しました。

次のようなイメージです。

  • 既に存在するリソースの命名(Auroraクラスターの識別子)
    • dev-hoge-aurora-cluster
  • あたらしく作りたいリソースの命名(Auroraクラスターの識別子)
    • dev-hoge-aurora-cluster-{ランダムな識別子}

ワークフロー実行時の入力です。

{
    "HogeDbClusterIdentifier": {
        "Identifier": "dev-hoge-aurora-cluster-{}"
    }
}

Pass ステートで States.UUID を使用して、生成した識別子を元の入力を上書きする形で更新します。

    "Pass": {
        "Type": "Pass",
        "Next": "Foo",
        "Parameters": {
            "Identifier.$": "States.Format($.HogeDbClusterIdentifier.Identifier,States.UUID())"
        },
        "ResultPath": "$.HogeDbClusterIdentifier"
    }

Auroraクラスターを作成します。(下記は RestoreDBClusterFromSnapshot を用いたスナップショットからの復元の例です。)

    "RestoreDBClusterFromSnapshot": {
        "Type": "Task",
        "Next": "Pass",
        "Parameters": {
            "DbClusterIdentifier.$": "$.HogeDbClusterIdentifier.Identifier",
            "Engine": "aurora",
            "SnapshotIdentifier": "hoge"
        },
        "Resource": "arn:aws:states:::aws-sdk:rds:restoreDBClusterFromSnapshot"
    }

結果、次のようなUUIDがサフィックスとしてついた識別子のクラスタが作成されます。(※インスタンス作成のステップはここでは割愛。)

dev-hoge-aurora-cluster-a7cae12b-3e92-4c7a-b2f5-07416d023dbc

States.StringSplit

続いては States.StringSplit です。これは、文字列を区切り文字で値の配列に変換してくれる関数です。 何かのパラメータを複数設定したい際などに便利で、活用事例としては、RDSのクラスター作成時のSGなどの指定で利用しました。

ワークフロー実行時の入力です。

{
    "SecurityGroups": "sg-01xxxxxx,sg-02xxxxxx"
}

続いてスナップショットからクラスターを復元する RestoreDBClusterFromSnapshot ステートの定義です。

    "RestoreDBClusterFromSnapshot": {
        "Type": "Task",
        "Parameters": {
          ...
          "VpcSecurityGroupIds.$": "States.StringSplit($.SecurityGroups, ',')",
                  ...
        },
        "Resource": "arn:aws:states:::aws-sdk:rds:restoreDBClusterFromSnapshot",
        "Next": "CreateDBInstance",
        "Catch": [
            {
                "ErrorEquals": [
                    "States.ALL"
                ],
                "Next": "NotifySlackFailureTheOthers"
            }
        ],
        "ResultPath": "$.Hoge"
    },

入力で渡していた SecurityGroupsStates.StringSplit の関数の第1引数に、区切り文字としてカンマを第2引数に与えることにより、API実行時のパラメータの指定を次のように展開してくれます。

    {
        ...
        "parameters": {
          ...
          "VpcSecurityGroupIds": [
                "sg-01xxxxxx",
                "sg-02xxxxxx"
            ],
          ...
        },
        ...
    }

States.MathAdd、States.ArrayLength、States.ArrayGetItem

最後にこの3つの関数の活用事例をまとめて紹介します。 ざっくり関数の性質を説明すると次のような内容です。

  • States.MathAdd
    • 引数に与えた2つの数値の合計値を返す。
  • States.ArrayLength
    • 引数に与えた配列の長さを返す。
  • States.ArrayGetItem
    • 引数に与えた配列とインデックスから対象の値を返す。

この3つの関数は一連のフローで組み合わせて次のようなケースで活用しました。

  1. ワークフローで実行するAPIのresponseのoutputが配列で返る
  2. States.ArrayLength で配列の長さを取得する
  3. 配列データをループ処理にかける
  4. States.ArrayGetItem で対象の配列とCounterとして用意していたパラメータを使用し、インデックスを指定して要素を取り出す
  5. 取り出した要素が処理の対象の要素かどうかを Choice ステートで判定する
  6. 対象の要素一致していなければCounterとして用意していたパラメータを States.MathAdd でインクリメントする、インクリメントが配列の長さに達している場合は処理をループ処理を終了する
  7. 再びループの先頭に戻る
  8. 繰り返し…

実際に簡略化して再現したものが次のようなものになります。

{
    "Comment": "A description of my state machine",
    "StartAt": "DescribeDBClusters",
    "States": {
        "DescribeDBClusters": {
            "Type": "Task",
            "Next": "Pass",
            "Parameters": {},
            "Resource": "arn:aws:states:::aws-sdk:rds:describeDBClusters",
            "ResultPath": "$.Output",
            "ResultSelector": {
                "Length.$": "States.ArrayLength($.DbClusters)",
                "DbClusters.$": "$.DbClusters"
            }
        },
        "Pass": {
            "Type": "Pass",
            "Next": "Choice",
            "Parameters": {
                "DbClustersLength.$": "States.MathAdd($.Output.Length, -1)",
                "DbCluster.$": "States.ArrayGetItem($.Output.DbClusters, $.Counter.Val)"
            },
            "ResultPath": "$.Tmp"
        },
        "Choice": {
            "Type": "Choice",
            "Choices": [
                {
                    "Variable": "$.Tmp.DbCluster.DbClusterIdentifier",
                    "StringMatches": "dev-hoge-aurora-*",
                    "Next": "Pass (2)"
                }
            ],
            "Default": "Pass (1)"
        },
        "Pass (1)": {
            "Type": "Pass",
            "Next": "Choice (1)",
            "ResultPath": "$.Counter",
            "Parameters": {
                "Val.$": "States.MathAdd($.Counter.Val, 1)"
            }
        },
        "Choice (1)": {
            "Type": "Choice",
            "Choices": [
                {
                    "Variable": "$.Tmp.DbClustersLength",
                    "NumericEqualsPath": "$.Counter.Val",
                    "Next": "Fail"
                }
            ],
            "Default": "Pass"
        },
        "Fail": {
            "Type": "Fail"
        },
        "Pass (2)": {
            "Type": "Pass",
            "End": true
        }
    }
}

DescribeDBClusters で全てのクラスターを取得し、先述したようなフローの処理を行なっています。

ワークフロー実行時の入力です。

{
    "Counter": {
      "Val": 0
    }
}

1つずつステートの処理を見ていきます。

最初の DescribeDBClusters ステートでは States.ArrayLength を使用し、 Output.Length のパスで取得したデータの長さを取得、Output.DbClusters のパスで取得したデータを丸ごとを取得し、元の入力と合わせて次のステートに引き継いでいます。

    "DescribeDBClusters": {
        "Type": "Task",
        "Next": "Pass",
        "Parameters": {},
        "Resource": "arn:aws:states:::aws-sdk:rds:describeDBClusters",
        "ResultPath": "$.Output",
        "ResultSelector": {
            "Length.$": "States.ArrayLength($.DbClusters)",
            "DbClusters.$": "$.DbClusters"
        }
    }

次の Pass ステートでは、States.MathAdd を使用し、Tmp.DbClustersLength のパスで本来の配列データから1を引いた数を取得、States.ArrayGetItem を使用し、Tmp.DbCluster のパスで対象のクラスター情報を取得し、次のステートに引き継いでいます。

    "Pass": {
        "Type": "Pass",
        "Next": "Choice",
        "Parameters": {
            "DbClustersLength.$": "States.MathAdd($.Output.Length, -1)",
            "DbCluster.$": "States.ArrayGetItem($.Output.DbClusters, $.Counter.Val)"
        },
        "ResultPath": "$.Tmp"
    }

さらに Choice ステートでは ループ上で絞り込んで取得している対象が dev-hoge-aurora-* というクラスターの識別子と一致しているかをチェックしています。

    "Choice": {
        "Type": "Choice",
        "Choices": [
            {
                "Variable": "$.Tmp.DbCluster.DbClusterIdentifier",
                "StringMatches": "dev-hoge-aurora-*",
                "Next": "Pass (2)"
            }
        ],
        "Default": "Pass (1)"
    }

一致していなかった際は Pass (1) へ移り、用意していた入力のCounterをインクリメントします。States.MathAdd を使い数値の1を追加しています。

    "Pass (1)": {
        "Type": "Pass",
        "Next": "Choice (1)",
        "ResultPath": "$.Counter",
        "Parameters": {
            "Val.$": "States.MathAdd($.Counter.Val, 1)"
        }
    }

もし、ここでインクリメントしていたCounterの数値が、取得していた配列データの数に達した場合は Choice (1) の判定により、処理が終了するようになっています。

    "Choice (1)": {
        "Type": "Choice",
        "Choices": [
            {
                "Variable": "$.Tmp.DbClustersLength",
                "NumericEqualsPath": "$.Counter.Val",
                "Next": "Fail"
            }
        ],
        "Default": "Pass"
    }

以上のように配列の操作系の組み込み関数も強化されているので組み合わせて柔軟に利用することができます。

余談ですが、ループ系の処理に関しては Map ステートという入力配列の要素ごとに一連のステップを実行してくれるものがあるのですが、ループ途中のBreakやそこからループ内の任意のoutputをもとの入力に統合するような実装などが難しいように感じ、今回は上記の組み込み関数を使用し、配列のループ操作を行いました。

おわりに

Step Functionsの組み込み関数が大幅にアップデートされ、ちょっとした計算処理や整形処理などがLambdaなどのリソースを使わなくてもワークフロー上で行えるようになり、非常に便利になりました。みなさんも機会があればぜひ積極的に活用することをおすすめします。

検索システムで再現率向上に取り組んだ話

こんにちは。エンジニアの永井(shnagai)です。

今回は、現在進めている検索システム内製化プロジェクトの中で、検索エンジニアとしてはほぼ未経験に近い自分が半年ほど試行錯誤した内容の一部を書き記していこうと思います。

※筆者の経験としては、Elasticsearch✕kibanaのログ基盤は複数構築経験はありで、Elasticsearch周りの設定への知識は0ではないレベル

この記事を見て、検索に詳しい方や自分もやってみたいという方がいたら是非お声がけいただけるとうれしいです。

内容は、ざっくり下記の構成になっています。

  • 作りながら身にしみた検索システムの奥深さ
  • 初回ABテストでは既存エンジンに惜敗。再現率向上を目指すためのチューニング
  • これから

作りながら身にしみた検索システムの奥深さ

プロジェクトの開始前に、そもそも検索システムを自社で作り運用していけるのかの当たりをつけるために、ママリのデータを使った検索システムのモック作りを開始しました。この時の自分は、暗に「1つの検索クエリに対していかに正確な検索結果を返すか」を解くべき課題と設定し、下記にあるように検索ワードに対して間違いの少ない検索システムを目指してモック作りを進めました。

社内向けのモックを作る際の最初の方針

  • 出来るだけ検索ノイズが少なくなるように
    • OpenSearchの match_phrase クエリを使って検索ワードの順序を厳格に判定
    • kuromojiはnormalモードを利用 ※searchで意図せぬトークン分割されるのを防ぐため
    • 家族ノートという別プロダクトを開発するときに作ったユーザ辞書をカスタム辞書として利用

※検索エンジンとしては、OpenSearchを採用しているのでクエリ等はOpenSearch(Elasticsearch7.10.2相当)のもの

その後、モックが出来上がり社内定性チェックを行い、そのFBを読み解く中で、下記のようなインサイトを得て少しずつ意識が変わってきました。

「検索クエリは検索者の検索意図を必ずしも表したものではない」

「検索クエリぴったりのものでなくても検索意図に合う結果であればよいパターンもある」

「0件ヒットの体験は検索システムとしてはかなり悪い」 ※コンテンツがそもそもなければもちろん許容

つまり、検索クエリは検索者の目的を必ずしも正しく反映したものではなく(自分的には目からウロコでした)、検索クエリからいかに意図を汲み取り次のアクションにつながる結果を返せるかが検索システムの役目ということをだんだんと理解し始めました。

そんな中、「検索システム」という良書をチームメンバが見つけ、検索システム内製化チームで輪読会をはじめました。この本は、めちゃくちゃ良書で今自分たちがぶつかっている課題等が見事に言語化されており毎度チームメンバとうなりつつ検索システムに対する理解を深めている最中です。

特に、「ルックアップベースの検索モデル」には課題があり、「クエリや検索行動」自体を理解する QueryUnderstandingが検索システムを作る上では欠かせないと解説されていて、めちゃくちゃうまく言語化されており自分が抱えていた課題感が腑に落ちたのを覚えています。 何回も読み直しており、めちゃくちゃオススメの良書です。

検索システム ― 実務者のための開発改善ガイドブック(電子書籍のみ) – 技術書出版と販売のラムダノート

初回ABテストでは既存エンジンに惜敗。再現率向上を目指すためのチューニング

「ルックアップベースの検索モデル」は、自分の中では出来るだけ間違いの少ない検索システムと捉えており、その方針で作った検索システムで最初のABテストに望みました。

結果、KPIに設定していた検索CTRの有意差判定で既存検索システムに負けてしまいました。

当初の検索システムは間違いを少なくするために適合率高めに設定していたのですが、検索ログから出した数値やユーザからのFBから再現率が低すぎる傾向が読み取れました。

適合率と再現率については、下記のelastic社のブログが詳しいのでこちらをご参照ください。

How to implement Japanese full-text search in Elasticsearch

www.elastic.co

さて、再現率向上のためのアプローチですが、ここではわかりやすい2つのチューニングについて説明していきます。

※一般的というよりはコネヒトの環境独自のチューニングの観点が大きいのでその点はご了承ください。

カスタム辞書のチューニング

ユーザからのお問い合わせベースで調査していると、地名を含めた検索で意図した検索結果になっていないことが見えてきました。

  • 地域名を入れた検索クエリで、検索結果が返ってこないケースがたまにある
    • 例)「厚木」では「厚木市」のドキュメントが当たらない

これは、別プロダクトで作ったカスタム辞書で市区町村が細かく定義されており、それをそのままKuromojiのカスタム辞書として利用していたことが原因でした。

わかりやすく、具体例で説明すると

厚木市の保育園 という文章をKuromojiで形態素解析すると

  • 【本来の形】 厚木/市/の/保育園 と分割され、厚木市 厚木 どちらでも検索にヒットする
  • 【ABテスト時点】 厚木市 というカスタム辞書が優先されるので、 厚木市/の/保育園 と分割されてしまう。結果、 厚木 という検索ワードでは厚木市の保育園 というドキュメントがヒットしない状況になっていました。

元のカスタム辞書は、BigQueryに独自の転置インデックスを登録するために作った辞書で、細かい単語を定義することに価値があったのですが、OpenSearchのKuromojiの辞書としてそのまま転用すると思わぬ落とし穴があったなという所感です。

地名系をカスタム辞書から一通り除外して、例のような検索クエリにドキュメントが返ることを確認しました。

Kuromojiのmodeをnormalからsearchに変える

日本語形態素解析エンジンとして、Kuromojiを使っているのですがモードを当初は normal にしていました。

詳細は、下記が詳しいのですが、複数の単語が組み合わさった単語をいい感じに分割してトークナイズしてくれるモードとのことで、再現率向上の観点から search モードを採用しました。

kuromoji_tokenizer | Elasticsearch Plugins and Integrations [7.10] | Elastic

www.elastic.co

上記2点のチューニングを行い、改めてABテストを実施したところ、再現率が向上とKPIにしているCTRで既存エンジンと有意差なしまで持っていくことが出来ました。

これから

今後、オートコンプリートや関連検索の提案等の複数検索機能も含めた検索システムを通して、よりママリの検索がユーザの悩みや課題解決につながる機能となっていくよう開発をしていこうと思います。

難易度が高くなるランキング周りの話やカスタム辞書のさらなるチューニング、シノニム(同義語)の整備、 QueryUnderstanding をチームで進めるためのログやモニタリングの整備等、検索めちゃくちゃやること多いなわくわくするなという思いをチームメンバはもっており、今後も走りながら進めていき、少しずつ事例も紹介していければと思っています。

最後にコネヒトでは検索システムを一緒に開発してくれるエンジニアを募集しています。

下記の募集以外にもポジションありますので、少しでも興味もたれた方は、是非気軽にオンラインでカジュアルにお話出来るとうれしいです。

https://hrmos.co/pages/connehito/jobs/00n

hrmos.co