{知能増幅技術}{希哲16年5月の一日一文}{知能増幅メモサービス}{知能増幅}{叫び続けている}{大きなビジョン}{願って}{気付いてくれる}{本当の可能性}{一人でも多くの人}...=}(276)

{“知能増幅メモサービス”はなぜいま最も重要なのか K#F85E/A-E74C-CDB9}

人工知能仮想通貨暗号通貨仮想現実仮想世界……等々様々な分野世界的な注目を集める中,これらを凌ぐ潜在力あるにもかかわらずまともに語っているのは私だけなのではないか,と思えてしまう分野がある。それが「知能増幅IA: intelligence amplificationだ。

知能増幅というのは,文字通り工学的に人間知能増幅させることを指す古くからある研究分野だが,人工知能などに比べてその話題性著しく乏しい参考。この言葉に「人体改造」に近い響き感じる多いだろう。実際脳にチップを埋め込む遺伝子を書き換えるといった人体改造的な研究これまでの主流で,まず倫理的課題大きかった倫理的課題大きければ技術的課題解消するための実験などもしにくく,実用段階にある技術存在しなかったデライト登場するまでは古典的な SF域を出ず,語れること大して無かったわけだ。

先日の「デライトの使い方の考え方」で少し触れたように,デライトは,その知能増幅誰でも簡単に触れるメモサービスとして実現した知能増幅メモサービス」であり,「世界初の実用的な知能増幅技術」だ。どのように実現しているかはあの文章ざっと書いたので,今回は,この知能増幅メモサービス意義について書いてみよう思う

知能増幅の世紀

私は,ビッグ・テックGAFAM などと呼ばれる世界最大の企業群Google, Apple, Facebook, Amazon, Microsoft合併して「Microappglezonbookマイクロアップグルゾンブック」となり,自分がその経営思うまま出来たらどうするか,という思考実験をすることがある。答えいつも変わらないiPhoneGoogle 検索Windows も,世界最大の SNS世界最大の通販サイトも,何もかも売り払って知能増幅メモサービス開発全てをかける

最近何かと話題イーロン・マスク氏と入れ替わったとしても,やることは同じだ。テスラSpaceXTwitter も,何もかも売り払って知能増幅メモサービス開発全てをかける。ちなみに,氏の事業一つには,まさに脳にチップを埋め込む系の知能増幅技術扱うニューラリンク」があるものの,やはり,他の事業ほど目立った成果もなく,あまり知られていない

つまるところあらゆる分野の中で,「知能増幅」が群を抜いて大きな可能性持っていると私は考えている。これを多くの人理解すれば,21世紀間違いなく知能増幅の世紀」になるだろう。世界初の実用的な知能増幅技術であるデライトは,その嚆矢だ。

知識を生み出す技術

長い前置き似合わず知能増幅メモサービスなぜいま最も重要なのかという本題は,拍子抜けするほど単純明快な話だ。知識最も価値を持つ時代において,最も価値のある知識は「知識を生み出す知識」であり,最も価値のある技術は「知識を生み出す技術」だからだ。まさにそれを研究開発するのが知能増幅という分野だ。そして,知能増幅メモサービスは,最も実現性の高い実際にデライト実現している知能増幅技術なのだ。

例えば人工知能がいかに発達しようと,それを開発管理利用していくのはあくまでも人間だ。人間愚かなまま機械だけが賢くなっても,人間社会にとってのボトルネック必ず人間の愚かさになる。知能増幅技術は,人間あらゆる知的活動最も根源的な部分から持ち上げる技術であると言える

……と,この単純明快な話を私がしたのは,昨日今日でもなければ一度や二度でもない昔から何度端的に語っても意図するところ伝わった試しがない。どうもピンと来ていないというのか,大体反応が「なるほど,で?」という感じだ。理屈なんとなく理解出来ても,それが意味すること大きさ想像出来ていないのだ。その大きさ先に書いた理由だ。

節穴

思えば,この“ピンと来ていない感じ”というのは,「個人知識管理PKM: personal knowledge managementとして認知されつつある分野感じるものと似たところがあるその名の通り個人自らの知識効果的に管理することに関してすでに色々な方法論技術集められている。その代表的手段として「メモ」があり,メモアプリメモサービスなどと呼ばれるものも盛んに研究開発されている。

このメモサービス知能増幅結び付けたのが「知能増幅メモサービス」というデライト位置付けだが,これが,私が思っていたより変わった発想だったらしい,とデライトの宣伝始めてから気付いた個人知識管理技術発展させていけば,それは当然知能増幅繋がる。この単純な発想が,意外にも共有しにくい。「デライトではこんな新しいこと出来る」と言っても,「なるほど,でも○○間に合ってるから」という反応受けることが多かった。そこには,想像していたよりずっと大きな温度差があった。

このあたりの分野よくよく観察してみると,開発者にせよ愛好家にせよ,そこまで大きなビジョン持っているほとんどいないことが分かる要は,「生活術」とか「仕事術」とか「ライフハック」の範疇でしかとらえていない個人知識管理知能増幅繋がり,それが世界を変える,なんて大それたことを考えている人間は,全くいないわけではないだろうが異端者だ。

私の立場からは「節穴同然眼力」としか言えない分野体たらくだ。「趣味の問題」で済むでもない。そう思ったとしたら,ここまでの理解出来ていないか,想像力があまりにも足りないただただ一人でも多くの人がこの分野本当の可能性気付いてくれることを願って,私は叫び続けている


{希哲16年5月の一日一文}{囚われたくない}{狭苦しい}{よく使っている}{閉じた}{満たしたい}{知的探究心}{好きなだけ}{遠慮する}{他人に}...=}(96)

{デライトに“参加しにくさ”を感じている人へ K#F85E/A-E74C-E681}

デライト新規利用者増やすにはどうすればいいか,と考えてくれている利用者達もあまり触れないことに,私自身のアカウント問題がある。デライト普及にとって最大の障害か,といえば,あまりに癖の強い私の輪郭溢れかえっていること,というのが開発者として常に感じていることだ。自分が訪問者でも入りにくいな,と思う

実際最初の頃は,自分の輪郭目立たせないように,宣伝活動をした後しばらく描き出し避けるなんてことまでしていた。それはそれで使いこなし方分かりにくくなるので,あまり作為的なことはしないようになった。だから,初期利用者入ってきた時は,世の中には変わった人がいるものだな,としみじみ思ったものだ。そうは思いつつ,私も私で失礼気がして言いにくかった

利用者達が活発描き出ししてくれるようになったおかげで,だいぶ入りやすい雰囲気になったとは思う。それでも,客観的に見れば,まだ「変わった人達の集まり」なのかもしれないし,コミュニティとしてのデライトに“参加しにくさ”を感じている多いだろう。

デライトは,極力誰でも好きな時にて,好きなこと好きなだけ書けるように設計している。もちろん挨拶必要もないし,他人に遠慮する必要もない。個人情報どころか,名前すらいらない。私自身,狭苦しいクラスタ」だとか閉じたコミュニティ昔から嫌いだ。

あまり先入観持たず,まずは触ってみてほしい,というのが開発者としての願いではあるが,もしデライトコミュニティとしての特徴があるとすれば,自由に知的好奇心探究心満たしたい人達の集まりとは言えるかもしれない。「希哲フィロソフィー」という言葉よく使っているように,知的探究心以外のなにものにも囚われたくない人間にとって,機能的にもデライト最高の場所だ。


=}
{あれ}{希哲16年3月13日のツイスト}{希哲16年3月13日}{昔から}{限られている}{宣伝文句}{賢さ}{望事}{ツイスト}{ゴミ}...=}(20)

{あれK#F85E/A-E74C-0B7A}

ただ,人工知能主軸にした望事プロジェクト評価難しい。「人工知能」が変数として漠然とし過ぎているから。昔から人工知能宣伝文句にするような望事は数多くあるが,そんなもん人工知能賢さ次第ゴミにもにもなるだろうというところがあり,実際成功例限られている

=}
{HTML}{駒手記法}{進捗記録}{あれ}{希哲16年2月20日13歩}{神秘的な}{別に}{実装した}{付けた}{階層区切り}...=}(248)

{希哲16年2月15日24歩 K#F85E/A-E74C-1EF9}

進捗時限記録中略

不意に閃いた階層区切り線」についての方針まとめて終了

従来の見出し未満区切り線記法に,見出し階層越えられる階層区切り線」を加える。以下のように,唯一通常の区切り線区別出来る見出し記号 #全角 使う

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落(# の数でも調整出来る)。

持ち辺モチベーション

従来の区切り線記法は,HTML において対応する <hr>性質上見出し未満区切りにしか使えなかった

見出し階層作った後で描写全体に対するフッター的なものを書こうとする第1階層見出し作る必要があるが,しばしば大袈裟感じられることがある。

検討過程

空見出し」の挫折

今回検討当初は,「空見出し」という概念主に考えていた区切り線長さ任意であるべきなので,どうっても自然な形階層調整出来そうになかった。その点,見出し内容出来れば手っ取り早い

しかし,等号星号区切り線使う予定なので,== のように第2階層以降で内容空にする衝突することになる。

区切り線の方を見直しても,--区切り線なら == はやはり二重区切り線であってほしい。直感性下線形見出しとの整合性考えるとこれは捨て難い星号による区切り線はそれに比べればまだ転用余地があったが,その代わり *使う Markdown の区切り線記法との互換性損われる

そもそも,「空見出し」という概念にも無理がある文字を書くから見出しなのだし,実質的に区切り線なのだから,直感的とは言い難い

階層区切り線」の閃き

ここで,唯一区切り線記法被らない見出し記号である番号記号思い出した

番号記号による見出しは,ハッシュタグ駒手記法との衝突避けつつ atx 式見出しある程度互換性持たせるため,## のように2個以上条件対応していた個人的に好きな記法ではなかったこともあり,おまけのような扱いで,ここまで気付かなかった

すでに「空見出し」に感じていて,区切り線記法での対応立ち返っていたことで,この ##特殊な区切り線みなせる特徴持っていることに気付いた記号2個以上繰り返す区切り線見える記法で,実際普文枠線的な装飾使われることが多い記号でもある。

特に,区切り線記法としての統一感直感性保てる2個第1階層表せるということは決定的に重要な点で,見出し記号個数階層関係一致しないとどうしてもちぐはぐ見えてしまう。これは,衝突回避したとしても等号星号では解決出来ない問題だ。区切り線記号としての最短形見出し記号としての第1階層対応しうる唯一記号番号記号だった。

ただし,通常の区切り線記号異なり,個数階層対応するため,普文装飾兼ねられないという問題があった。上位階層区切り線普文上で目立つように書けない

これは,最新の区切り線記法下線形見出し記法検討9日17歩19歩踏まえ見出し階層対応する4種区切り線組み合わせる解決することにした。つまり,第1階層から順に最短形#==##--##- -##. .# というように区切り線組み合わせることが出来るようにする。これがまた都合が良いことに,よくある装飾見える

9日15歩以後,見出し下線区切り線長さ区別出来るようになっているため,区切り線装体にはある程度多様性持たせ問題ない一方見出し下線階層表す装体になっているため,一定制限必要になる。この点でもぴったり噛み合った

別に2個以上良いだろうと実装した区切り線記法おまけ感覚付けた番号記号による見出し記法最近の拡張方針……何気ない全てパズル要素だったかのように思える神秘的な閃きだった。

番号記号見出し仕様厳密化

この階層区切り線考案に,番号記号による見出し常に2個最上位階層とすることにした。つまり,*=##始まる見出しはともに最上位階層表す

これまで異なる見出し記号併用することは特に想定しておらず,実際使われていないはずなので,記号個数単純に計算していた。見出し階層相対的な個数決まるため,*始まる見出しがあると ##第2階層になる。これは階層区切り線整合しない。

特に仕様として決めていたことではないため,ここで厳密化することにした。

実装上の課題

仕様完璧思えるが,実装上の課題残った

HTMLCSS機能的には,可接性ちつつ見出し要素隠すことは造作もないが,SEO 上の懸念多少ある。今の検索演心評価理積みはそこまで単純ではないだろうが,伝統的に見出し要素隠すべきではないとされてきただけに,どこまで不利になるか分からない出来るだけ行儀の良い実装方法見つけたい

そもそも見出し要素にしてはいけないのか,<section> あたりを使って上手く誤魔化せないか,など色々考えてみたが,どれも多かれ少なかれ怪しさ残る

見出しの無い階層区切りというのは HTML想定外だったのだろう。

{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}{実践的な}...=}(248)

{希哲16年2月15日10歩 K#F85E/A-E74C-2CA8}

進捗時限記録中略

昨日寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法タグ記法周りの概念整理仕様整理急速に進んだ

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称4記法基本とし,それぞれ所定装体スタイルを伴う <b><i><u><s> HTML 要素対応する

@ を使った文字サイズ記法% を使った色記法検討していたが,タグ記法概念が出来たことで中途半端なものになるため,これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つ検討方針

実装自体は容易部類で,記法概ね固まっていたにもかかわらず文字装飾記法実装踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針3通り考えられる

  1. 完全に意味論的な記法にする
  2. 完全に装飾的な記法にする
  3. 意味論装飾重ね合わせた記法にする

記法趣旨からしても,軽量標記マークアップ言語特性を考えても,1つ目に無理があるのは明らかだ。対応する HTML<b><i><u><s> は,私が何度解説を読んでもややこし感じる代物だ。それを多くの人正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系捨てることになるが,代替案があるわけでもない。

かといって,2つ目ももったいない。要は <span>装体指定だけにするということだが,例えば,太字にはしたいが <b> にはしたくない場合打ち消し線引きたい<s> にはしたくない場合がどれだけあるのかと考えると,無難通り越して臆病過ぎる失う可接性アクセシビリティ応用可能性釣り合わない

最終的に採用することになった3つ目も,全く考えなかったわけではないが,柔軟性に欠け,前の2つの悪い所組み合わされる気もして,有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態変えたのは,前日概念としてまとまったばかりのタグ記法だった。

これまで,デラングにおける HTML は,どうしてもデラング出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで,積極的に使うことを想定していなかった。実際個人的にはほとんど使っておらず放置している不具合多い部分だった。

デラングタグ記法として間接的に HTML使うことで,略記法導入可能になり,HTML 側の仕様変更に対しても一定の緩衝帯設けることが出来る。ここに来て初めて文字装飾記法でも「書き分け」が考えられるようになった文字装飾記法対応しうるのが全て1文字要素だったことも幸いした

昨日寝る直前に,##太字的な表現##<{font-weight:bold}>太字</> のように書き分けるよりも,##太字##<b>太字的な表現</b> のように書き分ける方がマシであることに気付いて,1つ目の実装方針完全に潰せた

これにより一時的に2つ目の実装方針再浮上したが,標準的に使う記法として標準的な用途最適化不足なのはやはり否めなかった

決着

最終的に,「文字装飾を伴う慣用表現」という用者自然に理解出来る範囲での意味論的位置付け与え逸脱する用途ならタグ記法書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針洗練させた格好になる。

例えば##太字## は「太字装体<b>」に対応する装体邪魔なら <b>太字的な表現</b>書けるし,意味邪魔なら <{font-weight:bold}>太字</>略記法検討段階のように書けるが,これらの場合稀少なのは明らかで,記述量上手く釣り合うワープロならともかく,軽量標記言語手書きしようという人にとって難しい使い分けではないだろう。

そもそも<b><i><u><s> は,古くからある視覚的要素HTML5慣用的な用途引き継いで意味論化されたものなので,「文字装飾を伴う慣用表現」と非常に相性が良い相互変換にも全く問題ない

何より,直感的に入力すれば構造的に出力されるというデラングの理想適っている

文字サイズ記法色記法廃案

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで,慣用表現を持たない文字サイズ記法色記法仲間外れになるが,タグ記法によって出る幕がなくなった感があるので,ここで廃案にすることとした。

第一に,タグ記法略記法整備した方が一貫性応用可能性高い特定プロパティ省略出来るようにし,<{white}>白い文字</> のように書ければ,%white%白い文字%% と書くのと記述量大差ない

もともとパラメーター必要とする記法異質感はあり,文字装飾記法統一感損うかという懸念はあったので丁度良かった

波及的検討

波及的に,いくつかこまごまとした検討進んだ

組み合わせは「」ではなく「入れ子」へ

これまで,複数文字装飾記法組み合わせ#/太字と斜体/# のように,「記号を1つずつ逆さにした終了記号挟む」といったややこしい説明考えていたが,##//太字と斜体//## のような「入れ子」を #/太字と斜体/#短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法発展

今回検討で,タグ記法早くも実践的な役割を持つことになり,デラングにおける存在感一気に増した

タグ記法HTML仕様変更対する緩衝的役割を持たせること,要素名省略<span> にすることを考え始めた

{進捗記録}{高い}{希哲16年2月7日の開発}{表示された}{0.1em刻み}{狭まってしまう}{滅多に使わない}{階層の深さ}{変わってしまう}{4階層}...=}(87)

{希哲16年2月7日16歩 K#F85E/A-E74C-5EF4}

{進捗記録}{高い}{希哲16年1月31日の開発}{希哲16年1月31日14歩}{見送ってきた}{別の記法}{必要性に乏しい}{閲覧性}{重い強調輪符}{予想される}...=}(97)

{希哲16年1月31日13歩 K#F85E/A-E74C-0A95}

進捗時限記録中略

閲覧専用模動強調輪符多重輪括弧についての整理終了


多重輪括弧は,単純に外側の輪括弧をそのまま全て表示する仕様まとめていくことにした。この場合,閲覧専用模動でも輪結になる。役割を考えると,この場合の輪結先閲覧専用模動ではなく後景一覧あるいは重い強調輪符との組み合わせ輪郭ページにすべきか。

直近の検討では,全知検索における多重輪括弧(個数にかかわらず)輪括弧1対だけ表示し,閲覧専用模動における二重輪結化のみ,三重以上で輪括弧表示する,といったように模動によって表示仕方変えるつもりだった。

これは,輪括弧輪結化する“水準”を表すものと考えれば自然な記法思えたが,模動にかかわらず輪括弧表示させたいという時にわざわざ {{{あれ K#XXXX/XXXX}}}書かなければならないなど,実際には煩雑紛らわしくなることが予想される。現に,こう説明してみても分かりにくい

この複雑な仕様必要なことがあるとすれば,閲覧専用模動強調輪括弧表示もせずに輪符輪結化したいという場合だが,閲覧専用模動用途全知検索との使い分け考える必要性に乏しい相応しい別の記法がありそうだ(これは次歩方針解決か)


二重輪符」や「多重輪符」という用語考えたが,このあたりは将来的に輪符の入れ子にもかかわりそうなので,もう少し整理したい。

輪符の入れ子から検討しているものの,必要性に対する複雑化懸念から見送ってきた。ただ,あれば表現の幅広がるのは間違いないので,将来的に対応する可能性高い


強調輪符閲覧専用模動でも輪結化するという方針維持する

最近全知検索では重い強調輪符のみ輪結先後景一覧ではなく輪郭ページにする方針固まり,より文書として読みやすい形で表現出来るようになるだろう。

閲覧専用模動構想初期に比べて,まず全知検索閲覧性十分なものにするという方向軌道修正している昨年12月6日の開発における輪結装体調整もその一環だった)ため,全知検索閲覧専用模動での表現差異必要最小限留め全知検索読みやすいように書いた文書自然に閲覧専用模動にも適したになるようにしたい。

{実際}

{}