はじめに
こんにちは、ランサーズでエンジニアをしている岡田です。
今回は新卒2年目に経験したベクトルデータベース移行の話をさせていただければと思います。
もう一年も昔の話なので、現在はサービスも快適に利用していただけますし、ライブラリも安定してきていると思います。
ただ、苦労した思い出を、経験のある方は「似たようなことあったわ」と、今まさに苦労している方は「自分だけじゃないんだ」と思ってもらえれば嬉しいです。
何があったのか
目まぐるしく変化する社会において、新規事業はとにかく早くリリースしてみることが重要です。
弊社がAIを使った新サービス「ランサーズ ジムインAI」をリリースするとなった時も同じでした。
いち早く価値提供するために、使えるものは使っていく。
簡単に実装できるのであれば、新しいOSSライブラリの導入はビジネスにおいて当然の判断です。
「ランサーズ ジムインAI」でも、自社のノウハウを知識として利用できるRAGの実装は急務でした。
そこで白羽の矢が立ったのが、ファイルベースでRAGを利用できるLlamaIndexです。
ファイルベースなら、検索エンジンやデータベース等のインフラの整備も必要なく、AIが参照する情報が混在することもありません。
開発段階では、ファイルの読み込み時間も書き込み時間も大して問題にはなりませんでした。
ただ、リリースして半年ほど経つと、ありがたいことに様々な用途に使われるようになって、RAGで参照するファイルに大規模なデータがアップロードされるようになりました。
すると、LlamaIndexで知識を検索するために、ファイルからベクトルを読み込む時間が問題になってきました。
ひどい時は読み込みに5分以上かかり、AIからの応答が全然返ってこない、という事態に陥りました。
上司から
「ファイルをアシスタントにアップしてるのですがアップが終わらず。ちょっとここは企業から特に求められるところになるので、早々に対応したいです・・」
と言われ、LlamaIndexでファイルベースのRAGを使う限りどうしようもないことを報告。
そして、毎度読み込むファイルベースではなく、すぐに検索結果が得られるベクトルデータベースに移行することになりました。
何をしたのか
ベクトルデータベースへ移行するために行った対応は以下の通りです。
- LlamaIndexのコードを読んで、どうすればファイルからデータベースに移行できるのか
- LlamaIndexのファイルベースの読み込み方法を理解
- LlamaIndexのベクトルデータベースの保存方法を理解
- LlamaIndexでファイルベースの読み込みをした後、別のベクトルデータベースに保存する実装
- 移行先のベクトルデータベースの選定
- 移行する上で重要な要素の洗い出し
- ベクトルデータベースの探索
- 各ベクトルデータベースの特徴の理解
- 各ベクトルデータベースが必須項目を対応しているか確認
- 各ベクトルデータベースでかかるコストの調査
- 各ベクトルデータベースの利用に必要なインフラ構成
- 各ベクトルデータベースの運用方法
- 安全に移行するための実行計画
- テストコードの作成
- メンテナンス画面の作成
- 移行方法の検討
- 実行計画のドキュメント化
- 実行計画の共有と意思決定
- 移行失敗した際の対応マニュアル
- 実行前の徹底したチェック
やることは山積みなのに、他人がアップロードした情報を参照できてしまうと情報漏洩の危険性がある。すでにサービスは走り出してしまっているのでユーザーは待ってはくれず、開発人員は少ないから移行準備しながら開発していて目が回る状態でした。
それでも、7月中旬から調査をはじめて9月中旬には開発を終えてレビュー待ち、10月上旬に本番環境でのインフラ構築のためSREに説明、約4ヶ月かけて11月上旬にリリース。
しかも、他のバグ対応や別の機能リリースもやりつつ、レビューもして、月末月初の対応までやって、
（レビューやインフラ構築は協力していただきつつですが）ほぼ1人で1からやり切ったのは今振り返ると自分を褒めてあげたくなり思います。
何が大変だったのか
初めはとにかくLlamaIndexのコード理解が大変でした。
メジャーバージョンが0のOSSライブラリは、それだけ不完全な状態ということなので、ファイルベースからベクトルデータベースに移行するなんて想定されているはずもなく。
ファイルの場合はどこに何が保存されるのか、ベクトルデータベースに保存する前にはどのクラスの何に情報が格納されていれば良いのか、ひたすらコードを追い続けました。
やっとの思いで、RAG用に保存されたファイルを読み込んで、ベクトルデータベースに保存する一連の処理を作ることができました。
「これで移行ができる」となった矢先、「じゃあ、何に移行する？」という問題が降ってきます。
AIについてある程度の知識を持っていても、新卒2年目でインフラとなるベクトルデータベースを選定するというのは酷でした。
ベクトルデータベースもこれまた過渡期のため、海外から国内、セルフホスティングまで選択肢は様々でした。探せば探すほどに新しいものが見つかるような状況で、どこまで調べればいいのか分からなくなっていました。
主要なものは出切ったかな、と思ったら、そこからは各ベクトルデータベースが我々のサービスの要求にマッチしているのかを調べる時間です。調べてもはっきりしたことが書いてなかったり、コスト計算が複雑で初めてのことだから試算も難しかったり。雑に決めることもできましたが、前述した通り「情報漏洩の危険性がある」機能になるので、慎重に選ばないとサービスどころが会社にも損害が出ます。
結局、悩みに悩んだ私は、候補をいくつか出して最終決定を上司の鶴の一声で決めていただいた形だったと思います。
最後に移行するために必要なテスト・メンテナンス機能・移行マニュアルを準備します。
人の目だけでは怖いのでテストコードを書き、メンテナンス用の画面なんてリリース時に用意していなかったので、メンテナンス機能も1から実装しました。
もし移行のタイミングで病気にでもなれば、誰か代わりにお願いするしかありません。その時のために（もちろん自分のためにも）、移行手順と失敗した時の巻き戻し手順を書いた移行マニュアルを準備しました。
全てを理解しているのは自分だけですから、見落としがないように何度もチェックしました。
さいごに
新しい試みをする新規事業では、最近登場したOSSライブラリを使うことも、少ない開発体制で進めることも、あるあるだと思います。
今回の移行を避けようと思うと
- リリース時点でベクトルデータベースを用意しておく → リリースが遅れる
- 移行をせずにファイルベースのまま放置 → ユーザー体験が悪くなって離れていく
となり、何かは犠牲にしなくてはいけなかったでしょう。
これが新規事業の開発現場のリアルだと感じました。
言えることは、出てきたばかりのOSSライブラリの利用は慎重になった方が良いし、利用するならどんなリスクがあるのか把握しておく、ドキュメントとして残しておく、そのくらいの余裕は持った方が良い、くらいでしょうか。
日々、奮闘されている方々、お疲れ様です ❤️🩹
Discussion