WeClone: Telegramのチャット履歴からLoRAでAI分身を作るパイプライン

誰のためのツールか: 履歴を資産に変える発想

WeCloneが解こうとしているのは、自分の書き言葉の癖をモデルに覚えさせるまでの手間である。READMEは「One-stop solution for creating your digital avatar from chat history」と位置づけ、チャットデータの書き出し、前処理、モデル学習、配信までを一続きの流れとして提示している。対象は、Telegramで日常的に長く会話してきた個人。データが既に手元にあり、それを外部サービスへ預けずにローカルで学習させたいという動機が前提になっている。

もう一つの前提はGPUである。READMEのハードウェア要件表は7Bから70Bまでを並べ、LoRAやQLoRAの行まで用意している。つまり「ちょっと試したい」層ではなく、VRAMを確保できる人を想定した作りだ。画像モーダルのデータも学習に混ぜられるため、テキストだけでは拾えないやり取りも対象に入る。

データが学習に届くまでの流れ

構造は素直である。Telegramから書き出した会話を取り込み、前処理でプライバシー情報をふるいにかけ、LLaMA Factory経由でLoRAのSFTを回し、できたアダプタをボットに結びつけて配信する。READMEの機能表を見ると、Telegramはテキストと画像に対応し、スタンプは絵文字へ変換される扱い、音声と動画は非対応、リンク共有も非対応と明記されている。取り込めないものがあることを先に把握しておかないと、前処理後の件数が想定より減っていて驚くことになる。

学習側はLLaMA Factoryに委ねる設計だ。READMEはQwen2.5-VL-7B-Instructを既定としつつ、LLaMA Factoryが対応する他のモデルや手法も使えると書いている。つまりWeClone自身はデータの取り込みと配信の受け渡しに責任を持ち、学習の内部は外部ツールに任せる。この分担は、学習手法を差し替えたい人には都合がよい。逆に、学習ループの中身まで自分で制御したい人には一段遠い。

セットアップ: uvとsettings.jsoncの2点

手順はREADMEに具体的に載っている。CUDAは12.6以上が必要で、既に入っていれば読み飛ばしてよい。依存関係の導入はuvを使う形が推奨されている。

git clone https://github.com/xming521/WeClone.git && cd WeClone uv venv .venv --python=3.12 source .venv/bin/activate # windows .venv\Scripts\activate uv pip install --group main -e .

次に設定ファイルの雛形を複製する。

cp examples/tg.template.jsonc settings.jsonc

以降の調整はすべて settings.jsonc に集約される。READMEも「Training and inference related configurations are unified in the file settings.jsonc」と明記しており、学習と推論の設定が1ファイルに閉じているのは見通しがよい。READMEには続けて、PyTorchがCUDAを認識できるかを確認するコマンドの説明が始まるが、そこから先の本文は途中で切れている。確認方法の詳細はリポジトリのドキュメント側で追う必要がある。

VRAM要件という現実的な壁

READMEの表で最も実用的なのはVRAMの見積もりである。LoRAやFreeze、GaLore、APOLLO、BAdamを使う16ビット精度の場合、7Bで16GB、14Bで32GB、30Bで64GB、70Bで160GB。QLoRAの4ビットなら7Bで6GB、14Bで12GBまで下がる。フル微調整は7Bのbf16で120GBと、個人の環境ではほぼ非現実的だ。

ここで注意したいのは、必要VRAMが小さいことと結果がよいことが別だという点である。READMEは「The performance of the 7B model is average, while models with 14B or more parameters tend to deliver better results」と書いている。つまりQLoRAで7Bを6GBに収めても、得られる分身の質は平均的と著者自身が認めている。手元のGPUで現実的なのは14B以上をQLoRAで回す線であり、その場合でも12GBから20GB程度を見込むことになる。この一文は、スペック表だけを見て7Bで始めようとする人への警告として読める。

配信先の広さと、Windowsの扱い

配信側はTelegram、Discord、Slack、そしてWeChatの個人アカウントに対応する。WeChatはopenclaw-weixinに基づくとREADMEに記載がある。WhatsAppはデータソースとしても配信先としても工事中の表示で、DiscordとSlackもデータソース側は未対応だ。つまり入力はTelegram、出力は複数、という非対称な状態が現状である。

実行環境についても記述がある。Windowsは厳密には検証されておらず、WSLを実行環境として使うよう案内されている。ネイティブのWindowsで動かそうとするより、最初からWSLに入るほうが無駄が少ない。加えてREADMEは「WeClone is still in rapid iteration phase, current performance does not represent final results」と述べており、バージョン間で挙動が動く前提で接するべきツールだ。

向かない場面と、代わりの選択肢

WeCloneが不要なのは、特定の口調を再現したいだけの用途である。数件の会話例をプロンプトに埋め込む手法や、システムプロンプトで人格を指定する手法のほうが、GPUも学習時間も要らず、履歴を書き出す手間もかからない。WeCloneが効くのは、数千件規模のやり取りから語彙や言い回しの癖を拾いたい場合で、その差はデータ量に比例する。

もう一つの代替はLLaMA Factoryを直接使う道である。WeCloneは学習部分をLLaMA Factoryに委ねているので、データの整形だけ自前で行えば、学習以降は同じツールで完結する。違いは取り込みと配信の自動化を取るか、設定の自由度を取るかにある。Telegramの書き出し形式の解釈や画像データの混ぜ方を自分で組めるなら、間に一枚挟む理由は薄くなる。逆に、そこを書きたくない人にとってWeCloneの前処理は価値がある。

ライセンスと保守の見取り図

ライセンスはAGPL-3.0である。ネットワーク越しにサービスとして提供する形態では、ソースの開示が求められる方向の条件がかかる。自分専用のボットとして閉じて動かす分には影響が小さいが、他人に使わせる形にした瞬間に条件が変わる。ここは法的判断ではなく、採用前に自組織の配布形態と突き合わせて確認すべき論点として挙げておく。

保守コストは、モデルとCUDAの追従に集約される。CUDA 12.6以上という下限があり、依存はuvで管理され、学習側はLLaMA Factoryの対応状況に連動する。設定がsettings.jsoncの1ファイルに閉じているため差分は追いやすいが、リリースはv0.3.01、v0.3.02、v0.3.03と0.3系が続いており、README自身が急速な反復段階だと認めている。固定したバージョンで動かし、上げるときは設定ファイルの差分を確認する運用が現実的だ。

編集部の結論

自分専用のTelegramボットとして、手元のGPUで完結させたい個人に向く。逆に、クラウドAPIで十分な用途、14B以上を載せるVRAMを用意できない環境、商用クローズド製品に組み込みたい開発者には向かない。導入前に確認すべきは3点。Telegramのトーク履歴が実際に書き出せること、CUDA 12.6以上とREADMEのVRAM表で自分のモデルサイズが収まること、そしてAGPL-3.0の下で配信形態がソース開示義務に触れないかどうか。ここを確認せずに進めると、学習まで漕ぎ着けても配布段階で手戻りになる。

公式情報源

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. xming521/WeClone on GitHub