日記2023-08-23

ラボユース合宿3日目

既に出現したページを抑制するのは、ベクトル検索で出現したものに限定すべきだ

AI読書ノートはとりあえず動いている

ScrapboxへのIOを想定して、入出力の口は一つだけでエラーメッセージも同じところに来るのだけど、その仕組みだと機械的にループさせたらエラーメッセージを読んで続きを書いちゃいそうだね

あー、3.5だと読んだものをそのまま翻訳して書いてしまったりするなぁ

大雑把な概算で、1ステップに$0.48くらいかかって、一冊の本に100〜500ステップくらい掛かりそうだから、まあなかなか高いガチャだな

fill_with_related_fragments系が、今は与えられたトークンを埋める文字列と使ったページのタイトルのリストとを返してるけど、これが変わるべき

今日もまたpushし忘れて定期実行のコードがちょっと古い…

マルチヘッドでヘッドをたくさん増やしておこう

離脱の時間までにできるかな

会場離脱

とりあえず並列ノートをたくさん作っておいた
これは今日の夜には忘れずに止めないとな…
- 1時間1回走るので明日の朝大変なことになってしまう
- 今でも既に大変なことになってる説w
- TODO 家に着いたら1日1回に戻す
たくさんのテーマを並列で走らせるのは良い
- 🔁マークを削れば自動更新は止まる
- でも、明示的にマークを削るって行動はあんまり体験がよくないように思っている
- ゆっくり頻度が下がっていくのがいいのでは？
  - Spaced Repetition
  - 徐々にスパンが増えていく
  - 人間がリアクションをしたら1日に戻る
- 生成日時は表示されている
  - 生成日時よりも更新日時が後なら編集が行われたということなので次回の定期タイミングで更新
  - 更新されてない場合には「前回の生成とその前の生成の差分」に1.5を掛けたものを超えている場合にのみ更新
    - つまり1,2,3,5,8,13,という感じになる
    - だいたいフィボナッチ数列

エラーが出たときにフラグメントが全部出力されてしまうので、それを消してやらないといけない、スマホからやるのはとても面倒

今数えたら並列トピック20ページもあるじゃん、作りすぎ！

16:07にリリースしましたの通知がGithubからくる、でもこの後GPT4が20件走るんだな、あれ？じゃあ30分くらいに上書きが走る？書き込みづらいな…

16:58 横浜駅で迷子になってる間に更新が来てるかなと思ったが来てなかった

デバッグ、謎は解けた

埋め込みAPIの失敗が無限にリトライする
ではなぜ失敗するのか？
「前回のノート」が空文字列になっている
なぜそんなことに？
GPT4のAPIが失敗してエラーログが前回のノートとして書かれてしまっているケースで、それがノートとして読まれると困るなと思ってスマホから削除した際に空行が残ったため

ふぅん、どうするべきか

A: 根本的にはエラーログがノートとして読まれうるのがよくない
B: マーカーの上に空行だけがあるときに、空行を前回のノートとするのはおかしい、今後もうっかりミスで引き起こしうる
C: そもそも本当に前回のノートが空であるときに、ベクトル検索をしてしまうのがおかしい
- 当初の設計ではランダムに埋めていたが、そのユースケースは無視して良いと判断していた
- 空であってもタイトルは存在するのでそれを使う
D: 本当に埋め込みAPIに空文字列が渡されたとき、無限にリトライするのはおかしい
- そもそも空文字列が渡されるのがおかしいので即座に例外を投げる B, C, D fixed: https://github.com/nishio/omni/commit/33ab6c7ad456c5aa96033603a4f06cb7e5a72465 A fixed: https://github.com/nishio/omni/commit/03b6ca3e660ced94fdcbb84e975c62bc115e3d4b

帰りの電車でインタラクションするという当初の予定は不発に終わった

🪴 Quartz 4.0