{デラング}{進捗記録}{交度}{デライト}{`whr_kw()`}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...=}(70)

{希哲15年8月23日7歩 K#F85E/A-E74C-ECC6}

全知検索整備についての検討終了

全文検索にはとりあえず pg_bigm採用しておくことにした。知名検索でも中間一致検索性能課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse()組み込み函数として提供されるようになっているので問題ないだろう。

後縁実装どうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能実装したい。これに関しても,だいぶまとまってきた

カンマAND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難&AND で AND 検索,|OROR 検索対応することにした。除外検索条件次第- を使えるようにしてもいいだろう。

部分一致検索については,省略記号 ...ダッシュ記法応用した ---対応する。

描写検索については,基本的には昨年7月27日3歩方針踏襲し,末尾に ?? を加える形で対応することにした。デラングとの兼ね合い検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。

一つの可能性として,検索ボタンダブルクリックダブルクリック検索対象切り替える機能があってもいいかもしれない。

いずれにせよ,まずは既存の検索語変換交度whr_kw()まとめる作業から始めることになるだろう。

=}
{一日一文}{Google 検索}{分かる}{デライト}{希哲15年5月の一日一文}{Qt: デライトは見出しが無くても困らない}{検索品質}{気に入った}{全てを知る}{名付けた}...=}(114)

{全知検索について K#F85E/A-E74C-4287}

個人知識管理(PKM)サービスを「知能増幅(IA)サービス」に発展させ,まずは Google に代表される検索演心エンジンと,Facebook に代表される SNS からいわゆる GAFAM切り崩す……これがデライトの成長戦略だ。

既存の SNS に対する「KNS(knowledge networking service)という概念については比較的よく語ってきたが,既存の検索演心に対する「全知検索(full-knowledge search)については十分に語ってこなかった。デライトを使い始めた人がまず戸惑う部分でもあるので,考え方だけ簡単説明しておきたい。

全知検索というのは,各輪郭に付けられる知名輪郭名対象とする検索のことだ。一般に「ページ名」などと呼ばれる部分を主な検索対象とするわけで,一見不便なようにも思えるだろう。

ただ,輪郭同士の関連付け柔軟性利用することで,慣れてしまえばさほど問題なく,面白い検索体験が出来るようになっている。検索語から繋がる情報手作りしているような感覚とでも言えばいいのか,これは開発者である私にとっても意外なことだった。


実は,デライト基礎になっているデルンという CMS実用化した当初,当たり前のように全文検索(full-text search)基本にしていた。しかし,使い込んでいるうちに,これはこれで問題があることに気付いた

デルンは,これまでに無い手軽さ大量情報を相互に結び付けられるように設計された。頭の中にある情報を,輪郭同士の立体的入れ子関係で表現する。その関係をひたすら作っていくことが使い方基本だ。

ある言葉について検索した時,その言葉について何を考え,それが何と結び付いているのか,これがまずデルンの検索で得たい情報になる。ところが,全文検索では余計な情報が引っかかり過ぎてしまう。少し言及しただけの輪郭も引っかかるので,それを一覧でざっと見てからその検索語について新しく描出投稿するかどうか考える必要がある。これは,デルンの使い方を考えると明らかに遅かった

そこで,いったん知名だけを対象にしてみた。すると,最初にイメージした検索語を打ち込んで,それが有るのか無いのか,瞬時分かるようになった。その知名を持つ輪郭に関連する輪郭を関連付けていく,というデルンにとって本質的作業と非常に相性が良いことにも気付いた。

これを用者ユーザー認知に基いた全く新しい検索手法として「全知検索」と名付けたわけだ。「全てを知る」と見せかけて,実は無知自覚させるという「無知の知」的な皮肉を感じさせるところも気に入った

全文検索は本文にある情報検索出来るが,逆に言うと,本文に無い情報は検索出来ない。

例えば,画像のようにそもそも文字情報を持たない献典コンテンツのようにあえて直接的表現を避けた文章,内容を書き換えたくないがこの検索語で引かっかって欲しいという古い文章……こういったものにも,全知検索であれば検索の道筋を作ることが出来る。

Google 検索ですら長年解決していない検索ノイズ問題にも有効手段となりうる。

これまでの検索というと,機械が抽出した情報から,人間が要らないものを指定していくという,いわば「ブラック リスト検索」だった。全知検索では,最初から人間が結び付けたい情報を指定しておく。いわば「ホワイト リスト検索」だ。


……全知検索の考え方は大体こんなものだ。

ただ,デライトでも全文検索実装しないと決めているわけではない。補助的にあれば便利なのは間違いないので,何らかの手段で全文検索も出来るようにはするつもりだが,あまり優先順位は高くない。

結局,慣れてしまうと全知検索でも十分引っかかりやすいように書くようになるし,現状,誰よりもデライトを使い込んでいる開発者があまり必要を感じていないのだ。

全文検索に無い利点がある上,全文検索と比べてはるかに低負荷で動き,慣れてしまえば全文検索が無くても困らない実用性がある。これはもう検索においてページランク級の一大発明と言っていいのではないかと思っている。

ウェブ検索という分野では,Google ですらページランク以上の革新を生み出せず,継ぎ接ぎ対策検索品質を保っているのが現状だ。

全知検索には,かつてページランクがそうしたように,ウェブ検索を原理からひっくり返す可能性がある。

{進捗記録}{`dg_fnd()`}{fnd()}{希哲13年12月16日の開発}{検索対象}{希哲13年12月16日の進捗時限}{希哲13年12月16日の進捗}{希哲13年12月16日}{DG_T::fnd()}{進捗時限記録}...=}(23)

{希哲13年12月16日4歩 K#F85E/A-5B28-7CD6}

出場周辺の理腑新知番実装換装,xpo.Pg 修正続き。

fnd_oln()名称について再検討する過程で,これまで感覚的に使い分けていた交単語 schsearch)と fndfind)の違いについても再検討。〈search〉過程〈find〉結果に注目した表現だが,やはり検索対象検索結果の対応が明確な機能については〈find〉で表現した方が自然に感じるため,これまでの使い分けを踏襲することにした。

DG_T::fnd() に合わせ,外充て函数 fnd_oln() は dg_fnd() へ,qy::fnd_oln() は qy::fnd() へ改称することを決めて終了。

=}
{検索対象}

{}