ZIKUUコアサービスは、
- LLM Broker（テキスト系LLMリクエストの中継）
- Vision Broker（Vision系LLMリクエストの中継）
- Light Auth（軽量な共通認証機能）
- Nerve（イベントとパイプライン管理）
- Context Pipeline Server（文脈抽出）
- Pivot Service（意味空間）
- Fact Builder（文脈を意味空間に投影）
- Repository Explorer（すべてのソフトウェアの調査・解説）
- Pivot Reasoning Engine（意味空間の断面を切り出して探索）
- Fact Build Tool（意味空間の再構成）
- Qdrant（ベクターデータベース）
- MinIO（画像・音声データベース）
- Gitea（原本固定）
- PostgreSQL（リレーショナルデータベース）
などから構成されるサーバー群のこと。
これらは、業種、分野、利用者の種類を問わない。
最近は、大きなコンテクストウィンドウを持ったLLMが増えている。
大きなプログラムの解析やコーディングをする、複数のAIタスクが長いコンテクストを共有するなど、さまざまな要求があるからだ。
コンテクストウィンドウは、プロンプトのデータ量に対して線形に増加するのではなく、指数関数的に増加するのが普通だ。
多くの開発者や研究者が、この問題を解決するために、LLM自体の研究、LLMの実行環境の研究をしてるが、ZIKUUは後者だ。
ZIKUUの場合は、
- 大きなサーバー、大きなGPUを大量に抱えられない
- すべてを自分の手の内に置くために、ローカルLLMを使わなければならない
といった制約から設計されたものが多い。
コンテクストウィンドウ問題もその一つだ。
これはCPS (Context Pipeline Server)の管理画面のスクリーンショット。
多くのRAG型のAIアプリは、左側のSegment Text Snapshotに表示されている、原本全文を読む。
ZIKUUのAIアプリは、右側のContext Unitsに表示されている、抽出された文脈の束だけを読む。
ZIKUU方式の方が、LLMに投げるプロンプトは圧倒的に小さく濃い。
しかも文脈束は、フィルターする、合成するといった操作が可能だ。
左側の原本は、Qdrantにも登録されているので、一般的なRAGアプリを作ることもできるが、無闇に読まない。必要になった時だけ読む。
これがコンテクストウィンドウ肥大化への解決策の一つになっている。
