2024年5月30日に開催されたChatGPT Meetup Tokyo #7で、ChatGPTとIBM Watson Discoveryを連携させたRAGのサービスについてLTした際の資料です。 動画（スライド画面＋音声）はこちらです。 https://www.youtube.com/live/ESdtIyMEktU?feature=shared&t=361 ※個人で作成したものであり、内容や意見は所属企業・部門見解を代表するものではありません。

はじめに こんにちは。ELYZA のML Engineeringチームの堀江 (@eemon18)、村山 (@zakktakk)です。 本記事では、弊社が2024/03/11にリリースした下記のデモについて、どのように70Bという巨大なモデルをホスティングしているのかを解説します。 まだデモを直接触れたことがないという方はぜひ一度以下のURLからアクセスし、140GBを超えるバイナリファイルからなるモデルがどのくらい高速に動作するのかを確かめてみてください。 本記事ではまず弊社推論アーキテクチャについて説明し、その後70Bを運用する際の技術選定や高速化の工夫について解説します。 推論アーキテクチャ 弊社のLLMアプリケーションのアーキテクチャは、平易に表すと以下の図のように構成されています。LLMの推論処理には時間がかかるため、アプリケーションと推論インスタンスはメッセージキューを介して非

最近はAIエンジニアを名乗ってるerukitiです。フロントエンドもバックエンドも、LLMを触るあれこれもやってるので、「AIエンジニア」くらいを名乗るとちょうどよさそうだなと思ってます。いずれLLM自体の開発なんかもやってるかもしれません。 LLMプロダクトを開発していると、構造化データを作りたいのに、Anthropic ClaudeのAPIにはJSONモードが無いことや、なんならJSONモードやfunction callingを使っても、データが正しい形式に従ってることは保証しがたい、みたいな自体に遭遇することがあります。 JSONが出力できたとしても、構造化データをうまく吐き出させるのは難しいものです。文字列を出力させたいけど、複数あるときは、配列なのか、それともカンマ区切りなのか？項目がオプショナルの場合はどうするか？項目が存在しない、空文字や 0 や undefined や nu

ローカルLLMでGitHub Copilotのような開発ができるようにしました。 Continue と Ollama を用いましたが、タブ補完がβ版ということもあってか設定で躓いたので、記事にしました。 TL;DR Ollamaを起動し、API経由のアクセスが有効か確かめます config.jsonの設定後、VSCodeを再起動します（2024-05-02時点では必要） Continueのタブ補完実行時、VSCodeのOutputタブとOllamaのserver.logでデバッグを行います。 技術選定 GitHub Copilotに代わるアシスタントとしては、Cursor, Continue, Tabby を比較しました。 今回は完全ローカルで動作するContinueを選択しました。 Cursorは2024‐05‐02時点ではCursorのサーバーを経由してLLMにアクセスしているため、n

はじめに テキスト生成モデルをAPIサーバでホストする需要が増えてきている昨今ですが1サーバでできるだけ多くのリクエストをさばくためにはどうすればよいでしょうか？もちろん高速なツールを使うことも重要ですが、それだけでは限界があります。前回の記事ではいくつかのツールを比較しましたが、どのツールでもバッチサイズを上げることで単位時間あたりの処理能力を高めることができるということがわかりました。つまりAPIサーバ側でバッチサイズを大きくする工夫をすることでより多くのリクエストをさばくことが可能になります。 今回の記事ではText Generation InferenceやvLLMなどが採用して注目を集めているContinuous batchingと呼ばれる手法について紹介します。 名称や仕組みなどについてはこれらの解説を参考にしています。 予備知識 Continuous batchingの説明に

Studio Ousiaと理化学研究所に所属している山田育矢です。 この記事では、大規模言語モデル（LLM）の性能を向上させる新しい方法であるLEIA（Lightweight Entity-based Inter-language Adaptation）を紹介します。 LLMは言語によって性能に顕著な差があり、訓練に使われるテキストが最も多い英語において特に性能が高い傾向があることが知られています。LEIAは、LLMが蓄えている英語の知識を他の言語から使えるようにする訓練を施すことで、英語以外の言語でのLLMの性能を向上させる新しい手法です。 この度、英語・日本語の2言語LLMであるSwallowの7Bと13Bのモデルに対してLEIAによる訓練を施して性能向上を行ったモデルを公開します。 ライセンスは、Swallowと同様のLlama 2 Community Licenseです。これらのモ

もしあなたがLLMを使ったプロダクトを何かしら開発している、もしくは興味があるのなら、メモリを大量に積んだMac Studioの購入を検討すべきです。 対象読者NVIDIAが絶対にいいという人はこの記事の対象読者ではありません。また、用途によって、ローカルマシンによるローカルLLMが向いてる・向いてないは明確にあるので、向いてない用途にしか使わない人も対象読者ではありません。あしからず。 また、この記事は別にNVIDIAをdisる意図はありません。みんな違っていい。NVIDIAもいい選択肢ですが、Mac Studioも悪くないですよ、と言いたい。 結論LLMプロダクト開発において、今年はもはやローカルLLMを無視できない、してはいけない状況です。 LLMプロダクト開発をする会社の視点でいえば、是非とも80GB以上の十分なGPUメモリを積んだマシンを用意できるようなアジリティを持つのが望まし

イノベーションセンター テクノロジー部門 Generative AI PJ の内部勉強会で発表した資料です。Retrieval-Augmented Generation (RAG) において重要な役割を果たす埋め込みモデル（特に日本語に特化したもの）について整理しました。

最近オープンになる大規模言語モデル（LLM）が、軒並みGPT-4レベルの性能となっています Huggngfaceで無料でダウンロードできるのですが、問題は必要VRAM容量です 話題の、Command-r-Plusは、日本語性能について評価が高く、一部の性能はGPT-4並みと言われますが、さすがに大型で104Bパラメータもあるため、4bitに量子化しても60GB程度のVRAMが必要となります。 コンシューマークラスのGPUの最高峰、RTX4090は、VRAM24GBのため、command-r-plusをすべてGPUに載せて推論しようと考えると、3台のマルチGPUデスクトップが必要です しかし、RTX4090は450W消費のGPUのため冷却機構が大きく、1デスクトップに3台収めるのは至難の業となります。 先日、水冷ラジエーター付きRTX4090で、マルチGPUデスクトップを作成しました。 水冷

2024.04.16「先達エンジニアに学ぶ 思考の現在地 Online Conference」での登壇スライドです event link: https://findy.connpass.com/event/313119/ 生成AIを使ってプロダクト作りをしていたり、社内の生産性向上をチャレンジしてる方に少しでも参考になれば幸いです。

こんにちは、安くLLMを構築したいですね。おすすめ構成をお知らせします。 LLMは大規模言語モデルのことで、AIがChatGPTみたいに文章を作ってくれます。無料で使えますが、業務で使おうとすると結構難点があるし、データの漏洩とか含めて困りますね。手元のローカルでLLMを作る際のおすすめ構成をお知らせします。 まず、LLMを作るには、マザーボード、CPU、メモリ、SSD、電...

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜

Continueというコーディング支援AIツールの紹介です。 コーディング支援AIツール・サービスとしてはGitHub Copilotが有名で、次いでCursorやCodeiumあたりが話題性のあるところかと思います。Publickeyに2024年3月時点での情報がまとまっています。 Continueはそれらと比べて知名度は劣りますが以下のような特徴があり、うまく使いこなせば有力な選択肢になると考えています。 ツール本体がオープンソースである Visual Studio CodeとJetBrains IntelliJ IDEAの拡張機能がApache License, Version 2.0で提供されています 言語モデルは自分で選ぶ Continueではコード補完用とチャット用で二つの言語モデルを利用しますが、そこでどの言語モデルを選ぶかは利用者側に任されています Continueを開発し

米OpenAI（オープンAI）が米国で少なくとも6件の生成AIに関連する特許を取得していたことが分かった。同社は特許の取得に消極的とされ、米特許調査会社のIFI CLAIMS Patent Services（IFIクレームズ・パテント・サービス）の調査でも「5件未満」とされていた。日経クロステックとAI（人工知能）特許総合検索・分析プラットフォームを手掛けるパテントフィールドが米国特許商標庁で2024年3月末までに公開されている情報を調べ直したところ、6件の特許取得が判明した。詳細をお届けしよう。 6件のうち2件は公開済み。残り4件も特許公報が発行されており、2024年1月から3月までに6件全てで特許権が成立している。特許出願から公開までは原則として1年半を要するため、今後立て続けにオープンAIの特許が公開される可能性がある。 出願者は非営利組織「OpenAI Inc.」でも事業会社の合同

今のLLMを取り巻く状況について紹介します。