Technik für KI-unterstützte Software-Entwicklung（「AI 支援型ソフトウェア開発のための技術」）バージョン 1.0 は、OSSBIG のプロジェクト「KI-unterstützte Softwareentwicklung」が作成したドイツ語のガイドである。このプロジェクトは 2023 年秋に OSSBIG のワーキンググループとして始まった。そのきっかけは、技術的なノウハウの不足が IT のこの新しい分野を導入するうえでの大きな障害になっているという認識だった。執筆者たちは、この作業をボランティアとして商業的な利害なしに行ったこと、そして本文の一部は、チームが書いたベースとなる文章から生成 AI を用いて作成され、その後グループによって改訂されたことを明記している。
このガイドは、生成 AI をソフトウェア開発に組み込むための実践志向の手引きと位置づけられており、企業環境での生成 AI の活用を計画、実装、監督しようとする IT マネージャー、運用担当者、意思決定者、開発者を対象としている。その焦点は、コード補完、エラー検出、テストといった繰り返し発生するタスクの自動化にある。ガバナンスは明示的に対象外とされ、OSSBIG の別の推奨文書に委ねられている。
詳細
- メリット。 ガイドは、開発プロセス全体にわたる AI の可能性を列挙している。コード生成と補完、自動テストとデバッグ、セキュリティ分析、CI/CD、ドキュメント作成、リファクタリング、言語間の移行、ローコード／ノーコード開発であり、これらをより速く効率的な開発としてまとめている。コード補完ではハルシネーションはそれほど大きな問題ではないと指摘している。たとえばユニットテストによって品質を担保できるからである。
- LLM の仕組みと失敗のしかた。 ガイドはトランスフォーマーアーキテクチャを一般的なレベルで説明し、LLM の出力を評価する方法（ユーザーのフィードバック、A/B テスト、単語ベースの指標）を述べたうえで、弱点を列挙している。出力を検証する組み込みの手段がないまま不正確さが生じること（見つけにくいセキュリティホールやバグが紛れ込みうるため、生成されたコードにとって大きな問題だとしている）、ハルシネーション、文書構造の認識の弱さと長い対話におけるコンテキストの喪失、ドメイン知識の欠落、過学習と学習不足、バイアス、透明性の欠如、そしてリソース消費の大きさである。
- LLM の運用。 ガイドは、提供者のエンドポイント経由でしか利用できず入力トークンと出力トークンごとに課金されるクローズドソースのモデルと、オンプレミスでも外部の提供者のもとでも実行できるオープンソースのモデル（厳密にはオープンウェイトのモデル）とを対比している。オンプレミス運用（データが社内にとどまりベンダー依存がないが、保守、パッチ適用、社内でのセキュリティ確保が必要）とクラウド運用（従量課金でインフラの維持負担が少なく試行が容易だが、アプリケーションの下でモデルが変わってしまうことやベンダーロックインがある）を比較検討し、十分な GPU 容量を持つ提供者を見つけるのが難しかったと述べている。
- プロンプトエンジニアリング。 ガイドは、通常エンドユーザーからは見えないシステムプロンプトとユーザープロンプトを区別し、言い回しのわずかな変化が結果を大きく変えうることを強調している。ほとんどのアプリケーションではモデルの開発やファインチューニングは不要であり、代わりにプロンプトエンジニアリングによって回答の質を改善できることが多い、と結論づけている。
- 統合と MLOps。 ガイドは、LLM をビジネスロジックに組み込むためのよく知られたフレームワークとして LangChain を挙げており、これには自社の文書を対象とした検索拡張生成（RAG）も含まれる。また、LLM のための MLOps は DevOps とは異なると指摘している。モデルの再学習はめったに行われない一方でリソースはより高価であり、プロンプトエンジニアリングが加わり、監視と評価は唯一の正解がないタスクに対処しなければならない。
- セキュリティ。 ガイドは LLM アプリケーション向けの OWASP Top 10 を紹介し、クローズドソースのモデルで社内文書を対象に検索を行うとそれらの文書が外部の提供者に送られる一方、ローカルで実行するモデルなら文書を社内にとどめられると指摘している。また、公開チャットボットの運営者に対して プロンプトインジェクション への警告を発している。
最終章では、ワーキンググループ自身の実験が報告されている。
- オープンソースのコーディングアシスタント。 グループは、Hugging Face のオープンソースの IDE プラグインを、HTTP 経由で提供される LLM に接続して動かした。IntelliJ 版は、自己署名証明書を用いる企業のプロキシの背後で動作させるためにフォークしてパッチを当てる必要があり、その後、共有の言語サーバーが VS Code 版向けに改修されたことで互換性がなくなった。StarCoder や CodeLlama などのモデルのテストには、ホスト型の推論エンドポイントが使われた。
- コードベースに対するファインチューニング。 2 つのオープンソースプロジェクトでファインチューニングした StarCoder モデルは、それらのコードベースのデータ構造を提案するようになったが、提案の全体的な質はファインチューニング前よりも大幅に悪化した。グループはその原因を、分析を行わずにコードベース全体で学習させたこと、最適な時点を過ぎても学習を続けたこと、そしてパラメータを調整する時間が足りなかったことに帰している。
- その他の実験。 推論プログラム llama2.c の主要な行列積を CUDA で GPU にオフロードしたところ、生成速度が毎秒約 6 トークンから約 17 トークンへとおよそ 3 倍になり、モデルを GPU メモリに完全に載せておかなければならない理由が示された。セルフホストの Web チャットボットは簡単に構築できることがわかった。また、Azure への GPT-3.5 モデルのデプロイは短時間で済んだが、Azure の多数のオプションを把握しきるのは難しかった。