Kozaneba

from 日記2023-11-01 omniに関する現時点での感想と思考の整理

「時々上がってくるページ」はよい - 時々浮かび上がってくるページ
- 表現の形には問題がある
- 現状、実験も兼ねて「全部とってある」けど、明らかによくない
- 結局、一番最新の生成だけ見てるのだから手前は必要ない
  - 手前の部分が未読なら読んだらいいけど
  - 振り返って読みたくなるかもしれないけど、最初から全部展開されてる必要はない
- 頻度のギャップが大きすぎる
  - また、その変更がタイトルの変更によって行われるのはあまりよくない
    - それ自体が悪いのではないが、タイトルが変更されたページを「新規追加ページ」として扱ってしまってるのが問題
      - omniの仕様バグ
    - この問題をScrapboxで解決するのは少し面倒そう
Iterative Commenter
- 想定通り「ゆっくりと周囲に枝を伸ばしていく振る舞い」が発生している
  - ねりねりの価値が緩やかに減ってるが発生しても、さらに時間をかけるとゆっくりと外側に広がっていく
- 元々のRecurrent Notesが持っていた「繰り返し要約をかけていくことによるKJ法的効果」がない
- Iterative Commenterはprivateに移した方がいいと思う
  - 乱読のセレンディピティをシステムが引き起こすから
元データについて
- 自分のScrapbox記事が書籍60冊分あるのと、本当の書籍由来のデータが100冊分あるのでは全然違う
  - 何が違うのか
  - 書籍は一次元の文脈を想定している
    - 読者が手前の文章を読んできていると暗黙に想定している
    - なので「そこまでに現れたものの何を知っていると想定しているか」が明示されていない
  - 一方でScrapboxは、読者が手前に何を読んでいるか仮定していない
    - なので、関連する内容は明示的にリンクにされる
      - のが理想だが、しばしばイベントの記録とか講演資料みたいに大きな一次元のものも置かれている。イベント記事は瀕死
- どうすべきか
  - 一つの案: レバレッジメモ
    - ページk-1とkを与えられて、ページkのレバレッジメモを作る
    - これは500トークンを少し超えたくらいのインプット
  - 要約は曖昧概念
    - レバレッジメモを「要約を作る」と考えるとよくない
      - レバレッジメモは要約ではなく、再利用可能コンポーネントの抽出
      - nullを返すのがしばしば正解
      - そういうデータセットでの訓練はされてない
      - この目的のためのデータセットはない、作るか？
    - 文脈指定のある要約
      - 文脈にマッチしたところを取り出したい
Markdown変換
- 単なるフォーマットの変換
  - これはつまらない
- 文体の変換
  - 断片的メモからブログ記事へ
- 英語への変換
- 前段階としてターゲットにすべきかどうかの判定も？
検索でヒットしたものとの関連
- 今の500トークンのチャンクよりも小さい単位がある
- Scrapboxの簡潔な記事は「それ」になってる
  - 常緑のノートはアトミックであるべき
- 書籍から切り出した500トークンの文字列はそれになってない
Github Actionで動くのを一旦やめるかなぁ

from 日記2023-11-02 omniに関する現時点での感想と思考の整理

Iterative CommenterはGithub Actionsで動いている

omni-privateはlocalで動いている
- その方が実験しやすいから
- publicなomniとコードが共有されてる
Iterative Commenterはprivateに移した方がいいと思う
✅Github Actionsで動いているのを一旦止める

public /nishio → Github

とりあえず保存
清書した記事は別途
メンテのWikignomeが3.5で作られれば良い

機械生成された重複コンテンツ微妙

理想

embedについて
- キャッシュ使う
- 使われなかったキャッシュを引き継がない
- 機械生成コンテンツを対象にしない
Updateについて
- テロメアを維持する
- もしくはログを残さずに上書きする
  - 過去のものが見たければHistoryを使う
検索結果
- 見れるべき
- 最初から見せるべきではない
  - too much
  - もっとdigest
    - 人手のdigestは将来のFTのためのデータにする

草原で迷子、どちらへ進むのか

魅力的な目標が一つではない状態
- 一つならその方向へ進めば良い
たくさんの目標が違う方向にある時にどちらに進むか迷う問題
Kozanebaすべき状況

動的セマンティックウェブと考える花火

AIとの共同活動

あまりできていない
omni-privateではクエリを投げてAIが生成してそれを読んでるだけ
- ただの単発リクエストレスポンス
- それを不向きなScrapboxでやってる

AI読書ノート

本を読むという活動をAIにさせる
- 読むとは何か
  - 知識のネットワークを作っていくこと
    - どのようなネットワークが必要なのか？
    - バックリンクあるべき、たぶん
    - 2-hopリンクあるべき
      - なぜか？
      - これ　Scrapboxは忘れたことを思い出させてくれる
nishioの文脈に着地させる？
- 書籍の間に関連を見出させる仕組みで、nishioの60冊分のアウトプットを読ませれば結果的に書籍をnishioの文脈に着地させられるのでは
  - 明示的に作り込まなくても
  - まあでもこの効果を体験したければまず相応のアウトプット量が要求されるのでまったく一般人向けではない
    - まずは一般人向けを目指さない方がいい Kozaneba
文章ではない表現形式が必要になった時に僕がずっと使ってきている
- 割と「機能的には十分」な感じ？
  - 文章としてのメモの書けたら便利だな、ぐらい
  - iPadから使えるようにしたい、みたいな機能というよりブラウザ互換性の問題
  - テキストを刻むところを人間がやってる、人間がやれてしまっているし、やることによって写経やアクティブ読書のような「処理しながら読むことによってより良い理解が生まれる」効果があるように思っている
    - が、思い込みかもしれない
    - LLMで支援したら「もっと早くこれをやればよかった！」となるかもしれない
ずっと使っているが、毎日使うタイプのツールではない
- 必要な時に取り出すツール
Scrapboxとの相互接続があるとよい？
- Scrapboxの「文字列によるリンク」とKozanebaの非言語的な「配置によるリンク」「線によるリンク」は相互補完的
Scrapbox側の表示のカスタマイズ性が低いので、別のビューが必要
- mem.nhiro.orgをもっと発展させる

Keichobot

人間に質問をすることによって言語化を促すシステム
ゼロから引き出すことにフォーカスしている
- ので、既存の会話やScrapboxのストックと接続されていない
- されると良い可能性はもちろんある
チャットログをScrapboxに置いた
- それがチャンクに刻まれてベクトルインデックスに入った
- これはメリットがあった
- 今は500トークンで刻んでるので粒度が荒いけど、このやりとりはQAなのでQAペアとかの形でインデックスするのが良いかも