韓国大統領選の公約情報を提供するプラットフォーム
(github.com/MinsuChae)第21代大統領候補の情報をひと目で
- タイトルは大げさに付けましたが、簡単に言えば第21代大統領選挙に向けて、大統領候補の略歴や選挙公約、候補者をめぐる論争などを提供することを目指したプロジェクトです。
- 🔗 https://daeseoneunjigeum.com
作った目的
私の周りの20代の知人たちが大統領や大統領選挙に関心を示しており、最近のさまざまな出来事によって若者の選挙への関心も高まっているため、大統領選挙への参加を後押しする必要があると考えました。
しかし実際に投票しようとすると、候補者を一人ずつ詳しく見るのは難しく、他の候補と比べて誰がより良いのか判断するのも簡単ではないのが現実でした。
「それなら、LLMで質問‑回答をすぐにしてくれるサイトを作ってみよう。」 というとてもシンプルなアイデアから作ることになり、企画には2〜5日、コーディングとデプロイには2日ほどかかりました。
提供機能
- 候補者ごとの略歴・公約・論争の要約を提供
（選挙公報がまだ出ていないため、現在はニュースベースの草案です。） - 「○○候補の代表的な公約を教えて」のように尋ねられるリアルタイムQ&A
（Gemma‑3‑1b‑itモデルが回答を生成します。CPUだけで動かしているので 😅 ）
今後の計画
- 選挙公報の資料に基づく情報提供
- 開発者界隈レベルではなく韓国国民レベルで大きな関心を得る、または機関などから支援を受けた場合、Gemma‑3‑27bにLLMモデルを改善
惜しい点
- モデルのサイズ
本来は27 bパラメータ版を動かしたかったのですが、VRAM 48 GBが必要でした。
結局、1 bモデルで妥協しました。（A6000を1台借りるだけでも月60万ウォンほど必要です。） - 低いデータ品質
ニュース記事などを通じてスクリーニングはしましたが、公式資料がないため、まだ具体的な公約などを把握しにくいという問題があります。選挙公報が公開され次第、最優先で更新する予定です。 - LLMモデルの応答速度
簡単なあいさつなどであれば数秒以内に応答しますが、公約などの核心的な質問をすると1分以上かかる問題があります。リアルタイムと言うには無理があります。CPU演算だからです。😅
お願い
- 誤った情報や使いづらさを見つけたら、コメントでお知らせください。
- GPU支援/クラウド提携はいつでも歓迎です。
- 過度な負荷テストだけは避けていただけると助かります！
最近は若者の選挙参加が重要になってきているだけに、政治情報を簡単かつ素早く得られるようにするため作ってみました。
一度立ち寄って気になる候補を検索してみて、不足している点を指摘してください。🙏
私の専攻はコンピュータ系ですが、開発者寄りというよりAI研究者寄りの立ち位置が強いため、テストコードやデータ型検査などは本職の開発者の方から見ると気になるかもしれません。
9件のコメント
こんにちは。この記事を見て着想を得て、似ていますが少し形を変えて私も作ってみました。個人的にAI応用開発をサービスとしてさまざまな可能性を試しているのですが、今回は技術的なアプローチと実装に関して良い経験になりました。
5月8日から5月11日まで、gemma 12bで稼働させます。GPUクラウドコンピューティングと似たサービスを提供する事業者が実施したベータテストに参加し、関連する負荷テストを行い、実際の負荷が分かるように適用しました。
関連情報は継続的に修正し続けるのが難しいため、大きな情報更新があるたびに更新しています。次回の更新は正式な選挙候補者が確定した12日午前で、その次は選挙公報資料が公開されたら、これをRAGを通じて情報提供できるよう改善する予定です。
趣旨はとても良いのですが、こうした情報をLLMベースで伝えると（不正確に提供してしまうと）、法的に問題になる可能性もありそうです..!
いくつかのサイトにはまだ掲載していませんでしたが、内部テストによるものなのか誰かなのかは分からないものの、過度な負荷でゾンビ状態になってしまいました。ローカルAIで、軽量なモデルなのでここまで深刻な負荷がかかるとは思っていませんでしたが、仮想化環境で動かしていたところ、ゾンビ状態に陥ってしまいました…;; 確認後に復旧させます。
ローカルAIサービスを提供されている方は、GPUで演算しているならまだましかもしれませんが、CPUは…諦めたほうがよさそうです。誰かがそれほど大量に使ったわけでもなさそうなのですが…;;
物理サーバー上で大きな処理が行われていなかったサーバーを、docker containerで起動してサービスしていたのですが、いくら低スペックだとしてもssh接続すら厳しいほど過度なCPU負荷がかかりました…; CPU制限をかけていなかったので、そのせいでホストサーバーにまで問題が出ていますね…
実際の利用者が多く使ったようにも見えないのですが…
OpenRouterのkeyを発行して使うようにしたり、WebLLMやGemini Nanoを使ってみることも検討されましたか？
ご指摘ありがとうございます。まず、静的サイトではないので、あえてフロントエンド側で処理するよりはバックエンドで実行し、APIキーをできるだけ隠そうと考えています。
以前はそこまで考えていませんでしたが、OpenAIや他のAPIは選挙日の7日前か14日前から使う予定です。
それまでは、どれだけ小型モデルでコストを抑えられるとはいえ、どの程度使われるか見積もれないため、利用には慎重になっています。
WebLLM はおかげで知ることができました。私はディープラーニングを研究する立場として、モデルをCDNなどで配信して実行することを考えていたのですが、あのように配信してくれるものがあると知りました。ただ、依然として悩ましい部分はあります。フロントエンドで実行されれば、もちろん負荷は減りますが、初期のモデル配信に少し時間がかかるのが問題ではないかと思っています。この点は悩みどころですね。それでも、おかげでああいった良いプロジェクトを知ることができました。まだきちんと見られていないので、ReadMe にあるモデルだけが動くのか、互換性のあるモデルも配信できるのか、それとも別のCDNに載せる必要があるのか、まだ十分には理解できていません。私の考えでは、モデル自体は別途配信する必要がありそうです。そうなると、この部分が悩みの種になりそうですね。海外は分かりませんが、国内でモデルを配信できるCDNがあるのか気になっています。私が調べた国内のCDNは、たいてい画像しか許可していない認識なので。
うわっ T_T
LLM 1Bモデルですが、やはり計算量が多いようです。昨日はかなり混乱していて、突然containerがゾンビ状態になってしまい大変だったのですが、dockerでCPU使用率の制限を何度も変えながらテストした結果、同時に3〜5件のリクエストをさばくのがやっとというレベルのようです。
ある意味、簡単なプロジェクトを進めながら、数年以内にローカルAIの時代が来るだろうし、もしGPUリソースが不足した状況でLLMサービスを提供したらどれほど負荷がかかるのかを知りたかった、という面もありました。
サーバーを動かしているCPUは AMD 7700 です。結局、ローカルAIでやるにはいろいろなことを考慮しなければならないと分かりました。思った以上にPOSTを送ってから応答が返ってくるまでにタイムアウトが発生する問題があり、結局これを安定したサービスにするにはGPUや推論用の機器（たとえばGoogle TPUなど）が多く必要で、応答速度の面でも有利になり、キュー形式で提供できるようにしなければならないという考えに至りました。
実際、国内でLLMをきちんと運用している会社は少なく（すでに知られているNAVER、カカオ、Upstageなど）、チャットボットも決められた機能をこなすケースが多く、LLMモデルのAPIをつないでいる場合もあるので、どれほどの負荷になるのか、またWebでこうしたサービスを提供する際にサーバー負荷を減らすにはどうすべきかを考えるきっかけになりました。
ちなみに、このコメントを見た人の中には、モデルをそのまま渡して配信すればいいのでは、と思う人もいるかもしれませんが、gemma3 1bの容量は1GBを超えており、サーバーホスティングを使っていてもこのトラフィックには耐えられないと考えました。
アプリの形で何とかプリインストールできるかもしれませんが、Webではどうすればサーバー負荷を抑えながらサービスを提供できるのかについて、しっかり考えた企業ほど低い維持コストで運用できるのではないかと思います。
貴重な経験の共有を本当にありがとうございます