omniに関する現時点での感想と思考の整理
Kozaneba
https://gyazo.com/7d6eed9b756f95558259b3ba75fa9f85
表現の形には問題がある
現状、実験も兼ねて「全部とってある」けど、明らかによくない
結局、一番最新の生成だけ見てるのだから手前は必要ない
手前の部分が未読なら読んだらいいけど
振り返って読みたくなるかもしれないけど、最初から全部展開されてる必要はない
頻度のギャップが大きすぎる
また、その変更がタイトルの変更によって行われるのはあまりよくない
それ自体が悪いのではないが、タイトルが変更されたページを「新規追加ページ」として扱ってしまってるのが問題
この問題をScrapboxで解決するのは少し面倒そう
想定通り「ゆっくりと周囲に枝を伸ばしていく振る舞い」が発生している
Iterative Commenterはprivateに移した方がいいと思う
元データについて
自分のScrapbox記事が書籍60冊分あるのと、本当の書籍由来のデータが100冊分あるのでは全然違う
何が違うのか
書籍は一次元の文脈を想定している
読者が手前の文章を読んできていると暗黙に想定している
なので「そこまでに現れたものの何を知っていると想定しているか」が明示されていない
一方でScrapboxは、読者が手前に何を読んでいるか仮定していない
なので、関連する内容は明示的にリンクにされる
のが理想だが、しばしばイベントの記録とか講演資料みたいに大きな一次元のものも置かれている。イベント記事は瀕死 どうすべきか
ページk-1とkを与えられて、ページkのレバレッジメモを作る
これは500トークンを少し超えたくらいのインプット
レバレッジメモを「要約を作る」と考えるとよくない
nullを返すのがしばしば正解
そういうデータセットでの訓練はされてない
この目的のためのデータセットはない、作るか？
文脈指定のある要約
文脈にマッチしたところを取り出したい
Markdown変換
単なるフォーマットの変換
これはつまらない
文体の変換
断片的メモからブログ記事へ
英語への変換
前段階としてターゲットにすべきかどうかの判定も？
検索でヒットしたものとの関連
https://gyazo.com/b300b107c18718ba2de3d6e5387628f8
今の500トークンのチャンクよりも小さい単位がある
Scrapboxの簡潔な記事は「それ」になってる
書籍から切り出した500トークンの文字列はそれになってない
Github Actionで動くのを一旦やめるかなぁ
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読書ノート
どのようなネットワークが必要なのか？
なぜか？
nishioの文脈に着地させる？
書籍の間に関連を見出させる仕組みで、nishioの60冊分のアウトプットを読ませれば結果的に書籍をnishioの文脈に着地させられるのでは
明示的に作り込まなくても
まあでもこの効果を体験したければまず相応のアウトプット量が要求されるのでまったく一般人向けではない
まずは一般人向けを目指さない方がいい
Kozaneba
文章ではない表現形式が必要になった時に僕がずっと使ってきている
割と「機能的には十分」な感じ？
文章としてのメモの書けたら便利だな、ぐらい
iPadから使えるようにしたい、みたいな機能というよりブラウザ互換性の問題
テキストを刻むところを人間がやってる、人間がやれてしまっているし、やることによって写経やアクティブ読書のような「処理しながら読むことによってより良い理解が生まれる」効果があるように思っている
が、思い込みかもしれない
LLMで支援したら「もっと早くこれをやればよかった！」となるかもしれない
ずっと使っているが、毎日使うタイプのツールではない
必要な時に取り出すツール
Scrapboxとの相互接続があるとよい？
Scrapboxの「文字列によるリンク」とKozanebaの非言語的な「配置によるリンク」「線によるリンク」は相互補完的
Scrapbox側の表示のカスタマイズ性が低いので、別のビューが必要
Keichobot
人間に質問をすることによって言語化を促すシステム
ゼロから引き出すことにフォーカスしている
ので、既存の会話やScrapboxのストックと接続されていない
されると良い可能性はもちろんある
チャットログをScrapboxに置いた
それがチャンクに刻まれてベクトルインデックスに入った
これはメリットがあった
今は500トークンで刻んでるので粒度が荒いけど、このやりとりはQAなのでQAペアとかの形でインデックスするのが良いかも
---
Kozanebaすべき状況
Kozaneba
https://gyazo.com/ae0d7e4e737b9a456622fc739151b5e9
https://gyazo.com/3d702a0302c4af25356bcd1d81dc7cd8
https://gyazo.com/5147d879ea14d5f577b768d674f95b83
これちょっと飛躍してるね
「レバレッジメモ」という具体的アイデアに引きずられすぎている
過度に具体的な実装イメージ
書籍のある1ページが与えられた時に、その書籍のそこまでの話の中の何と関連しているのかのリンクをLLMが見出すことができればLLMは一次元の書籍を読みながらネットワーク構造を作っていくことができる
https://gyazo.com/f63de6308625d08119272a5347a0bf32
https://gyazo.com/57798542ee925e3b8c24a7353c2a4f80
https://gyazo.com/3e5d0699752e9fd5f1868dceda0f8355
https://gyazo.com/05cc6af6d14c3b0e98abcad88efe1477
https://gyazo.com/cf2857d393f24abe26ed5a05be74dc41
Scrapboxへのリンクはあるのだから、バックリンクがあるべき
Scrapboxにそれを表示する機能はないので新しいビューがあるべき
https://gyazo.com/ff1555a81ebc3413f4fd063287e21597
https://gyazo.com/c8921c65abd0239638be23a1d3f1bb89
https://gyazo.com/fca06da9d2a3f9dcb7a1c4582d0fcb4b
---
https://gyazo.com/aca81f67b5fbc799e3069c38c41abd08
https://gyazo.com/226ef03e389b3994ac44e6d324aa85d5
https://gyazo.com/5f22c3e8d4ccd49636b98deb4d723725
https://gyazo.com/7d6eed9b756f95558259b3ba75fa9f85
再利用可能なコンポーネントを作る
nullを返しても良い
文脈と与えられた文章の間の関連を見出す
文脈とは
書籍の今読んでるページよりも前のページ
今読んでる本と他の本
どっちが文脈？
Scrapboxに書かれた考えと書籍
KozanebaのLLMでの支援
文章を刻むところ
グループにタイトルをつけるところ