検索システムを適切に評価したい - Qiita
情報検索・検索技術 Advent Calendar 2021 の22日目の記事です。 Motivation 検索エンジニアはバックエンドエンジニアのサブセットだと見なされることがありますが、ある程度の規模のプロダクトに携わる検索エンジニアの業務内容は新しい機能やAPIを作るというよりも、典型的な検索アプリが持っているSearch API、Auto-Completion API、Query Suggestion APIのような、すでに実装されているAPIのインタフェースを変えずに中身を変えることが多いという点で、バックエンドエンジニアとは少し違うと思っています。私自身も過去数年で新しい検索のAPIを書いた回数は片手で数えられるくらいですが、代わりにオフライン・オンラインの実験を毎日しているといった感じです。 このように検索エンジニアは新しいアルゴリズムを提案、比較、そして実験を通してベースラ
クランフィールド検索実験から2019年のニューラルモデルまで - Qiita
このテーブルからクエリが「quick」ならDoc1が「news」ならDoc2が「fox」なら両方の文書が関連しているドキュメントとして候補になることがわかります。ドキュメントを絞り込んだ後どのように並べるかですが、おおまかに分けるとクエリと文書をベクトルに変換して類似度を比較するVector Space Modelと、関連度を文書とクエリが与えられたときの条件付き確率 $P(rel \mid q, d)$ と定義するProbabilistic Modelがあります。その中でも70年代に発明されたBM25というアルゴリズム ("Best Matching" の頭文字) はElasticsearchに採用されていることもあり広く使われているので、検索に携わっている方ならば一度はこの式を見たことがあるのではないでしょうか。 $$ BM25(q, d) = \sum_{t_{q} \in q} i
LeakCanaryでメモリリークを検出する - Qiita
Squareがメモリリークを検出するライブラリ square/leakcanary を公開したので、さっそく使ってみたらすごく便利だった話です。 A small leak will sink a great ship Piwaiが書いたLeakCanaryの記事がこちらです。 LeakCanary: Detect all memory leaks! 要約すると、 Squareではビットマップキャッシュに顧客の署名を書いていたが、端末の画面のサイズ分のメモリを確保するので、署名をするときにクラッシュすることがあり、それがOOMの大半を占めていた。 Bitmap.Configを変更したり、OOMをキャッチしてGCを走らせたりしたが、問題の解決には至らなかった。 我々は間違ったアプローチを取っていたことに気が付いた。ビットマップの大きさではなくメモリリークが根本的な原因だったのだ。 通常であれば
RxJavaでモデルを取得、キャッシュ、ページネーション、そして - Qiita
これらの一連の実装をどうするか考えていた。 前提 REST APIを使っている APIはデータモデル+メタデータを返す モデルはメモリキャッシュ、ファイルキャッシュにも対応する モデルとレスポンスの形式 メタデータの中にはページ情報など、サーバ/クライアントでデータをやりとりするのに必要なデータが入っている。 メタデータはモデルの外に持たせたいので、モデル層をResponseクラスでラップした。ここにページネーションのしくみを持たせることにする。 public class Response<T> { private T result; private Extra extra; private Observable<Response<T>> next; public T getResult() { return result; } public Extra getExtra() { retu
RxJavaでAPIクライアントを作る - Qiita
RxJavaのモチベーション HTTPクライアントは今ならOkHttp一択なのですが、APIクライアントには非同期に通信をおこなってほしいものですが、非同期処理をおこなうAndroidフレームワークのAsyncTaskやAsyncTaskLoaderは正直使いやすいとは言えません。Volleyは設計は綺麗で拡張もしやすかったのですが、Googleとしての立ち位置がよく分からなかったので OkHttp + 非同期処理を担う何か を探していました。 それでPromiseライクなBoltsと迷ったのですが、個人的な好みでRxJavaを採用してみました。 APIクライアントの設計 以前書いたもの の参考実装としてライブラリを書いてみました。 Octodroid リソースへのアクセスの仕方は以下のようになっています。 // GET /users/rejasupotaro GitHub.client(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
