pVectorSearch2023-06-07
>ネクストアクションはエクスポートを介さずに公開プロジェクトのデータを吸い取ってインデックスにすること
/halsk 1281 pages
/yuiseki 2679 pages
/tkgshn 5648 pages
まず/halskから
127 sec
残り2つ
335 sec
done
いまrequestsで叩いてるところをaiohttp.ClientSessionで叩くようにする必要があるのだなー
"いまrequestsで叩いてる"はFalse
openai公式ライブラリを使ってる
これはlistで渡してバッチ処理ができる
3,500 RPM / 350,000 TPM
並列化をするレイヤーが当初の予定とは違っていた
embed APIを呼び出す関数かと思ってた
インデックスを表現するクラスにバッチで実行するメソッドをつけた
できたので走らせて昼食に行く
>This model's maximum context length is 8191 tokens, however you requested 9158 tokens (9158 in your prompt; 0 for the completion). Please reduce your prompt; or completion length.
oops
PDBで止めて観察
:(Pdb) print(list(map(get_size, texts)))
[85, 122, 88, 118, 5, 106, 100, 100, 9158, 9152, 9164, 121, 113, 81, 456, 133, 45, 6, 6, 7, 514, 351, 278, 441, 322, 27, 210, 515, 517, 252, 23, 28, 363, 92, 486, 318, 350, 326, 276, 340, 418, 355, 309, 292, 366, 334, 273, 387, 349, 341]あー、なるほど、これで1行なのか
チャンクわけしたものが巨大である場合、先頭だけ取ってエンベッドする仕様にする
元々そうしていたが、並列化にした際にエンバグしてたので長いままAPIに投げてしまった
このトラブルのせいでどれくらい時間が掛かるのかわからなくなってしまった
238/238 [11:46<00:00, 2.97s/it] これが修正後に走った/tkgshnのデータ
5748ページあるScrapboxが1万ちょいのチャンクに分けられ、50個ずつ238個のバッチで処理されている
1バッチあたり3秒くらいで、全部で12分という感じ。
Qdrantに入れる
ResponseHandlingException: The write operation timed out /nishioの時は
wait=True なしで叩き込めたんだけど、3人分を一度に入れようとしたら1.5人で死んでしまったWALが溢れたのかな？
追記: インデックス作成との衝突
wait=True をつけたらこんな感じ 117/117 [02:57<00:00, 1.51s/it] 44/44 [00:54<00:00, 1.23s/it] まあ数分で入るから気にすることではないか
クロス検索できるようになった
あれ？なぜかyuisekiばかりヒットするな？？？
そんなことある？
あっ
client.recreate_collection してたwやり直し
wait=True してても ResponseHandlingException: The write operation timed out になるな sleep(1) しててもなるあー、なるほど、インデックスの生成を止めるのね
23/23 [00:34<00:00, 1.48s/it] 117/117 [02:59<00:00, 1.53s/it] 44/44 [01:15<00:00, 1.72s/it] できた
横断検索できてる
余裕だな
今回検証できたこと
相手がScrapboxの公開プロジェクトであれば、特に相手の作業は必要ない
時間的コストも金銭的コストも大したことない
>@yuiseki_: 複数人の個人Scrapboxを結合してベクトル検索できるようにして協働や合意形成などにおいて有用か検証しますと言われると、自分のScrapboxに何をどれだけ書くのかという優先度が爆発的に高まるのを感じる
>@nishio: もうしばらくすれば誰でもこれに議題を投げられるようになる
iPhoneで見たら酷いことになってたw
>@yuiseki_: とりあえず重要な情報を100ページくらい追加しました
update機能を実装せねば...