私たちはMeta社と共同で、最新の大規模言語モデル Meta Llama 3 を Databricks上でリリースできることを嬉しく思います。Databricks上のLlama 3により、あらゆる規模の企業が、完全に管理されたAPIを介してこの新しいモデルを導入することができます。Meta Llama 3は、オープン言語モデルの新しいスタンダードとなり、最先端のクローズドモデルに匹敵する機能を、コミュニティと独自のLLMを開発する企業の両方に提供します。Databricksでは、オープンな言語モデルを推進するというMetaのコミットメントに共感しており、この新しいモデルを初日から企業のお客様にご利用いただけることに興奮しています。 Meta Llama 3は、今後数日のうちにリージョンごとに展開される予定で、Databricksモデルサービング上の統一的なAPIを通じてアクセスすることができます。 つまり、組織固有のデータを安全に活用しながら、ユースケースに最適なモデルを使用して、高品質で本番規模の生成AIアプリ

イントロダクション このブログポストでは、Databricksが作成したオープンな最新大規模言語モデル（LLM）であるDBRXを使った推論を紹介します（ DBRXの紹介 を 参照 ）。DBRXがどのように効率的な推論と高度なモデル品質の両方を実現するために一から設計されたかを説明し、私たちのプラットフォームでどのように最先端のパフォーマンスを達成したかを要約し、最後にモデルとの対話方法に関する実践的なヒントを紹介します。 Mosaic AIモデルサービング は 、 ハイパフォーマンスでプロダクショングレードのエンタープライズ対応プラットフォーム上のDBRX Instructに即座にアクセスする ことができます。 ユーザーは即座に実験やプロトタイプアプリケーションを構築し、その後スムーズに本番グレードの推論プラットフォームへ移行することができます。 今すぐDBRXをお試しください！ Databricksワークスペース内の AI Playground （米国のみ） OpenAI SDKを使って Databricks上

昨年、Rayサポートの パブリックプレビュー をリリースして以来、何百ものDatabricksのお客様が、マルチモデル階層予測やLLMファインチューニング、強化学習など、様々なユースケースに使用してきました 。 本日、DatabricksにおけるRayサポートの一般提供を発表できることを嬉しく思います。 Rayは、バージョン15.0以降、機械学習ランタイムの一部として含まれるようになり、Databricksでファーストクラスとして提供されるようになりました。 お客様は、追加インストールなしで Rayクラスターを開始することができ、Databricksが提供する統合された製品群（Unity Catalog、Delta Lake、MLflow、Apache Sparkなど）の中で、この強力なフレームワークの使用を開始することができます。 調和のとれた統合：Databricks上のRayとSpark Ray on Databricksの一般提供により、Databricks上で分散ML AIワークロードを実行する選択肢が

前回のブログ では、 仮想ネットワークサービスエンドポイント または Private Link を使用して、Azure DatabricksからAzureデータサービスに安全にアクセスする方法について説明しました。 この記事では、これらのベストプラクティスのベースラインを前提として、データの流出を防止するために、ネットワークセキュリティの観点からAzure Databricksのデプロイを強化する方法について、詳細な手順をウォークスルーします。 Wikipedia によると データ漏洩は、マルウェアや悪意のある行為者がコンピュータから不正なデータ転送を行うことで発生します。一般に、データ漏洩またはデータエクスポートとも呼ばれます。データ漏洩は、データ窃盗の一形態とも考えられています。2000年以降、多くのデータ漏洩が発生し、世界中の企業の消費者信頼、企業評価、知的財産、政府の国家安全保障に深刻な損害を 与えました。 この問題は、企業が機密データ（PII、PHI、戦略的機密情報）をパブリッククラウドサービスで保管・

イントロダクション よくあるシナリオを考えてみましょう。あなたのチームは、オープンソースのLLMを活用して、カスタマーサポート用のチャットボットを構築したいと考えています。 このモデルは、本番環境で顧客からの問い合わせを処理するため、いくつかの入力や出力が不適切または安全でない可能性があることに気づかない可能性があります。 そして、内部監査の最中になって初めて（運良く このデータを追跡 していた場合）、ユーザーが不適切なリクエストを送信し、チャットボットがそのユーザーとやりとりしていることに気づくのです！ さらに深く掘り下げると、チャットボットが顧客を不快にさせている可能性があり、事態の深刻さはあなたが準備できる範囲を超えていることがわかります。 チームが本番環境でAIイニシアチブを保護するために、DatabricksはLLMをラップして適切な動作を強制するガードレールをサポートしています。 ガードレールに加えて、Databricksはモデルのリクエストとレスポンスをログに記録する推論テーブル（ AWS | Az

本日、Databricks Feature Serving（特徴量サービング）の一般提供を開始いたします。 特徴量はAIアプリケーションにおいて極めて重要な役割を果たし、通常、正確に計算し、低レイテンシーでアクセスできるようにするためにはかなりの労力を必要とします。 この複雑さによって、本番のアプリケーションの品質を向上させるための新機能の導入が難しくなります。 特徴量サービングを利用すれば、AIアプリケーションに対して、単一のREST APIを使用してリアルタイムで、事前に計算された特徴量やオンデマンドの特徴量を簡単に提供することができます！ 特徴量サービングは、高速で安全、かつ簡単に使用できるように設計されており、次のような利点があります： 高速かつ低TCO - 特徴量サービングは、低TCOで高いパフォーマンスを提供するように設計されており、ミリ秒単位の待ち時間で特徴量を提供できます。 フィーチャーチェーン - 事前に計算された特徴量とオンデマンド計算のチェーンを指定することで、複雑なリアルタイム特徴量の計算

背景 RAG（Retrieval-Augmented Generation）がAIを駆使したアプリケーションとの関わり方に革命をもたらす時代において、これらのシステムの効率性と有効性を確保することは、かつてないほど不可欠なことである。DatabricksとMLflowはこの革新の最前線にあり、GenAIアプリケーションの重要な評価のための合理化されたソリューションを提供している。 このブログポストでは、Databricks Data Intelligence Platformを活用いて、GenAIアプリケーションの3つのコアコンポーネント（プロンプト、検索システム、Foundation LLM）の品質を強化および評価し、GenAIアプリケーションの継続的な品質を確保するためのするためにシンプルで効果的なプロセスを紹介する。 ユースケース MLflowのドキュメントの質問に回答し、その結果を評価するQAチャットボットを作成する。 Databricksで外部モデルを設定する Databricksの モデルサービング

はじめに Databricks Lakehouse Monitoring (レイクハウス・モニタリング)を使用すると、データからフィーチャー、MLモデルまで、すべてのデータパイプラインを追加のツールや複雑な操作なしに監視できます。 Unity Catalog に組み込まれているため、ガバナンスと並行して品質を追跡し、データとAI資産のパフォーマンスについて深い洞察を得ることができます。Lakehouse Monitoringは完全にサーバーレスなので、インフラストラクチャやコンピュート構成のチューニングを心配する必要はありません。 Lakehouseのモニタリングに対する統一されたアプローチにより、 Databricks Data Intelligence Platform で直接、品質の追跡、エラーの診断、ソリューションの検索が簡単に行えます。Lakehouse Monitoringを最大限に活用する方法を本記事ではご紹介します。 なぜレイクハウス・モニタリングなのか？ データパイプラインは順調に動いているよう

Retrieval Augmented Generation（RAG ）は、Gen AIアプリケーションのコンテキストとして関連データを提供する効率的なメカニズムです。 ほとんどのRAGアプリケーションは、通常、ドキュメントやWiki、サポートチケットなどの非構造化データから関連するコンテキストを検索するためにベクトルインデックスを使用します。 昨日、私たちはDatabricks Vector Search Public Previewを発表しました。 しかし、これらのテキストベースのコンテキストを、関連性のあるパーソナライズされた構造化データで補強することで、Gen AIの応答品質をさらに向上させることができます。 小売業のウェブサイトで、顧客が"最近の注文はどこですか？" と問い合わせる、Gen AIツールを想像してみてください。 このAIは、クエリが特定の購買に関するものであることを理解し、LLMを使用して応答を生成する前に、注文品目の最新の出荷情報を収集しなければなりません。 このようなスケーラブルなアプ