文芸的データベース - 文書の作成とそのデータベース化を同時に行なう手法
「文芸的データベース」とは、株式会社Helpfeelのshokai.iconが提唱している、 文書の作成とそのデータベース化を同時に行なう手法で、 文書とデータベースのフィールドをひとつの画面に混在させながら 追加したり修正したりして同時に構築していくことにより、 完全に整合性のとれた文書とデータベースを構築しようというもの こんにちはshokai.icon
shokaiです
コンセプトと機能を考えて実装・運用をしています
右のメニューのStart presentationでスライドになります
今日の話
1. 文芸的データベースとは
2. 機能設計の工夫
3. 実装の面白い所を紹介
既に全てのprojectで使えます
が、もしAPI quota超えた場合はbusiness projectを優先します
各ページから抜き出す項目を宣言すると
せっかくなので実演しますshokai.icon
https://gyazo.com/27108bf1a7ce89a23b122cd0c25e51a8
世によくあるやつ
人間が定型データを入力させてテーブル作ると、ドキュメントが大量生成されるシステム
その逆です
人間がドキュメントと項目定義を用意すると、LLMがテーブルを生成してくれる
抜き出された項目をページの右側に表示したもの
本文を更新すると、Infoboxも自動的に更新される
https://gyazo.com/d331ab2f889a31f07d1c0ab2ffdbb578
名前とデザインの元ネタ
Wikipediaの機能である元祖Infobox
2列目以降にプロンプトを書いて、正規化・ソートできる
https://gyazo.com/283da90609b4536c920a49d937cdb2ee
https://gyazo.com/e0f17f6f9e1473624b89678a5e6543d3
これちょっとわかりにくいですが、人間ではなくLLM向けの注釈や作業指示ですshokai.icon
何のために作ったのか
ドキュメントを各自が自由に元気よく書きつつ、
これは現状のCosenseの書き心地を維持したい
つまり
ページを書く時は、そのページに書いてほしいと要望されている項目を意識しろ
面談や議事録、スペック表、仕様検討などに必要な項目をInfoboxの抜き出し項目として定義しておこう 使用例を見ながらデモします
使用例
ガチで書くとこうなる。2列目にプロンプトが書ける
「対応予定時期」を必ず書け
1つのページに複数のInfoboxを設定できる
人物名鑑の例
用途
社内ミーティング、商談、面接、1on1
必ず記載すべき事がずっと右側に表示されていて、書かないと空欄になっている
例:「次回までにやっておく事」
数値、日付、URLなども抜き出せる
未着手、実装中、完了、中止など
人物名鑑、プロダクト名鑑、機能リスト
ちゃんと抜き出されない場合は本文の書き方が悪い
LLM可読ではないドキュメントを人間に読ませるのは失礼 項目定義やプロンプトではなく、本文を書き直すべきshokai.icon
例:システム運用のアイディア出しでは必ず仮説・検証方法・対策を書く
機能設計の工夫
楽しく子機能を使っていたら、便利な親機能の準備が整う
子機能
ページから抜き出された右側がリアルタイムに更新される
抜け漏れチェックできて便利
親要素
抜き出した要素をテーブルにしてソート・フィルタできる
4つの操作がある
1. 項目を宣言する
2. 本文を書く
3. 抜き出し結果を見る
4. テーブルを見る
どういう順番で操作しても破綻しないように作った
ドキュメント作成と項目定義は、どちらを先に行ってもよい
たくさんドキュメントを書いてから、項目定義してもよい
項目定義してから、ドキュメントを書いていってもよい
ドキュメントと項目定義が揃った時点で、即座にテーブルが生成される
保存ボタンも更新ボタンも無い
宣言を書くと抜き出される
宣言を削除すると消える
いつも通り本文を書くだけ
適当なタイミングでInfoboxは更新される
実装の面白い所
Infoboxの更新フロー
code:mmd
sequenceDiagram
participant ブラウザ
participant サーバー
ブラウザ->>サーバー: Infobox更新してください(HTTPリクエスト)
サーバー-->>ブラウザ: 更新しとくよ(HTTPレスポンス)
サーバー->>ブラウザ: 今更新してる(websocket)
ブラウザ->>ブラウザ: spinner回します
サーバー->>ブラウザ: できた(websocket)
ブラウザ->>ブラウザ: spinner止めます
ブラウザ->>サーバー: Infoboxください(HTTPリクエスト)
サーバー-->>ブラウザ: どうぞ(HTTPレスポンス)
「更新中」と「完了」のステータスがサーバーからwebsocketでpush通知される
Infoboxのテキストの取得は、websocketで通知されたブラウザ側からHTTPで取りに行く
なぜこうなっているか
ChatGPTからのレスポンス速度がまちまち
10秒近くかかる事もある
多重実行が起きると順番が入れ替わる
websocketにデカい文字列を流したくない
抜き出し結果のテキストは大きくなる可能性がある
websocketではあまり送りたくない
同時に1000人が見ているページかもしれない
ちょっと古い本文から作られたInfoboxが最終データとして残らないようにしてる
APIのcache
本文+プロンプトのMD5 hashを、cacheのkeyにしている
問題発生
Node.jsのメモリ使用量は大きくなっていないのに、サーバーのメモリ使用量が枯渇した
原因
1 msec 〜 10 msecの間CPUを専有し
HTTPリクエストが処理できなくなり
受信したHTTP / MongoDB / Redis接続のTCP socketは、kernel領域のメモリ空間にたまり続けてしまう
解決
chunkに分けて、細かくevent loopに処理を戻してあげながら、MD5計算するようにした
Infobox定義更新からの全ページ一括更新は、タスクマネジメントをブラウザ側でやってる
サーバーにqueueを持っていない
batch処理もしていない
以下をすべて満たす方法を考えていたら、そうなったshokai.icon
Infobox定義の変更をトリガーとした文芸的データベースの全件更新は
ユーザーの画面に表示されている順に、上から処理したい
負荷をランダムなNode.jsプロセスへ分散もしたい
並列数を上げて高速化もしたい
実行中に追加の変更が来たら再実行もしたい
両立させる
負荷分散・高速化・運用・ユーザー体験
パフォーマンスチューニング大変だった
おわり〜
文芸的データベースとInfoboxを使って、書いてほしい項目を宣言しよう
ドキュメントを各自が自由に元気よく書きつつ、複数人でのコラボレーションも正確にできるはずだ