Omoikane Embedを他のプロジェクトに入れる前にGit LFSをやめる
Omoikane Embedを他のプロジェクトに入れる前にGit LFSをやめる
Git LFSをやめる
このキャッシュはpickleがGit LFSでリポジトリに入る実装
サイズの上限にぶつかったのを面倒だったので月額5ドル課金で解決してる
>Every account using Git Large File Storage receives 1 GB of free storage and 1 GB a month of free bandwidth. doc
なのでオモイカネの2倍程度のサイズのプロジェクトだと無料枠を使い切ってしまうね
実行時間のことを度外視してキャッシュをしなかった場合、毎日0.1ドル、月に3ドル掛かることになる
うーん、じゃあやっぱり2倍のサイズのプロジェクトだと月額5ドル以上は掛かりそうだな
ここを何か他のストレージに置くことで無償にするチャレンジはやりたい人がいればどうぞ
あ、違うな、これGitに入れてるから過去のファイルも保存されて容量をじわじわ消費してるのか
今のオモイカネで54MBなので40倍の規模の/nishioだと毎日2GBくらい消費することになる
これは課金してもすぐ使い切るな…
じゃあ別の方法を考えた方がいいな
GPT4にどんな手段があるかきいた: log
Github Actionにキャッシュの仕組みがあり5GBまでおける
しかし任意のファイルタイプというわけではない
Artifactがおすすめとのこと
>Artifacts allow you to persist data between jobs in a workflow, and they can be used to store data for use in a later job. They're also accessible after the workflow is completed, so they can be downloaded manually if needed.
あっ、別のワークフローでアップロードしたらダウンロードできなかった、ワークフローごとか…
いや、同じワークフローの異なるrunでも共有できないじゃん…
between jobs in a workflow このワークフローとは単一のワークフローの複数回の実行ではなく、「単一のワークフローの単一の実行」だな
そういう場合にどうするのか聞いたらGitに入れるかクラウドストレージだなと言われた…
S3のバケットを作ってそこに入れる形
一旦Artifactを使う形に変える前に戻した
続きは明日
2023/8/1
キャッシュファイルを使わないという設計もアリだとは思う
その場合にどうなるか
データがクラウドサービス上にしかない状態になる
いま、キャッシュミスヒットが発生するものが新着データであると判断している
いまはオンメモリのdictなので高速
クラウドにおいたらそういうやり方は現実的ではなくなる
エクスポートしたJSONに含まれる各ページの更新時刻を見て、前回の更新以降のものを処理する方法が考えられる
A: 「前回の更新時刻」をどこかに記録しておく必要がある
B: 「古い時刻のデータのインポート」などが行われるとインデックスから登録漏れが起きる
Aに関しては、Scrapboxに書き込んでしまう手が考えられる
Bは、そもそもその「インポートするJSON」があるはずだから、コマンドラインからそのJSONを指定して読み込ませる手段があればいい
データがクラウドにしかない状態が嫌だったのだけど、当初やり始めた頃からAPIの値段が1/4になって、全部やり直しても4.0 USDになったから気にするほどでもない気がしてきた
その方がいいか？
キャッシュファイルができることのメリットはそれを例えばコンソールでの対話的利用に使ったり、後から複数のプロジェクトを混ぜたりすることにに利用できること
歴史的には前者の使い方が先に生まれた
うーん、一旦やめて「やっぱり必要だった」となるかどうか観察かな…
最悪4ドル払ってローカルに作ればいいよね
結局のところ4倍高かった時代に既に手元にあるデータを捨てて16ドル払って作り直すのが嫌だったからこの形になっただけ
今日は実装しないで一晩寝かせよう
この辺から適当に無料のS3ストレージを選んで使うとか？
自分なら試行錯誤のたびにかかるお金は額にかかわらずなるべく安く済ませたいなぁ
R2の方が安そう
ファイルがあればそれを使うし、無ければ作り直すみたいな形にしておけると良いのかな？
うーむ、確かに「めんどくさいから課金で解決」と思っちゃったけど、そうすると「課金がめんどくさい」が発生するんだよな
若い人はクレジットカードがなかったりするし
いや、埋め込みの時点でOpenAIのAPIに課金してますやん
ローカルで埋め込みするという手もあるよ
無料のS3、無料にするために何かをバーターで差し出しているはずで、何を差し出してるのか考えるのがめんどい
2023/8/2
ここまでの議論を踏まえて判断させる
チャット形式のUIの制限で要約させるための入力自体がその後の入力を押し流してしまい直近のものしかわからなくなっている
全データセットを毎日完全に生成する現在のプロセスは、特に大規模なプロジェクトではスケーラブルでないことは明らかです。毎日、新しいデータまたは更新されたデータのみを処理するインクリメンタルな更新システムを導入するのがよいだろう。この方法であれば、計算資源とコストを大幅に削減できる。しかし、そのためには、変更を正確に記録する堅牢な追跡システムが必要となる。
「スケーラブルでないのは明らか、差分更新にしろ」まあそうですよねぇ
Git LFSは、コストとサイズの制限から、キャッシュ・ストレージとして持続可能なソリューションではない...選択肢を検討する際には、コストだけでなく、信頼性、セキュリティ、既存プロジェクトへの統合のしやすさなども評価することが重要だ。...キャッシュのメリットが少なくなった場合は、プロジェクトをクラウドデータを中心に運用するように再構築する可能性もある。
「キャッシュのメリットが少なくなったら」なるほど、メリットは何か、ということだな。
GitHub Actionsとの連携： GitHub Actionsは任意のファイルタイプやワークフロー間でのデータ共有をサポートしていないため、この分野でより柔軟性のある別のCI/CDツールを検討したほうがよいかもしれません。あるいは、ワークフローの実行間でデータを共有するためのカスタムソリューション、例えば一時データ用の専用クラウドストレージバケットなどを実装することもできます。
そんな都合のいいCIツールあるかなぁ
最後に、プロジェクトの中核となる要件と依存関係を慎重に再評価することを提案したい。複雑さを減らし、プロジェクトの目的に必要な機能だけを維持することは常に有益だ。プロジェクトの安定性と機能性を確実に維持するために、これらの変更案の各段階でプロジェクトをテストすることをお勧めする。
「複雑さを減らし」したい。S3とか使うことに対する抵抗もそのせい
考える
プロジェクトの中核となる要件とは？
自分が管理者であるScrapboxを持っていて、それが1日1回ベクトル埋め込みされてベクトル検索できるようになると嬉しい人が、なるべく手軽に導入できること
ベクトル検索のメリットを実感
そこから将来的には「AI質問箱」「AIチャットボット」と進歩していく
キャッシュのメリットとは？
開発者としての僕が試行錯誤の過程でQdrantのデータの持ち方を変えたりとかするたびに「お金を払ってしばらく待つ」をやりたくなかった
「1日1回自動更新」のユーザは、スキーマが変わったりなどしないのでは？
チャット化とかのタイミングでは作り直しが必要になるかも？
GitHubのreleaseは、使えないのかな？
昨日のツリーにぶら下げるか迷った
リリースに含まれる各ファイルは、2 GB以下でなければなりません。 らしい
ある程度の規模までのプロジェクトならいけるのか？
分割すれば、、！
:-rw-r--r-- 1 nishio staff 1205792548 Apr 8 03:06 vecs.pickle
-rw-r--r-- 1 nishio staff 8905528 Mar 22 18:11 langbook2.pickle
-rw-r--r-- 1 nishio staff 137555937 Mar 15 00:56 tkgshn.pickle
-rw-r--r-- 1 nishio staff 503209270 Mar 15 00:56 motoso.pickle
-rw-r--r-- 1 nishio staff 85694092 Mar 15 00:56 blu3mo-public.pickle
-rw-r--r-- 1 nishio staff 404339530 Mar 15 00:55 mtane0412.pickle
-rw-r--r-- 1 nishio staff 588214717 Mar 15 00:34 nishio.pickle
-rw-r--r-- 1 nishio staff 18629402 Mar 9 11:01 qualia-san.pickle大体問題なさそう
「/nishioで600MBです」「2GBを超える人が出てきたらその時に考える」でいい気はしてきた
「/omoikaneは50MB超えてて、/nishioは40倍の規模だから2GB超える」という見積もりのミスについて
ページ数で40倍だからと考えた
/omoikaneは小説や雑談など分量の多いコンテンツが多い
キャッシュを「バイナリリリース」のような扱いに…
まぁでもある種的を得てるような
Github Actionsの中で最新のリリースを取得してダウンロードできれば…
Get the latest release: リリース - GitHub Docs
できそう
リリースを使うスタイル、むしろ面白いのでは
つまり「ここに自分のプロジェクトのバイナリインデックスがあるよ」とURLで示すだけでみんな/villagepump/Scrapbox ChatGPT Connector座談会モードができる
Resource not accessible by integration
お、Releaseできた
ダウンロードできたかと見せかけて133bytesしかない
いや元から133bytesしかない
あ、なるほど、Git LFSのせいか
一見できたように見えてできていなかった
できた
古いのは自動でdraftになってた
Downloadもできた
個別のテストはできたので本体に組み合わせる
まず手順を書いてみる
リポジトリからpickleを削除
ダウンロードのコードを入れる
アップロードのコードを入れる
備考
現在のところ、キャッシュをLFSで保存するときについでにJSONをコミットしている
これは機械的に扱える変化の履歴があるという意味では便利
とはいえScrapbox自体のバックアップもあるし要らないのではという説もあり
要らないか
少なくともここでやるのは単一責務ではない
ダウンロードして新しい埋め込みを計算した後アップロードで死んだ
古いリリースをdraftにするのはできているのに、そのあとでtagNameの重複でエラーになっている
たぶんtagNameとコミットが両方同じでない場合にエラーになるのだろう
一旦手動で削除してみた
あっ、その場合はダウンロードでリリースがないから死ぬのか
あっ、リリースもリポジトリも両方消してしまったw
Github Actionとかいうリモートでしかもファイルを直接いじらない環境で動くコードを書くのは難しい！
そもそも状態を持たないのがいいのに巨大な状態を持たせようとしてるわけで！
新しいリリースを作る前に古いのを削除
3枚目でコミットIDが変わっているのがわかる
ちゃんとリリースからダウンロードしたキャッシュで90%の処理をスキップできてる
よし、全部通してうごいた！
まとめ
Git LSFに課金しないでも/nishioの3倍程度の規模まで動くようになった