Kozaneba
from 日記2023-11-01 omniに関する現時点での感想と思考の整理
- 「時々上がってくるページ」はよい
- 時々浮かび上がってくるページ
- 表現の形には問題がある
- 現状、実験も兼ねて「全部とってある」けど、明らかによくない
- 結局、一番最新の生成だけ見てるのだから手前は必要ない
- 手前の部分が未読なら読んだらいいけど
- 振り返って読みたくなるかもしれないけど、最初から全部展開されてる必要はない
- 頻度のギャップが大きすぎる
- また、その変更がタイトルの変更によって行われるのはあまりよくない
- それ自体が悪いのではないが、タイトルが変更されたページを「新規追加ページ」として扱ってしまってるのが問題
- この問題をScrapboxで解決するのは少し面倒そう
- また、その変更がタイトルの変更によって行われるのはあまりよくない
- Iterative Commenter
- 想定通り「ゆっくりと周囲に枝を伸ばしていく振る舞い」が発生している
- ねりねりの価値が緩やかに減ってるが発生しても、さらに時間をかけるとゆっくりと外側に広がっていく
- 元々のRecurrent Notesが持っていた「繰り返し要約をかけていくことによるKJ法的効果」がない
- Iterative Commenterはprivateに移した方がいいと思う
- 乱読のセレンディピティをシステムが引き起こすから
- 想定通り「ゆっくりと周囲に枝を伸ばしていく振る舞い」が発生している
- 元データについて
- 自分のScrapbox記事が書籍60冊分あるのと、本当の書籍由来のデータが100冊分あるのでは全然違う
- 何が違うのか
- 書籍は一次元の文脈を想定している
- 読者が手前の文章を読んできていると暗黙に想定している
- なので「そこまでに現れたものの何を知っていると想定しているか」が明示されていない
- 一方でScrapboxは、読者が手前に何を読んでいるか仮定していない
- なので、関連する内容は明示的にリンクにされる
- のが理想だが、しばしばイベントの記録とか講演資料みたいに大きな一次元のものも置かれている。イベント記事は瀕死
- なので、関連する内容は明示的にリンクにされる
- どうすべきか
- 一つの案: レバレッジメモ
- ページk-1とkを与えられて、ページkのレバレッジメモを作る
- これは500トークンを少し超えたくらいのインプット
- 要約は曖昧概念
- レバレッジメモを「要約を作る」と考えるとよくない
- レバレッジメモは要約ではなく、再利用可能コンポーネントの抽出
- nullを返すのがしばしば正解
- そういうデータセットでの訓練はされてない
- この目的のためのデータセットはない、作るか?
- 文脈指定のある要約
- 文脈にマッチしたところを取り出したい
- レバレッジメモを「要約を作る」と考えるとよくない
- 一つの案: レバレッジメモ
- 自分のScrapbox記事が書籍60冊分あるのと、本当の書籍由来のデータが100冊分あるのでは全然違う
- 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
- 書籍の間に関連を見出させる仕組みで、nishioの60冊分のアウトプットを読ませれば結果的に書籍をnishioの文脈に着地させられるのでは
- 文章ではない表現形式が必要になった時に僕がずっと使ってきている
- 割と「機能的には十分」な感じ?
- 文章としてのメモの書けたら便利だな、ぐらい
- iPadから使えるようにしたい、みたいな機能というよりブラウザ互換性の問題
- テキストを刻むところを人間がやってる、人間がやれてしまっているし、やることによって写経やアクティブ読書のような「処理しながら読むことによってより良い理解が生まれる」効果があるように思っている
- が、思い込みかもしれない
- LLMで支援したら「もっと早くこれをやればよかった!」となるかもしれない
- 割と「機能的には十分」な感じ?
- ずっと使っているが、毎日使うタイプのツールではない
- 必要な時に取り出すツール
- Scrapboxとの相互接続があるとよい?
- Scrapboxの「文字列によるリンク」とKozanebaの非言語的な「配置によるリンク」「線によるリンク」は相互補完的
- Scrapbox側の表示のカスタマイズ性が低いので、別のビューが必要
- mem.nhiro.orgをもっと発展させる
Keichobot
- 人間に質問をすることによって言語化を促すシステム
- ゼロから引き出すことにフォーカスしている
- ので、既存の会話やScrapboxのストックと接続されていない
- されると良い可能性はもちろんある
- チャットログをScrapboxに置いた
- それがチャンクに刻まれてベクトルインデックスに入った
- これはメリットがあった
- 今は500トークンで刻んでるので粒度が荒いけど、このやりとりはQAなのでQAペアとかの形でインデックスするのが良いかも
Kozanebaすべき状況
Kozaneba
これちょっと飛躍してるね
- 「レバレッジメモ」という具体的アイデアに引きずられすぎている
- 過度に具体的な実装イメージ
- 書籍のある1ページが与えられた時に、その書籍のそこまでの話の中の何と関連しているのかのリンクをLLMが見出すことができればLLMは一次元の書籍を読みながらネットワーク構造を作っていくことができる
Scrapboxへのリンクはあるのだから、バックリンクがあるべき
- Scrapboxにそれを表示する機能はないので新しいビューがあるべき
https://kozaneba.netlify.app/#view=lhq9ixTHLRlLh55wFcT7
- 再利用可能なコンポーネントを作る
- nullを返しても良い
- 文脈と与えられた文章の間の関連を見出す
- 文脈とは
- 書籍の今読んでるページよりも前のページ
- 今読んでる本と他の本
- どっちが文脈?
- Scrapboxに書かれた考えと書籍
- 文脈とは
KozanebaのLLMでの支援
- 文章を刻むところ
- グループにタイトルをつけるところ