研究開発職

 

応募要項はこちら

研究員

 

R&D DevOps/MLOpsエンジニア

データエンジニア

 
 
 
 
 

研究開発部メンバーの連載記事

研究開発部の技術

 

研究開発職に関する記事

coremltoolsを用いたCore MLモデルへの変換 - Sansan Tech Blog
研究開発部Architectグループの堤です。最近は研究開発部の技術や成果物について紹介する記事を いくつか書いてきた のですが、 今回は、下記記事で紹介した"Smart Captured"（略してスマキャプ）の開発の中で行った「Core ML化」について深堀りしたいと思います。 buildersbox.corp-sansan.com 上に載せた記事内で、スマキャプでは以下の機械学習モデルの推論処理をオンデバイスで行っている、と書きました。 名刺検出（名刺の矩形を検出） 名刺切り出し（セグメンテーション） それぞれのモデルはTensorFlowで学習しています。 さらにiOSでは、モデルをCore MLに変換することで、 大幅なパフォーマンス向上 に成功しています 。 矩形検出は300%高速化（18 fps → 55 fps） セグメンテーションも推論時間は0.01〜0.02[s] さらに、機械学習モデルの推論処理のためのCPU負荷が下がることで、UIの描画やユーザーインタラクションのレスポンスも改善されます。下図は、変換前・後のモデルを切り替えてCPU使用率を可視化したものになります。 本記事ではこの Core ML化の具体的な手順や勘所 について、詳しく解説します。 そもそもなぜCore ML化すると速くなるのか、について解説しておきます。 Core MLは、機械学習モデルをiOS, macOS, watchOS, ...に組み込むためのApple製のフレームワーク, モデルフォーマットなのですが、 iOSで機械学習モデルの推論処理を行うための選択肢はCore ML以外にもいくつかあります。 TensorFlow for iOS (TensorFlow Mobile) TensorFlow Lite PyTorch Mobile (LibTorch) ただし、 TensorFlow for
https://buildersbox.corp-sansan.com/entry/2022/11/25/110000
hypothesis+panderaで始める、データフレームに対するProperty Based Testing - Sansan Tech Blog
技術本部 R&D研究員の前嶋です。 梅雨の季節ですが、少しでも快適に過ごせるようにOnのCloud 5 wpを購入しました。水に強くて軽快な履き心地で最高ですね。(追記：この記事の公開作業をしている間に梅雨が終わってしまいました) 今回は、データフレームのテストについての記事です。 データが中心となるサービスのネックになるのが テストをどう書くか です。というのも、データフレームは行×列の構造になっているため、入力あるいは出力値がデータフレームになるような関数が多いプログラムでは、テストケースを書くのが非常に面倒です。仕様の変更があった場合、それぞれのテスト用の疑似データに修正を加えることを考えると、より簡潔にデータフレームのバリデーションをする方法が欲しいところです。実は、データフレームのテストはProperty Based Testingという考え方と非常に相性が良いです。今回の記事では、 pandera と hypothesis ライブラリを活用した、データフレームに対するProperty Based Testingの方法を紹介します。 Property Based Testing(PBT) は、Haskellの QuickCheck で導入された概念だと言われています。一般的なExample Based Testing、つまり、ある値を入力したときの出力値(と状態)を検証するテストとは異なり、Property Based Testingは、入力値あるいは出力値が特定の属性(property)を満たしているかを検証します。例えば、自然数を整数倍する関数があったときに、その出力値は整数という属性を満たしている必要がありますが、入力値でさまざまなパターンで試してみて、結果が整数にならない場合はその例を返します。 契約による設計(Design by Contract, DbC)を実現するテスト手法として、名著『達人プログラマー』でも推奨されています。 hypothesis は、PythonでPBTを行うためのライブラリです。 hypothesis.readthedocs.io import hypothesis from hypothesis import strategies as st テストケースを生成する戦略(strategy)を定義します。例えば st.integers() はint型から生成を行い、 st.text() は文字列からの生成を行います。 example() メソッドを使うと、戦略に沿って具体的な例を1つ生成します。 >>> st.integers().example() 110 いくつか同時に例を生成してみます。 大小さまざまな値が生成されていることが確認できます。 ここから実際にテストをしていきます。例として、整数型の入力値を2乗する関数を作ってみます。 特定の戦略に沿ってテストケースを生成する、ということを指示するためには、テスト用の関数に @hypothesis.given デコレータを付与します。今回はテストフレームワークにpytestを、ipytest経由で使っています。 %%ipytest @ hypothesis.given(st.integers()) def test_square_int(num): assert type(square_int(num)) == int test_square_int() 実行結果 .
https://buildersbox.corp-sansan.com/entry/2022/08/10/110000
gokart の環境変数周りでバグを発見したので、修正 PR を出したら爆速でリリースされた話 - Sansan Builders Blog
こんにちは。技術本部 R&D 研究員の青見です。 4月で社会に出て1年になりました。 この時期は花粉症が辛くて記憶がくしゃみにかき消されがちですが、入社式のやっていきを思い出して2年目も頑張っていきます。 さて、 R&D では積極的にパイプラインツールを使って開発しようという流れになってきており、その1つとして gokart を利用しています。 gokart は Luigi という Spotify が開発している Python のパイプラインライブラリのラッパです。 特徴として機械学習利用のパイプラインに特化しており、再現性の担保という観点では非常に Luigi と比べて使いやすく感じます。 gokart と Luigi について詳しくは同じチームの髙橋が連載で紹介しているので、ぜひそちらを御覧ください。buildersbox.corp-sansan.com 今回は実際に使用していた gokart においてバグを発見したので修正の PR を出したところ、マージ後高速でリリースされ、即座に業務で利用することが出来たという話をします。 Luigi や gokart では処理の一つひとつをタスクという単位でまとめ、パイプラインとして実行します。 このタスクやパイプライン全体に対してパラメータをうまく扱う仕組みがあり、これらのパラメータを設定ファイル (.ini ファイルなど) として管理することが出来ます。 パラメータに関する設定ファイルは、 Python built-in の configparser に準拠しており、以下のようにセクション単位で機能やタスクのパラメータを管理します。 [TaskOnKart] workspace_directory=./resources local_temporary_directory=./resources/tmp [core] logging_conf_file=./conf/logging.ini [TaskA]
https://buildersbox.corp-sansan.com/entry/2022/04/07/110000

Sansan エンジニアに関する記事

 

Sansan株式会社について

 

Sansan Tech Podcast

当社のエンジニアがお届けするPodcastです。Sansanエンジニアの技術のこと、カルチャーのこと、日々のSansanライフについて自由に語っています。