LLMによる知的生産性向上勉強会

• サイボウズラボ勉強会 2023-10-06
  • オモイカネプロジェクトで7/29からAIがScrapboxに1日1回レポートを書くようになった
    • これを/nishioに移植してバリバリ改良して行った2ヶ月だった
  • 勉強会の僕の前回の発表「オモイカネ勉強会」(8/4)は動き始めた直後だった
  • 2ヶ月の間に何を経験して何を感じたかをまとめる
• 今までの話
  • 2023-03-24 自分のScrapboxをChatGPTにつないだ話勉強会　Scrapboxをベクトル検索する一問一答UIの話
  • 2023-08-04 オモイカネ勉強会
• 
  • サムネイル
• 1: 時事の話題: Azure Cognitive Search
• 2: ベクトル検索
• 3: Omoikane Embed
• 4: AIと人間の知的な共同作業
• 5: AIによる赤リンクの延伸
• 6: 生のChatGPTとomniのユースケースが違う
• 7: 非公開omniを使ってみての感想
• 8: ベクトル検索は切り出しの機会になる
• 9: ベクトル検索は認知の解像度を高める道具として機能する

1: 時事の話題: Azure Cognitive Search

• 9/18 Azure Cognitive Search: Outperforming vector search with hybrid retrieval and ranking capabilities
  • src
  • よくある「キーワードだけの検索」よりも、ベクトル検索よりも、両方を組み合わせてリランク(≒検索結果を見てから並び替えること)した方が圧倒的に良いという話
• 「組み合わせてリランクした方がいい」は前から知られていたこと
  • from 検索を組み合わせる
    • AI王 〜クイズAI日本一決定戦〜 に参加し第3位入賞した話｜PKSHA Delta 2023-01-04

      • 

      • DPRとBM25を組み合わせてる
        • DPRが雑に言えばベクトル検索

          • Dense Passage Retriever (DPR)...事前学習モデルを利用した密なベクトルベース

        • BM25とは雑に言えば「モダンなTF-IDF」BM25: 語彙一致ベース
        • DPR, BM25 の両者の検索結果のオーバーラップは極めて小さい
          • →両者のいいとこ取りが良い
        • ベクトル検索は:
          • 意味的な類似性に強い
          • 低頻度語を見逃す / 分布外での性能劣化が著しい
        • 低頻度語に弱い(=固有名詞、専門用語や製品名に弱い)から、普通の検索を組み合わせる必要がある
        • FiD=Fusion In Decoder
          • 100件の検索結果を読んでテキスト生成する仕組み
• ベクトル検索はフワッとヒットするので自然言語の会話の曖昧検索には良いが「営業で訪問した相手先企業名」とか「製品型番」とかが「見た目のよく似た違うもの」もヒットするのでユーザの認知負荷が高い
  • グループウェアがベクトル検索を使っていく上ではこの問題の改善が必要だなーと思っていた
  • Azure Cognitive Search
    • 7/18 パブリックプレビューが開始
    • 近々試そうと思ってる
  • 構成を見たらBM25+HNSW+リランクと王道な構成
    • なおHNSW(Hierarchical Navigable Small World)はQdrantやPinecoreでも使われてるベクトル近傍検索の方法
• 「検索」とは何か
  • 顧客に対して生み出してる価値は何か
  • いまユーザに提供している「検索のUI」はその顧客価値を提供する最善の方法ではない
  • リランカー≒「200件の検索結果を見て良い順に並べ替える小人さん」
  • Fusion in Decoder≒「100件の検索結果を読んで文章を書く小人さん」
  • こういうものが利用可能になっていく時代
  • 特にリランカーの部分で「ユーザが明示的に入力したテキスト」以外のもの、たとえば直前のグループウェア上の操作などを加味するスタイルは差別化につながるかも

2: ベクトル検索

• 西尾のベクトル検索
  • このScrapboxプロジェクトのベクトル検索、2023-06-05 公開
• 僕にとってはベクトル検索の有用さは経験的に明らかなのだけど、多分まだベクトル検索を体験してない人のために事例を紹介した方がいい
• ベクトル検索が有用だった事例

  • 事例1

    • 「社会保障費」の話題になる
    • 「社会保障費が高いという話を過去の講演で話したことがあるな」と思い出す
      • 科学技術に対する投資との比率が焦点だった
    • 見つけようと思うが「社会保障費」で検索しても見つからない
    • 西尾のベクトル検索で「社会保障費 科学研究」で検索したらヒットした
      • 
      • 「医療38兆 福祉他24兆 合計120兆」という表現だった
        • 少し離れたところに「科学技術」もある
    • タイトルに「社会保障費」を入れた抜き書きページを作った
      • 社会保障費と科学技術関係経費の比較

  • 事例2

    • 壁の穴の話を出そうとして壁とか穴とかで検索するけど見つからず
    • "壁の穴、近づかないと見えない"でベクトル検索
    • 2番目候補で見つかった
    • 
      • 進む先に壁があることは進まない理由にはならない
        • 「近づかないと見えない」と「近づけばわかるのに」がマッチしている
      • 壁に近づかないと壁の穴が見えないというニュアンス
    • 壁の穴は絵に描いていたがテキストになってなかった
      • 書き足しておく
    • Q: 検索は、絵を見ているわけではないのですよね？（確認）
      • A: 見てないです

  • 事例3

    • "実現不可能なアイデアが独創的に見える"でベクトル検索
    • 探していたものは5番目でヒット
      • 

      • 素人のアイデアは口頭発表では独創性高く見えるが実現可能でない

      • 「レゴマインドストームで独創的な進み方をするロボットを作れ」という課題でマインドストームを使ったことのない素人とロボコン優勝・準優勝者(以下、玄人)とで比較をした論文。...玄人と素人では独創性に差はなかった。...しかし、素人のほとんどはそのアイデアを実現できなかった。

      • 「独創的」と「独創性」の揺れ、「実現不可能」と「実現できなかった」の揺れでヒットしなかった
      • 検索キーワードで検索対象を指定しようとした時「実現不可能」みたいな名詞形のキーワードで表現してしまいがちだが、実際には動詞形に開いて記述されていることがある
    • これより上の候補にも、とても関係ある内容が多い: result
      • この実験のページはエピソード性があるので記憶に残りやすく思い出されやすいのだろう
    • 「実現不可能なアイデアが独創的に見える」で新しいページを作った

  • 事例4

    • "kintoneはデータの周りで会話する"でベクトル検索
    • 1番:

      • 現状のkintoneだとデータの横でコミュニケーションできてデータの更新ができて自動バージョン管理されるわけだが、理想はデータベースのスキーマやカスタマイズのJavaScriptに関しても同様の共同編集ができる状態なのだと思う。

    • 4番:

      • 公共事業向けデジタルソリューションを活用した自治体業務改革

        • 両自治体ではデジタルソリューションとしてサイボウズ株式会社の「kintone」が活用されました。kintoneはExcelを使う程度の知識があればプログラミングの知識がなくても業務アプリケーションを構築できます。メール、Excelとバラバラになっていた情報を統合し、創意工夫により独自の業務環境を作ることができます。

        • なるほどなー、kintoneをどう説明したらいいかわからないなと思っていたが「メールとExcelの統合」と説明するのか

        • 「メールとExcelの統合」という言葉はいいな

  • 事例5

    • "計測しやすいものだけ測るバイアス"

      • コストが数値で測りやすいのに対し、品質は測りにくいので軽視しやすい

  • Q: ベクトル検索なら、みんな検索うまくなる？

    • A:キーワードが既知であるならキーワードで検索した方がいい、ベクトル検索に良い特徴があっても「心を読む」ことはできないので検索する人の言語化能力は必要

  • この手の話は、うまく言った例だけ（あるいは多めに）聞くと魔法のように感じるが、実際にはうまく行かなかったときのほうが同じくらい（あるいは圧倒的に多い）ということもよくあるので、気をつけないといけない（自戒を込めて）

    • もちろんそう。サービス公開しているので自分で試してみて: 西尾のベクトル検索

  • 振り返ってみる

    • 「こういう『文字列』を書いたはずだ」ではなく「こういう『意味』のことを書いたはずだ」で検索することが可能になってる
    • 西尾自身がベクトル検索のシステムに適応していってる
      • 初期の事例では「社会保障費 科学研究」「壁の穴、近づかないと見えない」のように断片で検索している
      • 慣れるに従って「実現不可能なアイデアが独創的に見える」「kintoneはデータの周りで会話する」「計測しやすいものだけ測るバイアス」のように「意味を表現する短文」で検索するようになってる
    • 先日Zoomで画面共有しながらこのベクトル検索を使ってもらったらユーザが「自炊の経験について教えて」と入力して「あっ、使い方を全然理解してないな」と思った
      • ベクトル検索とInstruction TuningされてるLLMの区別がついてない
      • 多分世の中のほとんどの人が区別ついてないのだろう
      • 基盤となる言語モデルに「ユーザの入力を指示(インストラクション)とみなして、その指示に従う」という追加学習(Instruction Tuning)を施したものだけが指示に従う
      • ChatGPTがそうであるからという理由で似た入力をしてしまう
      • なるほど、ChatGPTとは違うのかー。
    • なおそのユーザはその後「料理に関して記述した内容」と入力して目的通り僕の酷い自炊の話を発見していたので結果オーライ？
      • あんまりベクトル検索の良さを活かしてない
        • クエリーの中の「意味」が、実質「料理」の1単語なのでキーワード検索と変わらないから
      • 今僕が「酷い料理を作ってしまった」で検索すると、酷い過去の料理がたくさん出てきたwww
• Q: 表記ゆれ吸収のための検索キーワードを付け加えてヒットしやすくするような作業がベクトル検索で不要になる？
  • A: それは不要になるけど、ベクトル検索だけにするとキーワード一致の検索が下手になるから結局Azure Cognitive Searchのようなキーワード検索と組み合わせるアプローチが必要になりそう
    • 一方Helpfeelは「表記ゆれ吸収のためにキーワードを増やす」という作業を機械が支援してより効率的にするアプローチだね

    • 弊社の独自アルゴリズム「意図予測検索」...の技術を米OpenAI社が提供するtext-embedding-ada-002モデルを使用し、さらに拡張させる HelpfeelがAIのハルシネーションを回避しながら検索精度を30%向上させる「Contact Sense AI」を公開。問い合わせの自己解決を促進｜株式会社Helpfeelのプレスリリース

  • Q: キーワード検索と組み合わせる場合、検索クエリはベクトル検索用のものとは異なる？
    • A: いや？BM25でも文章で検索できるのでそんな変わらないんじゃないかな。多分「単語で検索してそれが含まれる文書を返す」っていう昔の検索のイメージがあるのだと思うけど、BM25はそのイメージよりは「入力中のすべての単語で検索する」の方が近い
      • 実践で学ぶBM25 - パート2：BM25のアルゴリズムと変数 | Elastic Blog
  • Q: 多義語も扱って欲しいな〜(今のベクトル検索では厳しい？)
    • A: 「多義語」って発想自体が「単語で検索する昔の検索のイメージ」にとらわれてると思う。今は文章全体から埋め込みベクトルが作れる時代なので文意が一意になるように文章を書けばいい。1単語だけを見たときに語義が複数あっても問題にならない。
• Q: キーワードだけじゃ見つからないけど探したいものを見つける効果と、セレンディピティ的な予期しない情報の出会いと両方ある？
  • A: ある。目的のものがあってそれが見つかったとしても、周囲の断片を読むことに予期しない思考の刺激があって面白い。例: 「実現不可能なアイデアが独創的に見える」での検索結果

3: Omoikane Embed

• オモイカネプロジェクト 6/4~
• from [/omoikane/Omoikane Embed](https://scrapbox.io/omoikane/Omoikane Embed)
  • Omoikane Vector Searchのためのベクトルインデックスを作る仕組み
    • Github Actionで日本時間朝6時に実行
    • Scrapboxから自動でJSONをエクスポートする
    • 500トークンに刻んでベクトル埋め込み
    • Qdrantにアップロードする
  • 6/9から稼働開始、毎日実行されるようになった
  • 7/29からScrapboxにレポートを書くようになった
    • 前回のオモイカネ勉強会(8/4)はこれが稼働し始めたとこだった
  • 8/9 コードを整理して他のプロジェクトに入れやすくした
    • 実際に試してみる人たちが現れた
    • この/nishioにも入れた
      • これがomoikane-embed-nishio、略してomni
    • このomniをバリバリ改良して行った2ヶ月だった

4: AIと人間の知的な共同作業

• 8/16 AIと人間の知的な共同作業
  • 
    • AIがScrapboxにノートを書いて、翌日そのノートをAIが読んで、またノートを書く仕組み
    • Scrapboxという共同編集の場で人間と同じように知的生産の活動を繰り返していく
  • 8/12に実装して、
    • AIが毎日研究ノートを書く
    • AIとの共同化
  • 8/16に「AIと人間の知的な共同作業」を執筆、8/20(未踏ジュニア中間合宿)と8/21(ラボユース合宿)で話した
• 8/21 人間がトリガーを引かなくても良い
  • AIの一日一回のノートにコメントを書くコミュニケーションスタイルは「人間がトリガーを引かなくても良い」というメリットがある
    • 人間が忙しくてコメントを書けなくてもAIは一人で先に進んで行く
    • コメントをある程度書いたとしても「送信する」的なアクションがない
      • その後何かを思いついてさらに加筆するかも知れない
      • いつが「終わり」「完成」かの人間の意思決定がいらない
    • 「送信する」アクションがない方がいいのかどうかは不明
      • 個人的にはあったほうがいいと思うし、PCの前にいる時には開発環境でスクリプトを実行することによって実現できる
      • 今、合宿会場に行くために電車で移動している、こういう場合にスマホからトリガーしたいと感じる
        • →後にその機能がついた(Pioneer Mode)
• 8/21 ページをフォークしたい
  • →8/21 マルチヘッド / ページメモリ
  • from ページメモリ
  • AIが新しいページを作るのではなく、同じページに加筆していくスタイルが生まれた
    • その後、新しいページを作るスタイルはdisableした(8/31 メインブランチ停止)
  • これによって「複数のトピック」を並行して発展させていくことができるようになった
    • 人間が「この話題を発展させたいな」と思ったメモをシードとして書いて、それをAIノート扱いにする(当時の実装ではタイトルに「🤖🔁」を付ける)
    • →マルチヘッドの思考
• 余裕があれば話す(余裕はない)
  • 8/21 ページメモリ→8/23 全履歴からの使用済みページ無視→8/26 話題のピン留め効果
  • 8/25 更新ページ数制限→8/31 AIノートの更新間隔について
  • 加筆の方法を変えた: 9/11 Recurrent NotesとIterative Commenterの違い

5: AIによる赤リンクの延伸

• 8/30 AIによる赤リンクの延伸
• from AIによる赤リンクの延伸
  • AIが毎日研究ノートを書くシステムの、当初予定していた用法ではないが有用なユースケース
• 歴史
  • 赤リンク(リンク先が空のリンク)を作った上で、その赤リンクを指定すれば、リンクタイトルでベクトル検索した結果を用いてページが作られるようになった
  • これが有用
    • どういうエクスペリエンスをもたらすかというと:
      • 「確かこんなことを書いたことがある気がするな〜」とリンクを作る
      • ここでScrapboxのリンクサジェストにより支援されることもある
        • Scrapbox詳しくない人のために説明: Scrapboxはリンクの作成時に曖昧検索が走ってリンク先をサジェストする
        • されなかった場合に、今までは検索などを使って探さなければつながらなかった
        • それをAIに任せることができる
  • さらに発展
    • AIの生成物とか、AIが発掘した過去の記述とかを見ていい「長めのフレーズ」があった時に、マーカーを引く感じでリンクにする
    • 当然赤リンクになる
      • これは長いので「自然にはつながらないだろう」と予想される
      • そこでこれを「赤リンク延伸」する
      • 今までは長いタイトルを刻むページという運用で当たり判定拡大をしていた
• 具体例1
  • 🌀交換様式Dでomniが「問題解決の過程での交換の重要性を再認識しました」と言った
  • 「問題解決の過程での交換の重要性」が何かわからなかったので赤リンクにして延伸した
  • omniが「問題解決は理想と現状のギャップを埋めるものであり、その過程での情報交換は重要です」と言ったので「なるほど、情報交換は交換ということか」と理解した
  • この気づきを情報交換は交換に書いた
    • (この気づきの意味が多分伝わってないが、それは後で事例になっているのでここでは説明しない)
  • しばらくして「知識交換の交換様式はAなのか？」という疑問が生じた
  • そこで生まれた「贈与の対象としての公共」を赤リンクにして延伸したら、いろいろな事例を紹介してくれた
• 「説明のある検索」といえる
  • なぜそれを候補に出したのかの説明がついている検索
  • 検索結果を人間が直接読むのではなくAIが先に読んで説明を書いてくれる
  • 9/2 ベクトル検索とRAGの肌感の違い

    • kazunori_279 やっぱファインチューンとかRAGとかごにょごにょするより、単純にembでベクトル検索して結果を表示するだけで良くね？って思った。

    • nishio 僕もながらく「ベクトル検索だけでいいだろ」派だったのだけど、単なる質問回答ではなく知的生産のアシスタントとして使う場合はRAGの方がいいと感じる。生成部分が「目的に合わせて検索結果を要約すること」として機能するので。なおこれはクエリとは別に目的が与えられてることが前提。

    • ながらく「西尾のベクトル検索」を使って「これだけでいいのでは？」と思っていたが「AIによる赤リンクの延伸」ができて「こっちの方がいい」と思うようになった
  • 単なるベクトル検索とは異なった有用さを感じている
• 「検索と行動のデカップリング」とも言える
  • 今までの「検索」は更新を伴わないので、検索結果を見て僕がScrapboxを更新しなければ、その検索はなかったものになった
    • 「検索したことを忘れる前に人間が結果を読んで行動をすること」が暗黙に要求された
    • 検索と行動がカップリングされてた
  • 「AIによる赤リンクの延伸」は人間が「検索の意図」を書き込み、AIが「検索して、それを読んで解説の叩き台を書く」までやるので、検索後の人間の行動はオプショナルになる
• 9/4 Pioneer Mode

  • 開拓者モード (Pioneer Mode) とは、「AIによる赤リンクの延伸」の発展形

  • 「✍️🤖」のページにリンクを置いておくと、AIが定期的にチェックして自動的に生成してくれる

  • スマホから使えるようになった
• Q: AIで赤リンク延伸してくれたページと、自分が作ったページが区別されますか？区別されない場合、別に混ざってても特に違和感ないですか？
  • A: してない。最初はしてたけどやめた。
    • 「どの部分がAIでどの部分が人間か？」という問い

      • 二人の人間が意気投合して、活発な議論をして、互いの発言が互いに影響を与え合った場合、その結果として出てきたのもののどの部分が片方の人由来であるのかは識別しにくくなる。

      • 人間とAIの場合も同じことが起こる。これを識別しよう、識別できる状態にしよう、という発想はUIを設計する上で有害な可能性がある。

      • と自分が書いてた
    • 特にScrapbox上だと「あるページを読んで、考えが触発されたら、そのページに書き込む」という行動がアフォードされてる
      • そうなると「AIが生成したページ」を見て人間が書き込みをした時に、「そこが元々AI生成ページであるから」という理由でその人間の書き込みが拾われないのはおかしいよなという気持ちになりAI生成ページかそうでないかの区別を捨てた
    • 例えば行単位で更新者を知ることはできるので、AIに専用アカウントを作ってやれば「AIの生成したコンテンツを無視して人間の書いたものだけ使う」は一応可能
      • なんでやってないかというと、それをやる必要性を感じないから…
      • やってみると新たな発見があるかもしれない、他の試したいことが山積みなので優先度が低くて着手されてない、という感じ
    • 一方で明示的にダメだと思ってることもあって、ベクトル検索の結果をそのままAIの出力としてScrapboxに書くのは良くないと思っている
      • 人間がそれを読むことまではOKだけど、再び検索結果に入ると「タイトルとコンテンツの対応づけ」の価値がスポイルされる感じがある
    • from AI生成ページのタイトルに🤖を入れるのをやめた理由
      • AI生成ページのタイトルから🤖マークを外すことについて考察した。当初はAIが生成したものをAIが読まないようにするためだったが、運用中に人間がAIが書いたページに反応することが自然であると感じた。しかし、その内容がAIによって読まれる対象にならないことに疑問を感じた。また、共同編集の場の前提がないことについても触れた。
      • いい要約だった
      • 続きのこれは確かに問題
      • このノートは、西尾の研究ノートの断片「AIページの底に埋もれてる」に関連している。AIが生成したページに人間が反応することが自然であるという考え方と、AIが生成したページの底に人間の思考が埋もれてしまうという問題は、AIと人間の間の情報伝達という観点から見ると密接に関連している。
      • その問題は今はこういう対処をしている
      • Recurrent NotesとIterative Commenterの違い

6: 生のChatGPTとomniのユースケースが違う

• 9/6 自分が無意識にChatGPTとomniを使い分けていることに気づいた
• つまりその二つが提供している効用には差があるということ、何が異なるのか？
• from 生のChatGPTとomniのユースケースが違う
  • 世の中のテキストは大部分が「多くの人が読んで理解できる表現」で書かれているのに対し、僕の研究ノートは「自分が理解できる表現」で書かれているため、後者を使ってRAGするAIは僕個人の思考をChatGPTよりもはるかに効率よく加速する
  • 自分の研究ノートでは自分がわかってる単語の解説を書かないので、それを読んだAIも僕がわかっていることの解説を書かない。概念は思考の経済性を高める道具なので一人の思考では無説明で使う方が効率的
  • それを他の人に説明する時にはChatGPTを使うのが有益
• 氷山モデル
  • omniの方が僕個人の水面(まだ言語化されてないものとの境界)に近い出力をするので言語化支援効果が高い
  • たぶんブログとScrapboxの特性の違いも関係している。Scrapboxでは同じ概念を何度も説明するのではなく、その概念のページを作ってそれにリンクする
  • すぐ上の事例、「氷山モデル」のここでの説明は最小限
    • 
      • from 公共の言葉と私的な言葉 : エンジニアの知的生産術 p.206 (6.2.5.5) 公共の言葉と私的な言葉
• 事例1
  • 「知識の生産性を向上させるためには、共同化の重要性や計画作成の前に暗黙知を共有することの重要性を理解する必要がある」
    • この「共同化」が「野中郁次郎のSECIモデルの話」であることを僕はわかる。これは少し日本語が下手なのを補って読める。
  • 「知識の生産性を向上させるためには、共同化の重要性や計画作成の前に暗黙知を共有することの重要性を理解する必要がある」を一般人が理解可能な表現にしてください。
  • 「知識を効果的に使って物事を進めるためには、みんなで協力して情報をシェアすることや、実際の仕事を始める前に、それぞれの経験やコツをみんなで共有することが大切です。」
    • 大部分の人は分かりやすくなったと感じるのだろう
    • 僕の主観的には明らかに劣化している。多分GPT4が共同化を正しく理解していない。
  • 追記:これをもうちょっと説明したい
    • 野中郁次郎のSECIモデルにおける「共同化」は言語化が困難な「暗黙知」を、言語を介さずに共同作業などの「同じ体験を共有すること」によって共有すること
      • なので、それを「情報、経験、コツをシェアする」という表現をしているのは「全然わかってないな」感がある
    • それを踏まえるとこの発言は「言語的な計画を立てる前に、まず共同化による非言語的な体験の共有が必要である」という解釈になる。
    • で、この発言が出てきた文脈ではAIによる知的生産性の向上について話していたので
    • AIを使ってどのように知的生産性を向上するかについて、言語的な計画を立てる前に、まずは共同化が必要である
    • となる。人間が毎回指示を出してAIがそれに答えるのではなく、AIが勝手に活動するシステムを作って普段僕が知的生産をしている場に住まわせて「AIとの共同生活」を体験するのはその一つの形。
• 事例2(さっきの「情報交換は交換」)
  • 「情報交換は交換」を僕は重要な気づきだと感じたが、たぶんほとんどの人は何が面白いのかわからないと思う
  • 「交換」という言葉を見て僕は「柄谷行人の交換様式論」の文脈につなげる
  • すごく大雑把な説明
    • 交換様式A: 贈り物をしてお返しをする
    • 交換様式B: 服従をして保護をする
    • 交換様式C: 対価を支払って商品を得る
  • 「情報交換は交換」は「情報も財であるのだから情報交換を柄谷行人の交換様式論の枠組みで考えることができる」という気づき
    • 「では知識交換の交換様式はAなのか？→いやDMではなく共有の場を使う情報共有は贈与の対象としての公共があるから新しい交換様式なのでは？」という気づきにつながった
• 補足(時間に余裕があれば)
  • 技術的にはRAGでプロンプトにたくさん積んだことによって「チャットらしさ」がなくなって「要約タスク」に近づき、RLHFによる「一般人が好む表現にする圧力」が下がってるのだと思う
• 理解の速度には文体も要因として大きいなあと感じてて、ただGPTに生成させた文章より、few-shot で自分の文章を与えて生成させたほうが自分にとって読みやすい文章が生成される印象がある
  • 確かに。omniは僕の文体で話すから僕にとって読みやすいということもありそう。結局AIアシスタントは個々人にパーソナライズした方が個々人の生産性をより高めるということかも。

7: 非公開omniを使ってみての感想

• 9/20 公開の/nishioで動かしていたomniに十分な有用性を感じたので非公開omniを作り始めた
  • 
  • 公開の場におけないもの(書籍など)を検索対象に含めたいため
  • 横断ベクトル検索実験メモ2023-09-20
• 9/27 非公開omniを使ってみての感想
• ベクトル検索だけでかなり面白い
  • 「本棚の前で語ると本が飛び出してきて関連したページが開く仕組み」をイメージしてもらえれば、そりゃ面白いよねという気持ちはわかってもらえるのではないか
  • 他人のScrapboxがヒットした場合は「Xさん、こんなことを書いてたのか〜」と面白く読んでる、その後のコミュニケーションにつながるかも
• 公開omniと非公開omniの感覚の違い
  • やっぱり使い分けてる
    • ということは異なる効用を感じているはず、それは何か？
  • データが主に自分由来であるのか、そうでないのかによって感じ方が違う
  • 自分由来の時はAIと人間が渾然一体の存在として思考をドライブしてる感じ
    • 「自分が加速してる」と感じる
    • 「自分が異なる視点から見ている」と感じる
  • 他者由来の時は「あー、このテーマについてXさんはこんなことを言ってたのか〜」という気持ち
    • 「他人の発言を見つけた」と感じる
  • 事例
    • 基礎研究をする科学者は身銭を切って活動すべきなのか、それとも市場に任せると投資が不足する公共インフラとして政府が投資すべきなのか
    • 「反脆弱性［上］」の断片から、政府の投資は研究全般ではなく、非目的論的な活動に向けられるべきという考え方が示されている。
    • おー、そんなこと言ってるのか、読んでみよう

    • 政府がお金をかけるべきなのは、研究ではなく非目的論的ないじくり回しである --- 反脆弱性［上］ p.375

  • 自分由来の断片は、一旦自分の中で噛み砕かれたあとで再構築されているので、なめらかにつながる感じがある。他人由来の断片はまだ表面が硬い
    • でも「噛み砕いて再構築」「溶け合わせる」「なめらかにつなげる」自体を自分由来データでファインチューニングしたLLMがやるという手も将来的にはありかもしれない
      • 10/3 Scrapboxでの知識醸造をLLMに教える
      • 噛み砕くプロセスは知識問題ではなく入力をどのようなチャンクに分けるか、どのようなフォーマットにするか、という問題なのでファインチューニングが有効そうに感じる
  • 自分由来の異なる視点の断片は、他人由来の異なる視点の断片よりも強く弁証法的発展をドライブする
    • 他人由来のものは今の自分の意見と異なってても「そういう考えもあるよね」とスルーできる甘えがあるから？
    • 「他人の意見が異なってるのは当たり前だよね」という逃げ？
    • 自分由来の意見が今の自分の意見と異なっている場合、両方自分なので「なぜ意見が違うのか？」という問いを強く惹起する？
• Q: 自分由来の異なる視点ってのは自分が考えそうって意味ですか？
  • A: 「自分が過去に考えたこと」の方が近い
• Q: やっぱりこれは「自分が一度読んだ本」をいれておくからいいのかな。それとも一度も読んでない本でもフレーズがベクトル検索でヒットしたら有用なのかな？
  • A: 一度読んだ本でも細部まで覚えてないでしょ。
    • ベクトル検索を使い始めて自分が8年前に書いたブログ記事とかが発掘されたりするけど、自分で書いたのに覚えてない
    • 読んだ本でも予期せずヒットして「おっ、この本にそんなこと書いてあったっけ？あー、確かに書いてるー！前に読んだときにはあんまり気にしてなかった！」みたいな感じ。
    • 良書は何度も読むといいって言われるけど、要するに書かれていることを受け止められるかどうかは読み手の側の属性。
    • そういう意味でも「いま関心を持っていること」に関連する書籍の関連するページが出てきてそれを読むのはとても良い読書体験になりそう。
• Q: 自分由来なのか他人由来なのかの認識は、公開Omniか非公開Omniかというところでの識別してるんだろうか？それとも内容をみて識別してるんだろうか？
  • A: そういう意味だと今は非公開Omniに自分由来データが入ってないからどちらも同じ
    • 混ぜてみた実験をするのがいいね

8: ベクトル検索は切り出しの機会になる

• 
• 9/2 切り分けられていない連なりの一部にヒットすることで切り出しの機会になる
• 数え切れないくらい発生した有益事象
  • 日記、チャットログ、講演資料、会話の文字起こしなど「時間軸で並んだ記述」がある
  • AIがトピックで検索して、その「並びの途中」にヒットして、そこに言及する
  • それを見た人間が、その部分を切り出して新しいページをつくる
  • ベクトル検索の話でもやってた

    • タイトルに「社会保障費」を入れた抜き書きページを作った

• 時間軸で並んだ記述からトピック指向で切り出される

  • 時間軸とトピック指向の間でのバランスは、情報の整理や解釈における重要な課題である。時間軸に沿った情報の整理は、情報の流れを追体験するのに適しているが、特定のトピックやテーマ性を探求する際には、トピック指向の新しい構造を作るために時系列の構造を破壊する必要があるかもしれない。一方、トピック指向の整理は、情報を特定のテーマやコンテキストに基づいて整理することを可能にする。これらの間での適切なバランスを見つけることが、情報の効率的な整理と理解を促進する。

• 事前に行うことは難しい
  • 適切な切り出し方は、ニーズが明らかになった後に決まる
• 「切り出し」の概念について不慣れな人も多そうなので解説
  • 個人の知識管理の領域では、単一のトピックの短いページを好ましいものだとする考え方がある
    • 例: 常緑のノートはアトミックであるべき

      • そうすることで、トピックや文脈を超えたつながりを形成しやすくなります

    • 単一責任原則にも似ている
  • なので「複数のトピックが混じったページ」から「単一のトピック」を抽出する行為が行われる
  • Scrapboxの場合、これが「複数行を選択してバルーンメニューからNew Pageを選ぶ」という操作で実行可能
    • これが通称「切り出し」で、名前の通り「カット」して新しいページを作り、相互にリンクする
      • 「カット」と「コピー」のどちらが良いかは議論の余地があるし、僕も常にカットが良いとは思っていない、講演資料は通して読める状態を保つことに価値がある
        • グループウェアに議事録が置かれてる状態とかはそれを編集してしまうことにユーザは抵抗を感じるだろう
        • Scrapboxの哲学の「死んだテキストを置く倉庫ではない」という思想からは「そういう使い方をするな」となるだろう
• チャンクに刻まれた断片に対するベクトル検索であることによる振る舞い
  • 今500トークンで刻んでるので、書籍1ページくらいの分量
  • チャットログだとスレッド全体でも特定の一人の発言でもなく「何件かのやりとり」の単位になる
  • 長い会話の「一番そのトピックについての言及が濃いところ」が検索で返される
  • 人間がそのチャンクのいらないところを捨てたり周囲の関係するものをピックしたり、触発されて新しい意見を書いたりして新しいページを作る、これが有益
• Scrapboxは切り出しをアフォードする設計になっている、これがLLMと組み合わせる上で有益
• 切り出すと時系列のコンテキストが無くなるのが問題になることもありそう
  • Yes
• なるほどなあ。→死んだテキストを置く倉庫ではない、という視点
  • 作者の思想はそうだけど、個人的には「なんでも入れよう」の方がいいと思ってる
• 積読した本を入れておくと、実は有益かもしれない？？
  • 積んでても語りかけてこないからこのシステムに入れた方がいいんじゃない？まあ実態がなくなるので「なんとなく手に取る」とかの機会はなくなるが

9: ベクトル検索は認知の解像度を高める道具として機能する

• 
• from 10/3 Scrapboxでの知識醸造をLLMに教える

  • nishio 自分の研究ノートからのベクトル検索は認知の解像度を高める道具として機能する

  • それは「似ているもの」が提示されることによって、今考えていることを少しずつ違う方向から観察することになるからだ...「言語化をする」というプロセスに「世界を記述する解像度を高める」と「高い解像度での観察によって得られた理解を他の人に伝わる形で記述し直す」とがあり、これは別物なのでそれぞれわけて考える必要がある

    • 「今考えていることを少しずつ違う方向から観察する」が「似ている→違いは？」思考によって認知の解像度を高める
• 似ている→違いは？

  • 認知の解像度を上げるために有益な思考のパターン

  • ある二つの概念に対して「似ている」と感じた時、「これは全く同じものだ」と感じなかったということはそこに「違い」を感じている。

  • その「違い」は現時点では言語化されていない。

  • 「違いは何か？」と考えることで物事をより詳細に観察できるようになる。

    • 今回の発表でもChatGPTとomniを比べたり、公開omniと非公開omniを比べたりしてきた
• ベクトル検索は「似た話題の断片をかき集める仕組み」として機能する
  • KJ法の「関係がありそうな断片をひとところに集めて、それからどのような関係があるのか考える」に似ている
  • 小さな収束ムーブとそこからの発散 9/3

    • 見覚えがあるなと思った

      • 
        • from アイデアの干渉効果
          • 
            • 発想法 p.107
  • 「似た話題」と「似た意見」は違う
    • 似たトピックに関する異なる意見はベクトル検索的には割と近い
      • 対立は近い関係
• シードが異なる自分との対話を過去との自分との対話で代替するということか……
  • それもあるけど、やっぱり「そのときに自分が置かれていた状況」によって考えることは影響を受けるのだなぁ、とベクトル検索でヒットした過去の記事を見たりして思う
    • 今の瞬間の自分でもこのScrapboxに書くのと他のScrapboxに書くのとSNSに書くのと社内グループウェアに書くのでは少しずつ異なった知的生産がされるイメージ
    • それらを再度束ねることによって
• 西尾さんは自己拡張を体験している！西尾さんにとっては、何倍になった感じですか？1.3倍？2.4倍？？
  • 1.2倍かな〜。2.0は超えてないw

以下は執筆前のメモ 以下は、入力された情報を要約したものです：

• 7/29: AIがScrapboxに書き込み、Scrapboxエージェントの概念を紹介。
• 8月の初めから中旬: オモイカネ勉強会、AIとの連携に関する議論、AIによる研究ノートの執筆、ベクトル検索の進化、及びAI生成ページの取り扱いに関するトピック。
• 8月の中旬から終わり: マルチヘッド、ページメモリ、ユーザーの認知負荷を考慮した更新と検索に関するトピック。
• 9月の初め: AIとユーザーとの相互作用、ノートの管理、及び異なるコンテンツ間の関連性を探求。
• 9月の中旬: マルチヘッドの思考、エンジニアの知的生産術、AIとの連携に関するさまざまなトピック。
• 9月の後半: LLMと他のモデルの比較、人間の概念に関する議論、Scrapboxの最適な使用方法、及び非公開ツールのフィードバック。 全体として、この期間はScrapboxとAIとの連携、特にベクトル検索やマルチヘッドの概念、AIの思考とユーザーとの相互作用に重点を置いているようです。

7/29 AIがScrapboxに書き込む

• Scrapboxに住んでるエージェント 8/4 オモイカネ勉強会

8/11 /omoikane/この後の進み方をGPT4に相談した2023-08-11

8/12

• AIとの共同化
• 知見: /unnamed-project/AIのペースが速いと人間が追い付けない

8/12 AIが毎日研究ノートを書く 8/16 ScrapboxとAIに関する思考の結節点2023/8/16 8/16 ベクトル検索結果を積む 8/16 上書きモード 8/18 AI生成ページのベクトル検索からの無視 8/18 AIの支援で新しい結合ができた事例 8/21 マルチヘッド

• ページメモリ 8/23 全履歴からの使用済みページ無視

8/25 更新ページ数制限 8/26 話題のピン留め効果

8/29 AI生成ページのベクトル検索からの無視の解除 8/30 AIによる赤リンクの延伸 8/31 メインブランチ停止 8/31 質問は言語化を促すが質問にも種類がある 8/31 enchiへの導入 8/31 AIの役割の明確化が大事 8/31 AIノートの更新間隔について 8/31 中学生の職場体験でSFプロトタイピングをやってもらった事例 9/1 流動的プロセスとしてのページ 9/1 思索と開発のトレードオフ #苦痛 9/1 このプロジェクトにおけるAIの役割は何か 9/1 複数の個性のAIがある？ 9/1 AIノートのページごとに目的を明示したらいいのでは 9/1 AIページの底に埋もれてる #苦痛の原因 9/1 異なるコンテンツの間のつながり発見 9/1 自分の日記に他人のAIを召喚 9/2 ベクトル検索とRAGの肌感の違い 9/2 切り分けられていない連なりの一部にヒットすることで切り出しの機会になる +1 9/2 AIが無限に思考を発展させてくるので休めない #苦痛の原因 9/2 他のプロジェクトのURLを読めるという気づき

9/2 マルチヘッドの思考 epoch 9/2 たまに浮かび上がるページ

9/3

• 「マルチヘッドの思考」と「エンジニアの知的生産術」
• 小さな収束ムーブとそこからの発散
• まとめを上に書く

9/4

• ___BELOW_IS_LESS_INTERESTING___を__BELOW_IS_AI_GENERATED__にした

🌀マルチヘッドの思考 🌀AI出島

Iterative Commenter Pioneer mode

~ AIシャーマン

9/11 松尾研のLLM講座 AIによる異なる視点の提供の実例 歌詞をAIに解釈させる実験 Recurrent NotesとIterative Commenterの違い

9/12 不明瞭で長期的なタスクをAIにねりねりさせる PDFからScrapboxへ

9/13 ビジネスはシーズとニーズのマッチング

• メタ考察:ビジネスはシーズとニーズのマッチング
  • 市場ニーズと個人ニーズ
    • (9/5) 深層の価値探求: 連携と成長

AIにページを発展させさせる

9/15 長い寝起き神託の考察 最近のモーニングルーティン2023-09-15

9/16 人生に関する歌詞を集めて気に入ったフレーズをピックアップする

9/18 「どの部分がAIでどの部分が人間か？」という問い

9/20 private projectでの統合 横断ベクトル検索実験メモ2023-09-20

2023/9/22 LLMに似ているものの違いを言語化させる (仮)まだ名前のない操作 Scrapboxを活用した思考とコミュニケーションの再構築

2023-09-24 「人間」の概念が曖昧

2023-09-29 非公開omniを使ってみての感想

Scrapboxでの知識醸造をLLMに教える