{新生デライト}{『希哲日記』}{御しやすい}{希哲15年8月24日}{考え尽くした}{救われてきた}{何度となく}{上手く行っている}{追いつかない}{乗っている}...=}(75)

{希哲15年8月23日の日記 K#F85E/A-E74C-979F}

開発では全知検索整備についての検討急進展し,新生デライト全文検索など一通り検索機能盛り込める見通しとなった。

新生デライト開発デライト収益目標達成も,日に日に展望明るくなり,期待感も高まっているが,一方で,不思議な不安もある。

これは恐らく,意思思考齟齬の大きさによるものだろう。今月は,先月まとまった新生デライトの要件実装する作業没頭するつもりだった。ところが,実際にはここまで検討作業がやたら捗るばかりで,実装作業はほとんど進んでいない

振り返ってみれば,無闇手を動かすより考えるべきこと多かったのも確かだ。それによって困っているかというと,まだ気持ちのゆとりもあり,総合的状況はむしろ良くなっているようにすら思える

結局,意識出来ないほど膨大情報を,意識が追いつかない速さ処理させているということなのだろう。これだけ想定外のことをしていながら,なぜ上手く行っているのか,もはや自分でも分からない

今日の全知検索整備検討にしても,やろうと思って始めたわけではなく,なんとなく考え始めたするするまとまった。本当は輪郭選り手整備を進めたかったが,結果をみれば確かにこれで良かったと認めざるをえない。

こんなことは過去にも何度となくあったし,それに救われてきた。しかし,景色がどれだけ良くなっていようと,何度経験していようと,全く自分言うことをきかない乗っているのは不安なものだ。ましてやこれまでにない山場でだ。とにかく心臓に悪い

そろそろ考えるべきことはほぼ考え尽くしたはずなので,明日にはもう少し御しやすいになっていることを願う

=}
{デラング}{進捗記録}{交度}{デライト}{`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 ですらページランク以上の革新を生み出せず,継ぎ接ぎ対策検索品質を保っているのが現状だ。

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

{デラング}{進捗記録}{論組}{輩符}{`!?`}{`??`}{希哲14年7月27日の開発}{検索種別}{描写検索}{補助的}...=}(61)

{希哲14年7月27日3歩 K#F85E/A-5B28-31DB}

デライト検索における部分一致検索全文検索仕様について大まかな方針を決め終了。

現状,デルン初期から引き継いでいる輩符による部分一致検索が残っているが,輩符は末尾ならともかく先頭に置くのは一般に使われる除外検索と紛らわしいという問題がある。

代わりにアスタリスクを使うという手も考えた。技術者にとっても分かりやすく,一般的にも伏せ字で使われることがあり,直感性に大きな問題はない。特殊記号であることは明らかなので混同の恐れも小さい。ただ,アスタリスク描写記法デラング)において見出し強調などに使うことを想定しており,その場合一貫性に欠ける。

そこで,「...」を使うことを考えた。例えば,「検索語...」で前方一致検索,「...検索語」で後方一致検索となる。「」や「・・・」で代用してもいい。普遍的省略記号であり,直感性アスタリスクに勝る。唯一の難点として素早く入力しにくいというのはあるが,全知検索ではあくまでも補助的な手段であるためこのくらいで丁度いいかもしれない。

ついでに将来的に全文検索などに対応をする場合の用合いについても検討

そのうち,知名検索だけではなく描写検索も含めた全文検索への要求も高まるだろう。現時点で想定しておかなければならない検索種別は,現状の知名のみ検索に加え,描写のみ検索,知名・描写検索の3種となる。これらを上手く切り替えられる方式を考えておきたい。

現状,?ボタンに使っているため,これを拡張して,検索語の末尾に ?! を加えることで検索種別を切り替えられる方式を考案した。末尾にこれらの文字を加えると,ボタンも ??!? に変化する。例えば,知名・描写両方を検索したい場合は ?? に,描写のみを検索したい場合は !? のようにする。!論組では否定の意で使われるため,知名は検索せず描写は検索する,という状態を上手く表している。

自然で分かりやすいが,自然過ぎることによる問題もある。題名などで疑問符感嘆符を使うものは珍しくないため,上手く切り分ける方法も考えておく必要がある。一番分かりやすいのは,記号の前に空白を置くことだが,フランス語のように言語によっては既にそういう習慣がある。末尾に空白を置いて無効化出来るなど,いくつか代替手段も必要だろう。

細部に課題は残るが,大まかな方針としてはこれで間違いないだろう。

{デライト}{検索機能}{機能退行}{希哲14年5月22日のツイスト}{希哲14年5月22日}{目障り}{ツイスト}{曖昧さ}{発見}{完全一致}...=}(15)
{デライト}{再実装}{機能退行}{希哲14年5月22日のツイスト}{希哲14年5月22日}{ベタ}{ツイスト}{後回し}{実装}{ブックマーク}...=}(14)
{全文検索}

{}