  |
関連性で推薦すればCTRが最大化されると思ったが、そう単純ではないらしい
状況によっては、関連性の高い情報ばかり表示するとユーザーが飽きてしまい、関連性スコアが低めのものがクリックされたりする
そこで、ノベルティやダイバーシティといった複数の指標を考慮すると、よりCTRを増やせる可能性がある
閲覧履歴を保存していれば、そのいくつかを何らかのルールベースを用いて結果から除外する形でノベルティを増やせる
ダイバーシティを増やす方法は、検索結果をパチンコ台みたいに複数の台を用意しておき、それぞれの台から結果を抽出するような方法が使える
forループからなる処理があり、データに対して、条件に合致する行にスコアを与え、スコア判定されたものは(id, score)というペアを出力し、それ以外のデータはリストにまとめて返す、という処理がある。
このパターンが6回ぐらい連続で続いていたが、条件合致部分が複雑で、処理が一致していることに気が付かなかった。
処理が一致していることに気がついて、abstractメソッドに実装(条件合致部分)を与えるという方式にして抽象化したらコードがスッキリした。
SQLは構文はわかっていても、最適化方法がイマイチわからない言語である
そこで、こういうことはCopilotに全部聞いてしまう
粗結合性から見るとアンチパターンだが、コードの見やすさは上がる。
#改善前 def honya1(a,b,c,d,e,f,g,h,i,j,k,l,m,n): (処理) #改善後 def honya2(**kwargs): (処理)
追記: 文脈がわかってないようなので書く。これは、どこかの計算で使われた集合を複数個(a,b,c,d,e,f,g,...)引っ張ってきて直積にする算術。最初は2つだったので良かったが、徐々に必要な直積が増えていき、その分だけ引数を定義していた。しかも任意個なのでNoneを与える部分もあった。*argsか**kwargsを使えばもっと簡単にかけるはず。
レコメンダシステムの理解が進んだ段階では、その仕組みを汎用化して、入力パラメータで挙動を変えられるようにできていると仮定する
A/Bテストを行うために必要なのは、まず入力パラメータとユーザーアクションの組を保存することである
目標の設定から始める必要があるが、ここではクリック率を追うと仮定する
これだけでは比較が出来ないため、検証対象のパラメータAとBを同頻度でユーザーに適用する
この適用方法は色々ある。ランダムに切り替える方法もあるし、ユーザーを2つのグループに分ける方法もある。この適用時に、サンプルサイズを決めておく
それで、ある程度の期間データを収集するが、期間をちゃんと決めておく。大体1〜2週間ぐらいになることがおおい
期間が過ぎたら、まずAとBのアクションの統計的推移をEDAとしてプロットするとはっきりと傾向を見て取れる
また数値的な比較として統計的検定を実施するのも方法の一つである
結果的に、どういうパラメータ設定であればよりクリック率が増えるのかを明確にする
テスト結果をどのようにフィードバックし、次に進むのかを計画する。得られたデータを基に仮説を再構築し、継続的に改善を行うサイクルを確立する
その処理は、例えばメールを大量に処理するようなものだったりして、速度が要求される。
こういう場合は、処理するべきメールとログ（およびそれに必要なデータ）をジョブキューに突っ込んでいき、必要な前処理は全て済ました状態で一気にデキューしていくのがいい。
ただしこの方法を使用するには、ジョブキューの管理や並行処理の管理など、いくつかの追加的な技術が必要になる。
またシステムのリソースも考慮に入れる必要がある。例えば、メモリやCPUの使用量など。
このようなアプローチは、高速なレスポンスタイムが求められるシステムや、大量のデータを効率的に処理する必要があるシステムでよく使用される。
ジョブキューを使用してバックグラウンドで時間がかかるタスクを処理することで、ユーザーに対するレスポンスタイムを短縮し、システムのパフォーマンスを向上させることができる。
高速化のためといい、前任者がcythonで書いたランダムフォレストのコードがあり、どういうわけかsklearnよりも数倍速い
社内ではリランキングモデル(LTR)のためにこのランダムフォレストを使っているらしい
というのも外部ライブラリに頼ると面倒なことになるという認識が開発当初にあり、開発に関係するライブラリは全て自前で書いていたようだ
しかし前任が去ったことでこの最適化に最適化を凝らしたようなモジュールの理解が誰もできない
誰かにプロトタイプを使ってもらって「入力Aに対して出力Bが得られる例はない？」などと言われることがあるだろう
例えばレコメンダシステムでは、ユーザーの行動を入力としてアイテムを出力する
「こういう行動をした場合と、してない場合で、こういうアイテムの違いが想定されて欲しい」という要望が出てくるのである
そういう場合は、可能な行動の組み合わせを全て網羅して、それらを関数に自動的に入力し、その出力をファイルとして出すなどして見てもらって自動化したほうが良い
要するに、プロトタイプをポチポチ触るだけでは効率が悪い場合は、入力の組み合わせを自動入力してしまったほうが早いわけである
もし出力に条件があれば、その条件をフィルタリングすることも可能だろう
そのため、自動化が必要かどうか、またどの程度の自動化が適切かを判断するためには、テストの目的と範囲、そして利用可能なリソースを考慮することが重要
モデルAは特徴量を10000個使っていたが、追加で4000個の特徴量を付与したモデルBを作ったとする。
モデルAとモデルBをテストデータを使ってテストすることも可能だが、使用感を確かめるなどの目的の場合は、入出力を明確化してデモにするとわかりやすかったりする。
例えばそれは「検索エンジン」のモデルだったりするわけだが、モデルAとBを切り替えるボタンを検索エンジンのデモに用意しておき、検証可能にしておくのである。
具体的には、検索クエリを入力し、その結果をモデルAとモデルBで比較できるようにするということだ。
それにより、各モデルがどのように異なる結果を生成するか、また新たに追加された特徴量が結果にどのように影響を与えるかを直接確認できる。
ただし、このデモを設計する際には、結果を解釈するのを助けるために、各モデルの主要な特徴と動作原理についての説明も提供する。
それで、上司にデモを見せる。上司がモデルが失敗する細かい条件を見つけ出し「ダメだよ君ぃ、こんなものをTrueにしちゃうようじゃ」と言う。
これは不毛なやり方である。いつまで経ってもモデルにOKサインが出なくなる。
たまに次のような書き方をする人がいるかもしれない。
result = f(g(x, h(y)))[0]
これはエラーメッセージをわかりにくくするのでおすすめできない。例えばIndexErrorが出たとして、どの部分のエラーかパッと見てわかりやすいだろうか。
以下のようにするべき。
z = h(y) tmp1 = g(x, z) tmp2 = f(tmp1) result = tmp2[0]
いきなり本格的な広告管理ツールを作るためにデータベース設計するのではなく、最初は簡易的なプレーンテキスト形式の設定ファイルで管理するところから始める。
そうすれば当面の間はその簡易機能で対応できるし、対応の速度も早い。
広告管理のスケールが大きくなってきたと感じたところで広告管理のCRUDを設計するのでも遅くはない。
ただし、このアプローチを採用する際には、将来的にデータベースに移行することを見越した設計をすることが重要。
具体的には、設定ファイルの形式を選択する際には、データベースに容易にインポートできる形式を選ぶこと、また、データの整合性を保つための適切なバリデーションルールを設けることなど。
