ElasticsearchのSearchTemplate - はてだBlog（仮称）
Elasticsearchには、Search Templateという、よく使うクエリをElasticsearch自体に登録して、それをテンプレートにして検索クエリの一部を差し替えたような検索ができます。 使い所によって、共通化、タイプ量削減、設計方針の強制、コンセプトの共有、いろいろな捉え方ができると思います。 テンプレートのフォーマット指定は、mustache風です。 www.elastic.co 私の中では、存在は知っていたものの、（後半に示しているJSONをパラメータに受け取ってそのままプレースホルダーにはめ込みできるというところが特に）再発見でしたので、勉強メモとしてこちらにサンプル例を書き連ねてみます。 確認に使ったElasticsearchのバージョンは ver6.8です。 もっともシンプルな例 いろいろな例 001（オーソドックス：検索ワードの当てはめ） 002 (001と同
Elasticsearch 日本語ドキュメント用 analyzer設定generator(Analyze設定のマイフェイバリット2020) - はてだBlog（仮称）
ちょっとタイトルは内容からすると主語というかスコープがでかすぎです。ご了承ください。 過去に次のような記事を上梓させていただいております。 itdepends.hateblo.jp itdepends.hateblo.jp ただ、いろいろやっていると、多少気分も変わることもしばしばです。 マイフェイバリットの軸はかわらないものの、今日はこんなフレーバーかな?と、横道にそれることもあります。 その際に、エディタによるJSON編集のサポートがあったとして、それでも、自分の中の秘伝のタレのごとき、mappings、settingsをごちゃごちゃやるのが、どうも苦痛になってきました。 そこで、PythonのdictとJSONの響きが似ているような気がする...というのはちょっと乱暴ですが、少なくとも形が似ているような気がするので、マイフェイバリットの最新版をPythonのコードに寄せて管理しようと
Pandas（他）のEDA前によく使う（かもしれない）私的前処理スニペット集 - はてだBlog（仮称）
はじめに データサイエンス的な世界に限らずですが、本処理以上に「前処理」が勝負というところがあります。 ここで、「本格的な『前処理』の更に前段の『前処理』が必要になった」という経験はありませんか。 まあ、単なる言葉遊びに過ぎないところもありますが、普通の「前処理」が、「使い物になるめどがあるデータを使いやすい形に加工する」だとすると、「『前処理』の『前処理』」は「そのデータが使い物になる可能性があるのかを見極める調査」というところでしょうか。 データサイエンスの分野だとEDA（探索的データ分析/解析)と呼ばれる（らしい）範囲の活動にあたるのかな。 ... と話を膨らませておいて言うのもなんですが、別にデータサイエンスでなくて、ある既存アプリの改善プロトタイプの検討なんかでも、よくある話だと思いますし、むしろデータサイエンスど真ん中でない分野で発生する似たようなケースの方が 人間の業のような
Pandas pivot、pivot_table、melt、stack、wide_to_longのシェイプ変更のイメージ(tidyデータ) - はてだBlog（仮称）
PandasにおけるDataFrameのシェイプ変更のメソッドである、 pivot、pivot_table、melt、stack、wide_to_longについて、これらをまとめて図解してみました。 実例 import pandas as pd import io df = pd.read_csv(io.StringIO(""" year,season,num 2010,春,4 2010,夏,1 2010,秋,2 2011,春,3 2011,夏,4 2012,春,1 2012,冬,2 """ )) ## pivot _ = df.pivot(index='year', columns='season', values='num') _ _.index ## pivot_table import numpy as np _ = pd.pivot_table(data=df,index='ye
Elasticsearchのひらがなでの検索時のトリックについて雑談 - はてだBlog（仮称）
はじめに Elasticsearch(kuromoji)では、アナライザーに「kuromoji_readingform」というものがあり、これを使うと「読み」に関して、表記揺れや曖昧検索相当に対応できます。 ただし、この「読み」部分については、実は、kuromojiの形態素解析(分かち書き/token化)とセットになる話なので、一番ベーシックなアナライズの設定組み合わせの範囲では実は次のようなことが発生します。 「渡辺」「渡邊」のような「端」「橋」のような、（そのようになるように検索クエリを用いれば）期待どおり互いに検索時にヒットする 一方で、 ひらがな「わたなべ」で、漢字の「渡辺」や「渡邊」を（ただしく読めていると思われるにもかかわらず）これらをヒットさせられない これは、「読み」は当てられているものの、形態素解析でトークン化されたものに対して、転置インデックスの各エントリに対して当ては
BM25を分かった気になるかもしれない邪道な解説(?) - はてだBlog（仮称）
1. はじめに このブログではElasticsearchについて時々思い出したように書きなぐっております。 そしてこの記事では、Elasticsearchのデフォルトのスコアリング方式であるBM25について、数式が苦手でも、なんとなく分かった気になる（かもしれない）解説を試みてみます。 邪道に徹しておりますので、(私自身もそうですが）できれば数式を見たく無い人向けに「デフォルメ」した言い方をしているところもあります。 この点をご容赦いただくとともに、デフォルメを超えて間違っているじゃんというところがあればこっそり教えてください。 正攻法や、数学的・情報科学的に正確な手法としての説明をお求めの方は、末尾の参考リンク先などをあたってください。 2. BM25やTF-IDFのアイディア BM25やそのある種前身であるTF-IDFについて、使う側の立場としてこれらの手法を理解するには、どのようなド
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
