今回はGoogle Apps Script(GAS)を使い、Androidスマートフォンのアラームと部屋の電気を連動させる方法をご紹介します。 コードをコピーして簡単にできるので、Nature製品をお持ちの方はぜひ試してみてください。 必要なもの googleアカウント 部屋のライトを登録したNature Remo Androidスマートフォン   Nature Remo APIへの登録 https://api.nature.global/login にアクセスし、Natureアカウントに登録しているメールアドレスでログインします。 Access tokens一覧より「Generate access token」を選択し、アクセストークンを作成します。 アクセストークンは一度しか表示されないため、忘れずにコピーしましょう。（クリップボードの履歴はWindowsの場合[Win] + [V]キーで確認できます） Google Apps ScriptでAPIを作成 Google Apps Script(GAS)ではGET、POSTメソッドのAPIを作成する機能が提供されています。 Googleドライブの任意の場所に新しいGASファイルを作成しましょう。特にディレクトリにこだわりがなければ、 ここ から作成できます。 ・ライトのシグナルIDを取得する 操作するデバイス（信号）のIDを特定します。以下のコードを入力してください。 function findSignalId() { apiAccessKey = 'コピーしたアクセスキー' baseURL = 'https://api.nature.global/1' headers = { 'Authorization' : 'Bearer ' + apiAccessKey, 'accept' : 'application/json', 'Content-Type' : 'application/x-www-form-urlencoded', } options = { 'method' : 'GET', 'headers' : headers, } response = JSON.parse(UrlFetchApp.fetch(baseURL + '/appliances', options).getContentText()) response.map((device) => { console.log('デバイス名 : ' + device['nickname']) device['signals'].map((signal) => { console.log(signal['name'] + " : " + signal['id']) }) }) } 関数を実行すると、実行ログに登録された機器名と各操作のシグナルIDが出力されるので、その中からライト点灯のIDを探してコピーします。 ・APIをデプロイする 先程とは別のスクリプトを作成します。左のメニューより「スクリプト」を選択してください。   以下のコードを入力します。今回はPOSTメソッドのAPIを作りたいのでdoPostメソッドを使います。 function doPost() { apiAccessKey = 'コピーしたアクセスキー' signalId = 'ライト点灯のシグナルID' baseURL = ' https://api.nature.global/1 ' headers = { 'Authorization' : 'Bearer ' + apiAccessKey, 'accept' : 'application/json', 'Content-Type' : 'application/x-www-form-urlencoded' } options = { 'method' : 'POST', 'headers' : headers, } response = JSON.parse(UrlFetchApp.fetch(baseURL + '/signals/' + signalId + '/send', options)) //今回は使用しませんが、APIの疎通を確認するアプリを使うとレスポンスとしてメッセージを取得できます。 message = 'ライトを点灯しました' return ContentService.createTextOutput(message).setMimeType(ContentService.MimeType.TEXT) }   APIをデプロイします。画面上部の「デプロイ」ボタンから「新しいデプロイ」をクリックします。 種類の選択から「ウェブアプリ」、アクセスできるユーザーの欄で必ず「全員」を選択してください。 デプロイを実行するとウェブアプリのURLが表示され、すでにAPIでライトを操作できる状態になっています。早速呼び出してみましょう。 Andriodスマートフォンに「Sleep」アプリをインストールしてセットアップ アラームが鳴るのと同時にAPIを呼び出せるアプリ「 Sleep 」を使います。 [設定] > [各種サービス] > [オートメーション] の順に選択、「Webhooks」を有効化し先ほど表示されたウェブアプリのURLを入力します。 このアプリからAPIの呼び出しが行われるタイミングは複数あるのですが、今回呼び出してほしいタイミングはアラームが鳴ったときだけなので、上にある「イベント」から「ALARM_ALERT_START」以外のチェックを外しておきます。 これで設定は完了です。アラームを鳴らして動作を確認しましょう。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Androidスマホのアラームが鳴ったら部屋の電気を自動でつけたい【Nature Remo】 first appeared on SIOS Tech. Lab .

こんにちは！ サイオステクノロジーの安藤 浩です。 エンタープライズ向けブロックチェーンのデファクトスタンダードといわれているHyperledger Fabricの入門の続きとして、Hyperledger Fabricでいうところの合意形成の仕組みであるトランザクションフローについて説明していきます。説明や用語などは以下の前回の記事をもとにしています。 Hyperledger Fabric 入門 – Hyperledger Fabricとは、Hyperledger Fabricのコンポーネントの説明 – はじめに Hyperledger Fabricには以下の3つのステップで構成されるトランザクションフローによって合意形成がなされます。 ステップ1: Endorsement トランザクションの内容について合意するステップです。(Chaincode実行結果にPeerが署名したもの) ステップ2: Ordering トランザクションの順序を確定しプロックを生成・配布するステップです。 ステップ3: Validation & Commit トランザクションの有効性を検証したうえで反映するステップです。 ステップ1～3のトランザクションフローが完了したときにクライアントアプリケーションにLedger(台帳)の更新が通知されます。   ここからはそれぞれのステップにおいてどのような処理がされているか詳しく見ていきます。 ステップ1: Endorsement 目的： 複数の組織で複数のPeerを所有する場合、Chaincodeを実行することで同一の結果が得られることを確認したい 理由： Peerに対して不正を働いた、不具合があった、ミスや障害などで不正な状態のLedgerのデータをもとにTransaction が処理されることを防ぎたい。 以下の図に記載の順でEndorsementのステップ(青色の部分)は実行されます。 1.Transaction Proposal 送付 まず、クライアントアプリケーション(図内のClient App)がPeer に対して、Chaincodeを実行するように要求を行います。これをTransaction Proposalといいます。この要求はLedger に対しての読み込みや書き込みが該当します。 2.Chaincode 実行 Peer 内のChaincodeを実行し、署名を付けます。この結果をEndorsementといいます。※ここでは実際にLedgerに対して反映することはないため、シミュレーション実行とも呼ばれます。 3.Endorsement 返却 2のEndorsementをクライアントアプリケーション(図内のClient App)に返却します。 4.Endorsement Policy に基づきEndorsementを収集 Client AppはPeerから返却されたEndorsementをあらかじめ決められたEndorsement Policyに基づいてEndorsementを収集します。Endorsement Policyとは、 あるTransaction をLedgerに反映するために、どのようなEndorsementを集めてこなければならないかをあらかじめ定義した条件のこと。 例：Organization1, Organization2, Organization3 で構成されるネットワークとしたとき。 ・ Organization1, Organization2のどちらからもEndorsementを収集しなければならない条件。 ・Organization1, Organization2, Organization3のいずれか2つのOrganizationからEndorsementを収集しなければならない条件。   ステップ2: Ordering   目的： Transactionの集合を適切な順序で配置し、それらをBlockにまとめることです。そのBlockをPeerに配布して最終的なValidation を実施して、Ledgerに書き込みます。 理由： Transaction の順序を決めないとデータの不整合が発生してしまうため。 以下の図に記載の順でOrderingのステップ(緑色の部分)は実行されます。   5.Transaction 送付 Endorsementを収集したクライアントアプリケーション(図内のClient App)がTransactionをOrdering Service に送付します。まず、図の点線部分でPeerのFabric Gateway(v2.4で導入された)を介して、TransactionをOrdering Service に送付されます。 ※ここでOrdering Serviceは複数ノードで構成されます。 Transaction には Peerから署名済のTransaction Proposalへのレスポンスが含まれます。 6.Block生成 1. Ordering Service で受け取ったTransaction の順序を合意し、決定します。( コンセンサスアルゴリズム: Raft を利用) 2. Ordering ServiceがTransactionを組み込んだBlockを生成します。 7.Block配布 Ordering Serviceは生成したBlockをPeer に配布します。 また、 Peerが停止していた、または後からChannelに参加した場合はOrdering Service に再接続した際にBlockを受信します。   ステップ3: Validation & Commit   目的： 最終的に Transaction の有効性を検証したうえでLedger に反映したい。 理由： ステップ1で実行した結果と一致するか、署名やTransaction が改変されていないかなどの不正が起こっていないかをチェックするため。 以下の図に記載の順でValidation & Commit のステップ(紫色の部分)は実行されます。 8.Validation → Commit 1.Peer はOrdering Service から配布されたBlock内のTransaction を検証(Validation)します。 2.Validationが完了したら、Ledgerに対して反映(Commit)します。 Validationの際にはやることは以下です。 ・各Transactionを検証 ・Transaction が必要な組織のPeerによってエンドース(署名がついている)されていること ・Endorsementが一致していること ・Read-Set に含まれるKeyに対するVersionが現在の World State のKeyのVersionから変更されていなければTransaction を有効する。変更されていればTransaction を無効とする。 最後の点が分かりにくいので、用語の説明とともに詳細を説明していきます。 用語の説明 World State ここでWorld Stateとは、World StateはKeyの現在のValueを格納されているデータストアです。 また、各Keyに対するVersionも持っており、レコードがどのBlockのどのTransaction によって書き込まれたかを表します。 以下の例のようなデータをもっています。 Read-Set Read-Setとは、ステップ1のEndorsementの際にChaincodeの実行によって取得されたKeyとVersionのリストです。 以下は仮想的な例ですが、 read-set のブロックで囲まれた箇所です。 <TxReadWriteSet> <NsReadWriteSet name="chaincode1"> <read-set> <read key=" WaterB ottle1 ", version="0"> <read key=" WaterB ottle2 ", version="0"> </read-set> <write-set> <write key=" WaterB ottle1 ", value="LION"> <write key=" WaterB ottle2 ", value="MAMMOTH"> <write key=" WaterB ottle3 ", isDelete="true"> </write-set> </NsReadWriteSet> <TxReadWriteSet> 「 Read-Set に含まれるKeyに対するVersionが現在の World State のKeyのVersionから変更されていなければTransaction を有効する。変更されていればTransaction を無効とする。 」について 用語の説明はできたと思うので、「 ・Read-Set に含まれるKeyに対するVersionが現在の World State のKeyのVersionから変更されていなければTransaction を有効する。変更されていればTransaction を無効とする。 」については、ステップ1のEndorsementでChaincodeを実行した際に生成されたRead-Setと現在のLedger内のWorld State の状態が一致するかということを検証しています。 Endorsement からValidationまでにほかのTransaction などによってWorld StateのKeyに対するValueが変更されている可能性があるため、最終的にValidationをしています。   9.BlockがLedgerにCommitされたことを通知 最後にBlockがPeer内のLedgerに反映されたことをもって、トランザクションフローが完了します。これをクライアントアプリケーション(図内のClient App)に通知して終わりです。 また、 Ordering Service に接続していないPeerの場合はほかのPeerからGossip プロトコルによりBlockが配布されます。Private DataについてもGossip プロトコルによってPrivate DataをもっているPeerから配布されます。 まとめ トランザクションフローは3つのステップで実行され、システム全体の合意形成がなされることを説明しました。 ステップ1: Endorsement (Transaction の内容について合意) ステップ2: Ordering (Transaction の順序を確定しプロックを生成・配布) ステップ3: Validation & Commit (Transaction の有効性を検証したうえで反映)   参考URL Transaction Flow — hyperledger-fabricdocs main ドキュメント Glossary (用語集) — hyperledger-fabricdocs main ドキュメント ピア — hyperledger-fabricdocs main ドキュメント The Ordering Service — hyperledger-fabricdocs main ドキュメント Blockchain GIG 集中講座 #1 Hyperledger Fabric（再）入門 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Hyperledger Fabric 入門 – トランザクションフローの説明 – first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの佐藤 陽です。 今回もRAGの構築に関する記事を書いていきます！ これまでも何本かRAGに関して書いてきましたが、 今回はそれらの集大成として、 PDFを外部情報とするRAGを実装し、Ragasで評価する ところまで、ソースコードと合わせて一挙ご紹介していこうと思います。 これを読めば、今日からRAGが構築ができるような記事になってます！ ぜひ最後までご覧ください！ はじめに 今回一番伝えたいことは、 「評価を回しながらRAGの開発を進めてください！！」 という事です。 RAGというと、どうしても回答を出す部分に注目が行きがちですが、評価の方も非常に大切です。 生成AIを利用していることもあり、RAGの回答内容は不安定であり、人間が評価するのが難しいことがよく言われています。 更にRAGを構築する要素の設計は多岐にわたります。 プロンプト変更 チャンキング戦略 検索方法 LLMのモデル and more! そのため、今回扱うようなRagasを利用し、定量的に評価をしながら開発を進めていくことが大切になります。 今回の記事を通じ、評価までを含んだシステムを構築し、よきRAG開発ライフを送っていただければ幸いです。 ポイント 今回のポイントとしては以下の通りです。 詳細に関してはそれぞれリンクしてある記事でも紹介してます。 DocumentIntelligenceを使ったPDFの読み込み   RAGパイプラインの実装 RagasによるRAGパイプラインの評価   それぞれの技術要素については、これまでにも解説してきましたが いざシステム化するとうまく動かなかったり、つなぎ方が分からない点もあるかと思うので 今回は、実際にこれらを組み合わせたアプリケーションを構築していきたいと思います。 そのため本記事では各要素について深い解説を行いません。 本記事で読んでいて分からない点があれば、各記事にて詳細を確認ください！ 題材 今回RAGに組み込むPDFファイルとしては、デジタル庁が提供する テキスト生成AI利活用におけるリスクへの対策ガイドブック を利用したいと思います。 環境 今回利用する技術としては以下のようなものです。 併せて利用したpythonライブラリのバージョンも記載しておきます。 ※ragasが現状最新の0.1.10を使った場合、エラー発生したのでバージョン注意です。 python(3.1.23) LangChain(0.2.9) Azure OpenAI Service Azure AI Document Intelligence(1.0.0b3) Azure AI Search(11.6.0b3) Ragas(0.1.9) システム構成図としては以下のような形となります。 ステップ 全体のステップとしては以下の流れです。 DocumentIntelligenceを利用し、PDFを読み込んでMarkdownとして出力する LangChainを利用して、Markdownのファイルをセマンティックチャンキングする セマンティックチャンキングした情報をベクトル化してAI Searchに格納する RAG Pipelineを構築する ユーザーからの質問に基づきAI Searchからコンテキスト情報を取得する ユーザーからの質問に対してテンプレートを適用する テンプレートを適用したプロンプトをAzure OpenAI Serviceに対して投げかけ、回答を得る Ragasを利用して評価する Ragasを利用して評価用のテストセットを構築する 4.1(context) と 4.3(answer) と 5.1(question, ground_truth) で得られたパラメータを用いてRAGパイプラインを評価する ではそれぞれのステップを、ソースコードと合わせてみていきたいと思います。 事前準備 今回のプロジェクト構成としては以下の通りです。 └── Project/     ├── rag.ipynb    //ソースコード     ├── .env    //環境変数用のファイル     ├── ai_guidebook.pdf    //RAGに組み込む情報     └── documents/         └── splits    //チャンク化した情報を格納するフォルダ             ├── split_0.txt             └── split_1.txt ライブラリ 必要なライブラリのインストールとインポートを行います。 ! pip install python-dotenv langchain langchain-community langchain-openai langchainhub openai tiktoken azure-ai-documentintelligence azure-identity azure-search-documents==11.6.0b3 ragas==0.1.9 unstructured ipywidgets from langchain_openai import AzureChatOpenAI from langchain_community.document_loaders import AzureAIDocumentIntelligenceLoader from langchain_openai import AzureOpenAIEmbeddings from langchain.schema import StrOutputParser from langchain.schema.runnable import RunnablePassthrough from langchain.text_splitter import MarkdownHeaderTextSplitter from langchain.vectorstores.azuresearch import AzureSearch 環境変数 次に、環境変数の読み込みを行います。 事前にAzure上に作成したリソースから、エンドポイント名やkeyを参照し.envファイルに記載しておいてください。 今回必要となるリソースとしては以下3つです。 Azure OpenAI Service Azure AI Search Azure AI Document Intelligence ※keyに関してはGitHubなどのバージョン管理ツールにはpushしないよう注意しましょう。 import os from dotenv import load_dotenv load_dotenv() os.environ["AZURE_OPENAI_ENDPOINT"] = os.getenv("AZURE_OPENAI_ENDPOINT") os.environ["AZURE_OPENAI_API_KEY"] = os.getenv("AZURE_OPENAI_API_KEY") doc_intelligence_endpoint = os.getenv("AZURE_DOCUMENT_INTELLIGENCE_ENDPOINT") doc_intelligence_key = os.getenv("AZURE_DOCUMENT_INTELLIGENCE_KEY") envファイルとしては以下のような内容になります。 AZURE_OPENAI_ENDPOINT = "https://{resource-name}.openai.azure.com/" AZURE_OPENAI_API_KEY = "{KEY}" AZURE_SEARCH_ENDPOINT = "https:/{resource-name}.search.windows.net" AZURE_SEARCH_ADMIN_KEY = "{KEY}" AZURE_DOCUMENT_INTELLIGENCE_ENDPOINT= "https://{resource-name}.cognitiveservices.azure.com/" AZURE_DOCUMENT_INTELLIGENCE_KEY = "{KEY}" PDFの読み込み まず、AI Document Intelligenceを利用し、PDFから文章をMarkdownの形式で抽出します。 Markdownで出力するためのパラメータはDefaultでONになっているため特に設定する必要はありません。 ただapi_modelとしては、Markdown出力が可能なモデルであるprebuild-layoutを選択しましょう。 今回、RAGに組み込むPDF(ai_guidebook.pdf)は本プログラムと同じ階層に置いてあります。 loader = AzureAIDocumentIntelligenceLoader(file_path="ai_guidebook.pdf", api_key = doc_intelligence_key, api_endpoint = doc_intelligence_endpoint, api_model="prebuilt-layout") docs = loader.load() セマンティックチャンキング 出力したMarkdownをLangchainの MarkdownHeaderTextSplitter 関数を利用してチャンキングします。 今回はHeaderレベルに合わせてチャンク化の方を行いました。 このチャンク化の粒度というものもRAGｎお品質に関わってくる部分になります。 チャンキングした情報を、ローカルに作成しておいたdocuments/splitsというフォルダの中に保存します。 # Split the document into chunks base on markdown headers. headers_to_split_on = [     ("#", "Header 1"),     ("##", "Header 2"),     ("###", "Header 3"), ] text_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) docs_string = docs[0].page_content splits = text_splitter.split_text(docs_string) for i, split in enumerate(splits):     with open(f"documents/splits/split_{i}.txt", "w") as f:         f.write(split.page_content) AI Searchへの格納 次に、分割した情報をベクトルストアであるAzure AI Searchに登録していきます。 ここでもLangchain経由で操作を行います。 まずはAI Searchにアクセスするためのインスタンスを作成します。 ベクトル化のため、Azure AI Searchのコンストラクタのパラメータとして、embeddingsモデルのLLMを指定します。 embeddingsモデルに関しては事前にAzure OpenAI Service上でデプロイしておいてください。 aoai_embeddings = AzureOpenAIEmbeddings(     azure_deployment="text-embedding-ada-002",     openai_api_version="2024-02-15-preview",  # e.g., "2023-12-01-preview" ) vector_store_address: str = os.getenv("AZURE_SEARCH_ENDPOINT") vector_store_password: str = os.getenv("AZURE_SEARCH_ADMIN_KEY") index_name: str = "sios_sample_index" vector_store: AzureSearch = AzureSearch(     azure_search_endpoint=vector_store_address,     azure_search_key=vector_store_password,     index_name=index_name,     embedding_function=aoai_embeddings.embed_query, ) 実行すると、AI Search上にインデックスが作成できていることが確認できます。 まだこのインデックスには何も情報が含まれていないため、先程チャンク化した情報を追加します。 add_documentsを誤って複数回実行すると、のちの関連情報の取得に影響出るため注意してください。 from langchain_community.document_loaders import DirectoryLoader loader = DirectoryLoader("documents/splits") documents = loader.load() vector_store.add_documents(documents) 少し時間が経過するとデータの追加が確認できます。 RAGパイプラインの構築 実際にRAGのパイプラインを構築していきます。 LangChainの LCEL を利用し、チェーンを組み立てます。 Chainの構築に関しては こちら のブログで紹介しています。 今回組み立てるChainは2本です。 Answerを得るためのChain Contextを得るためのChain Answer用のChain ユーザーからの質問に対する回答を得るためのChainです。 以下のようなChainを組みます ChatLLMに対して投げるプロンプトのためのテンプレートを構築 questionに対して、ベクトルストアから関連情報を収集 関連情報と質問事項をテンプレートに組み込み、プロンプトを投げる 回答を出力する Context用のChain ユーザーからの質問に対する関連情報を得るためのChainです。 こちらのChainに関しては1ステップのみです。 questionに対して、ベクトルストアから関連情報を収集 RAGを構築するためだけであればこのパイプラインは必須ではありません。 今回はRagasでの評価にて利用するため構築します。 from langchain_core.prompts import ChatPromptTemplate, HumanMessagePromptTemplate from langchain_core.messages import SystemMessage llm = AzureChatOpenAI(     openai_api_version="2024-02-01",  # e.g., "2023-12-01-preview"     azure_deployment="gpt-35-turbo-16k",     temperature=0, ) prompt = ChatPromptTemplate.from_messages(     [SystemMessage(          """質問に対して、関連情報を参照に回答してください。          関連する情報を参照しても分からない場合は、「分かりません」と回答してください。"""     ),      HumanMessagePromptTemplate.from_template(          """ 関連情報：{context}                      ## 質問：{question}          ## 回答： """     )      ]     ) retriever = vector_store.as_retriever(search_type="similarity") # Documetを連結する def format_docs(docs):     return "\n\n".join(doc.page_content for doc in docs) # answerを得るためのchain answer_chain = (     {"context": retriever | format_docs, "question": RunnablePassthrough()}     | prompt     | llm     | StrOutputParser() ) # contextを得るためのchain context_chain = retriever 回答取得 ここでRAGのパイプラインが構築できたので、RAGから回答の方を取得したいと思います。 実行する内容としては、answerのchainに質問を与えてあげればOKです。 answer_chain.invoke("本資料の対象の読者は誰ですか？") 得られた回答としては以下の通りです。 '本資料の対象の読者は、テキスト生成AIのサービス開発者やサービス提供者です。' これでRAGのパイプラインの構築は完了です。 では続いて評価のフェーズに映りたいと思います。 Ragasでの評価 テストセットの作成 Ragasでテストセット(評価に用いるQuestion,Ground_truth)を作成する場合は filename のmetadataを保持している必要があります。 そのため、今回の場合は source のmetadata(ファイル名)を filename の値として設定します。 Each Document object contains a metadata dictionary, which can be used to store additional information about the document accessible via Document.metadata. Ensure that the metadata dictionary includes a key called filename, as it will be utilized in the generation process. The filename attribute in metadata is used to identify chunks belonging to the same document. For instance, pages belonging to the same research publication can be identified using the filename. ref : Generate a Synthetic Test Set from langchain_community.document_loaders import DirectoryLoader loader = DirectoryLoader("documents/splits") documents = loader.load() for document in documents:     document.metadata['filename'] = document.metadata['source'] 次に、Ragasの機能でテストセットを作成します。 テストセットの作成にはLLMを利用するため、Azure OpenAI Service上にChatモデルとEmbeddingsモデルをデプロイしておきます。 デプロイしたモデルのapi versionや、モデル名を各種パラメータに設定します。 また今回は日本語でテストセットを作成するため、adaptの language の設定を japanese とします。 その他、test_sizeやdistributionsの値は適宜調整してください。 from ragas.testset.generator import TestsetGenerator from ragas.testset.evolutions import simple, reasoning, multi_context from langchain_openai import AzureChatOpenAI, AzureOpenAIEmbeddings # generator with openai models generator_llm = AzureChatOpenAI(     openai_api_version="2024-02-01",     azure_deployment="gpt-35-turbo-16k", ) critic_llm = AzureChatOpenAI(     openai_api_version="2024-02-01",     azure_deployment="gpt-35-turbo", ) embeddings = AzureOpenAIEmbeddings(     openai_api_version="2024-02-01",     azure_deployment="text-embedding-ada-002" ) generator = TestsetGenerator.from_langchain(     generator_llm,     critic_llm,     embeddings ) generator.adapt(     language="japanese",     evolutions=[simple, reasoning, multi_context] ) # generate testset testset = generator.generate_with_langchain_docs(documents, test_size=2, distributions={simple: 0.5, reasoning: 0.25, multi_context: 0.25}) テストセットの表示 どのようなテストセットが作成されたか見てみます。 testset.to_pandas() もちろんこれらのテストセットは自分で用意してもらってもOKです。 ただ、Ragasで生成できるようにしておくと、膨大なテスト量をこなせたり、自動化したりしやすいのでよいですね。 評価項目のインポート Ragasで評価する項目をimportし、あとで設定可能なようにListとして定義しておきます。 Ragasには多くの評価項目がありますが、全てを評価しようとするとLLMのトークン数を多く利用します。 その場合、リソースが枯渇したり、思わぬ金額が請求されたりするため注意してください。 今回は以下の4つのみを評価対象とします。 context_precision faithfulness context_recall, context_relevancy from ragas.metrics import (     context_precision,     faithfulness,     context_recall,     context_relevancy ) # list of metrics we're going to use metrics = [     context_precision,     faithfulness,     context_recall,     context_relevancy ] 評価パラメータの整備 評価に使うための question ground_truth context answer を用意していきます。 questionとground_truthに関しては、先程Ragasの機能で生成したtestsetの値を利用します。 この時、回答が生成されないケース( nan )があるため、”回答無し”という表記に変換します。 次に、先程構築した2つのchainを利用して、contextとanswerの内容を取得します。 df = testset.to_pandas() df = df.fillna("回答なし") #nanは"回答なし"に変換する def get_answer_contexts(question: str):     answer = answer_chain.invoke(question)     # langchainのDocumentからRagas評価時に使うテキストデータだけ取り出す。     contexts = context_chain.invoke(question)     contexts = [c.page_content for c in contexts]     return {"answer": answer, "contexts": contexts} results = [get_answer_contexts(s) for s in df["question"]] 評価パラメータのセット 作成した各種パラメータをdatasetsの中に代入します。 from datasets import Dataset result_ds = Dataset.from_dict(     {         "question" : df["question"],         "answer" : [r["answer"] for r in results],         "contexts": [r["contexts"] for r in results],         "ground_truth": df["ground_truth"]     } ) result_ds.to_pandas() 評価に利用するLLMパラメータの設定 評価に利用するLLMのパラメータを設定します。 先程まで利用していたモデルと同一のものでも、別に用意してただいてもOKです。 from langchain_openai.chat_models import AzureChatOpenAI from langchain_openai.embeddings import AzureOpenAIEmbeddings from ragas import evaluate chat_llm = AzureChatOpenAI(     openai_api_version="2024-02-01",     azure_deployment="gpt-35-turbo" ) embeddings = AzureOpenAIEmbeddings(     openai_api_version="2024-02-01",     azure_deployment="text-embedding-ada-002" ) 評価の実施 evaluate関数で実際に評価を行います。 result = evaluate(     result_ds, metrics=metrics, llm=chat_llm, embeddings=embeddings ) 結果の表示 RAGパイプライン全体の結果の表示 result 以下のような結果となりました。 {'context_precision': 0.9028, 'faithfulness': 0.5000, 'context_recall': 0.5000, 'context_relevancy': 0.1732} 次に、各質問に対する結果の表示 をします。 result.to_pandas() まとめ 今回は、RAGのパイプライン構築から、Ragasでの評価まで一気に解説しました。 最初にも書きましたが、構築とともに評価を行っていることが今回の大きなポイントです。 「開発して、評価して、開発して、評価して…」と、いいループが回せるとよいかと思います。 是非今回の内容をベースに、RAGの構築の方に取り組んでみてください！ ではまた！ 参考文献 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【AOAI】RAGパイプラインの構築から評価フェーズまでの実装を一挙解説！【Ragas】 first appeared on SIOS Tech. Lab .

今号では、前号に引き続き nmcli コマンドの使い方やオプションについてご紹介します！ 今回は、接続 (ネットワーク) 編です。 nmcli connection コマンドについて 今回ご紹介する nmcli connection は、ネットワークのプロファイル情報を参照したり編集するためのコマンドです。 nmcli コマンドの中で、最も使用頻度が多いと言えるでしょう。 また、ネットワークの有効化/無効化も nmcli コマンドから行うことができます。 基本の書式 サブコマンドに “connection” もしくは “con” 、 “c” を指定すると、このシステムで 使用可能なプロファイルの情報を表示します。 なお、これはオプションに “show” を指定した時と同じ動作になります。 # nmcli con show NAME UUID TYPE DEVICE System eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ethernet eth0 lo 8515cb3c-66df-419b-b813-b5bb9c5e7e15 loopback lo nmcli connection コマンドのオプション よく使用されると考えられるオプションを抜粋してご紹介します。 オプションに “up” 、その後に対象となるプロファイルを指定すると、当該プロファイルの ネットワークをアクティブ (有効) にします。 # nmcli con up "System eth0" Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3) なお、上記はインタフェースの名前 (id) を指定していますが、他にも uuid を指定することも できます。 # nmcli con up uuid 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 オプションに “down” 、その後に対象となるプロファイルを指定すると、当該プロファイルの ネットワークを非アクティブ (無効) にします。 # nmcli con down "System eth0" ※ nmcli con up と同様に、id 以外にも uuid を指定することもできます。 オプションに “modify” 、その後に対象となるプロファイル、値を変更したいパラメータを 指定すると、指定したパラメータの値を変更できます。 例えば、eth0 の id (System eth0) を変更したい場合、下記の様に実行します。 # nmcli con modify "System eth0" connection.id "eth0" # nmcli con show NAME UUID TYPE DEVICE eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ethernet eth0 lo f6681442-22fa-4cc3-9ea5-a92f0c45ee7f loopback lo オプションに “clone” 、その後に対象となるプロファイル、新しく作成 (複製) する プロファイル名を指定すると、既存のプロファイルから新しいプロファイルを複製します。 例えば、既存のプロファイル eth0 から eth1 を作成 (複製) したい場合、下記の様に実行します。 # nmcli con clone eth0 eth1 eth0 (5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03) cloned as eth1 (3fc59d00-c73c-4c75-8a9b-72730224d2be). # nmcli con show NAME UUID TYPE DEVICE eth0 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03 ethernet eth0 lo ad8c3d7a-0d6b-43c8-b709-40d980150fa3 loopback lo eth1 3fc59d00-c73c-4c75-8a9b-72730224d2be ethernet -- ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！nmcli コマンドの使い方 ～接続編～ first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 アメリカの大学生が、Google Drive から Linuxを起動することに成功しました。 Booting Linux off of Google Drive https://ersei.net/en/blog/fuse-root Windows がブルースクリーンになり、強制的に再起動を繰り返すという事象が話題になりましたが、今回の問題が発生する以前にも Debian や Rocky Linux でも同様の問題が発生していたことが分かりました。 CrowdStrikeによるPC起動不能問題は過去にLinuxディストリビューションでも発生していた https://gigazine.net/news/20240722-crowdstrike-debian-rocky-linux/ 2024/7/10、Zed Industries が Rust で実装されたオープンソースのコードエディタ「Zed」の Linux 版を公開しました。 オープンソースのRust製コードエディタ「Zed」、Linux版を公開 https://atmarkit.itmedia.co.jp/ait/articles/2407/16/news036.html ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2024年7月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

はじめに こんにちは、サイオステクノロジーの藤井です。 Azureのリソースを検索したいってことありますよね。私はありました。 実は私、部署内にてクラウドコスト改善チームという、部署内で利用しているazure等のクラウドリソースの無駄遣いを減らす活動をしているのですが、その活動の一環として、無駄遣いなリソースをAzure Resource Graphで検索してslackにて通知する、というシステムを作成しました。この記事では、そこで得た知見について書いていきたいと思います。 基本的には、本日(2024/7/19(金))に行ったPS Liveで話した内容と同じです。 Azure Resource Graphとは Azure Resource Graphは、KQLを使って、サブスクリプション内の様々なリソースやリソースの変更履歴などを検索できるサービスです。 KQLとは KQLとは、Kusto Query Languageの略で、今回紹介しているResource Graphの他、 Log AnalyticsやData Explorer等のサービスでも使われるSQLライクなクエリ言語です。 KQLの詳しい使い方については、以下の公式ページに載っています。 https://learn.microsoft.com/ja-jp/azure/data-explorer/kusto/query/tutorials/learn-common-operators 例として「東日本リージョンにある仮想マシンを検索する」場合のクエリーで説明します。 東日本リージョンは他の、例えばアメリカ東海岸リージョン1などと比較して高いですから、東日本リージョンのリソースを検索出来れば、コスト削減につながると思います。 1行目のresourcesでどこから検索するか指定します。この場合はこのサブスクリプションのAzureリソース全てです。 その次のproject句で、表示する項目を絞り込みます。この例では、name・type・location・resourceGroupの4項目のみ表示する用にしています。 最後にwhere句で、表示するリソースを絞り込みます。この例では、typeが仮想マシン、resourveGroupが今回の検証用のリソースグループ、locationが東日本リージョンとなるように絞り込んでいます。 Azure Resource Graphの使い方 話を戻しまして、Azure Resource Graphの実際の使い方について説明します。 ここではKQLの例と同じく、東日本リージョンにあるVMを検索しようと思います。 まず検証用として東日本リージョンとそれ以外のリージョン(今回はEast US)にVMを作成しておきます。 「Resource Graphエクスプローラー」を選択します。 画面上側に、先ほどKQLの説明の時に例に出したクエリを入力して、「クエリの実行」ボタンを押すと、画面下側に検索結果が表示されます。この例では、先ほど作成した2つのVMの内、東日本リージョンのVMのみ検索する事が出来ました。 自動化する方法 さて、Azure Resource Graphはリソースを簡単に検索できますが、無駄遣いなリソース探しでは、一回検索したらOKでは無く、継続的に検索する必要があります。しかし、毎回手動でクエリーを実行するのは面倒なので、検索を自動化する必要があります。 この記事では二種類の検索自動化方法を紹介します。 1個目はlog analyticsを使う方法で、2個目はAzure Logic Appsを使う方法です。 Log Analyticsを使う方法 まず、Log Analyticsを使って、リソース検索を自動化する方法を解説します。 Log Analyticsは、Azureサービスなどのログを収集し分析するサービスです。 Log Analyticsを使った検索自動化の概要としては、以下の図のように、まず、Log Analyticsを使って対象リソース(先ほどの例では、「東日本リージョンのVM」)の個数を監視します。この対象リソースが1個以上あるとメールで通知する、というアラートルールを作成することで、自動的に検索し続けることが出来ます。 詳しくは以下の公式ページに載っています。 https://learn.microsoft.com/ja-jp/azure/governance/resource-graph/alerts-query-quickstart?tabs=azure-resource-graph log analyticsを使うメリットは、高頻度で検索し続けられる事です。 デメリットとしては、メール以外・SMSなどいくつかの通知方法以外(例えばslackなど)で通知しようとすると、実装が複雑になってしまうことです。 通知はメールでも良いので、検索対象のリソースが出来たらすぐ知りたいという場合は、log analyticsを使う方法が適していると思います。 Azure Logic Appsを使う方法 次に、Azure Logic Appsを使って、リソース検索を自動化する方法を解説します。 Azure Logic Appsとは、ノーコードまたはローコードワークフローを作成しサーバーレスで実行できるサービスです。 Azure Logic Appsを使った検索自動化の概要としては、以下の図のように3つのトリガー・コネクターを持ったLogic Appsを作成します。 まず上段の定期実行トリガーによってこのLogic Appsが定期的に実行されます。 次に、中段のHTTPコネクターで、Resource GraphのREST APIに検索条件のKQLを含むリクエストを投げることで、検索を実行して、結果を取得します。 最後に、下段のslackコネクターで、取得した検索結果をもとにslackに通知を送ります。 詳しくは以下の公式ページに載っています。 https://learn.microsoft.com/ja-jp/azure/governance/resource-graph/tutorials/logic-app-calling-arg Azure Logic Appsを使うメリットは、カスタマイズ性が高いところです。コネクターが豊富なのでいろんな機能と組み合わせたり、条件によって検索内容・通知内容を変えたりできます。 この例で使っているslackなどのメール以外の手段で通知したい・通知内容をカスタマイズしたい場合などは、Azure Logic Appsを使う方法が適しています。 まとめ この記事では、Azure Resource Graphで簡単に検索する方法と、Azure Logic AppsまたはLog Analyticsを利用して検索を自動化する方法を説明しました。 ちなみに、冒頭で話題に出した、私が作成した、「無駄遣いなリソースを検索してslackにて通知するシステム」は、「検索は週に1回で良い」と「slackで通知する」という要件のためAzure Logic Appsを利用して実装しました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure Resource Graphで簡単にリソースを検索する方法 first appeared on SIOS Tech. Lab .

サイオステクノロジー武井です。僭越ながら、5回目のMicrosoft MVPを再受賞致しました。今年で通算5年目となります。これからも有益な情報を発信していきますので、何卒よろしくお願い致しますm(_ _)m 受賞カテゴリの変更 特筆すべき変更として、今年は私の受賞カテゴリが昨年の「Microsoft Azure」から「AI Platform」に変更されました。ちなみに、Microsoft MVPはカテゴリというのがありまして、得意分野ごとに表彰される仕組みとなっています。 プロフィール見るとたしかにAI Platformに変更になっています。 昨年は、AI関連の発信が多かったこともあり、カテゴリが変更になったのかと思います。今年もAI関連はどんどん発信していきますー。 Microsoft MVPとは？ そもそも Microsoft MVP (Most Valuable Professional) 制度というのがどんなものかを説明します。これは、Microsoft が、社外のエンジニアを「MVP」として表彰する制度になります。 マイクロソフト製品(AzureとかOffice365など)などに対する深い専門知識を待ち、そしてその知識をブログや登壇などを通じて世に広く広めてくれる人たちに送られる表彰制度です。 肝なのは、「深い専門知識を待ち」だけではなく「 その知識をブログや登壇などを通じて世に広く広めてくれる人 」であることですね。ここが大きな特徴で、技術コミュニティへの貢献度が大きく問われるということになります。 受賞しますと、Azureの月数万円分無料利用可能なサブスクリプションが頂けたりなど、今後のアウトプットをさらに充実するためのさまざまな支援があります。 これから ５回目の受賞ができたのも、ひとえに皆様のご支援・ご協力のおかげでございます。改めて御礼申し上げますm(_ _)m カテゴリがAIになりましたので、AI関連の情報を更に提供していきたいと思います。それだけではなく、引き続きAzureに関する全方位的な情報を「わかりみ深く」届けたいと思います。 ということで、以下のYoutubeチャンネルも引き続き宜しくお願いしますm(_ _)m ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Microsoft MVPを再受賞しました first appeared on SIOS Tech. Lab .

こんにちは！サイオステクノロジーの安藤 浩です。今回はエンタープライズ向けブロックチェーンのデファクトスタンダードといわれているHyperledger Fabricについてご紹介します。入門として、Hyperledger Fabricの説明とHyperledger Fabricの各コンポーネントについて説明したいと思います。 Hyperledger Fabric とは Hyperledger Fabric は、Linux Foundation の下で設立されたHyperledger プロジェクトのひとつであり、オープンソースのエンタープライズ向けの許可型(Permissioned) 分散台帳テクノロジー(DLT) プラットフォームです。 Hyperledger Fabric は金融、保険、ヘルスケア、人事、サプライチェーン、デジタル音楽配信などの幅広い業界のユースケースに利用可能です。 Hyperledger Fabricの特徴 Hyperledger Fabricの特徴としては以下が挙げられます。 1.許可型ネットワーク Member Shipservice Provider（MSP）を使用してネットワークに参加するユーザーを管理し、許可されたメンバーのみがアクセスできます。 2.機密性の高い 共有したいデータのみを、共有したいメンバーに公開することが可能です。 3.Chaincode(スマートコントラクト)やFabric SDKでカスタム言語の習得は不要 Ethereum ではSolidity を利用するのが一般的かと思いますが、Hyperledger FabricのChaincode(スマートコントラクト)ではGo、Node.js、Java でコードが書けるので、独自の言語の習得は不要です。Fabric SDK(クライアントアプリケーションで利用)はNode.js、Javaの公式で提供されています。 ネットワークモデルによるブロックチェーンの分類 ブロックチェーンは、ネットワークモデルにより大きく以下の3つに分類されます。Hyperledger Fabricではプライベートブロックチェーンとコンソーシアムブロックチェーンの構築が可能です。 1. パブリックブロックチェーン 誰でも参加でき、全ての取引が公開されます。例としてはBitcoin, Ethereumです。 2. プライベートブロックチェーン 特定の組織内で利用され、アクセスが制限されています。例としてはHyperledger FabricやGoQuorumです。 3. コンソーシアムブロックチェーン 複数の組織が共同で運営し、参加メンバーが制限されています。例としてはHyperledger FabricやGoQuorumです。 主要なコンポーネントの説明 以下にHyperledger Fabricの主要なコンポーネントの説明をします。概念をつかみたいと思いますので、各コンポーネントの詳細はここでは省略します。(Hyperledger Fabric v2 系での説明) Organization コンポーネント(Peer, Orderer など)、ユーザが必ずいずれかのOrganizationに所属する。 Membership Service Provider (MSP) ネットワーク上のすべてのコンポーネント(クライアントアプリケーション、Peer、Ordererなど)/ユーザーを管理および認証する。 クライアントアプリケーション Hyperledger Fabricを利用するアプリケーションのこと。Fabric SDKを利用してPeer上のChaincodeを実行する。 Peer(ピア) Chaincodeの処理やブロックの承認などを行うノードのこと。 Peerは以下の特徴がある。 ・Ledger(台帳)を保持する ・Chaincodeを実行する Ledger(台帳) Organization間のトランザクションの履歴と現在の状態のデータのこと。 LedgerはBlockchainとWorldStateで構成される。Blockchainはトランザクションの履歴のことで、WorldStateはトランザクションの履歴が現在の状態に至ったデータのこと。※WorldStateは現在の状態しか持たない。 これはBlockchainのどの時点を切り取ってもWorldStateが生成できることを意味している。 Chaincode(チェーンコード) Ledger(台帳)の更新、参照をするビジネスロジックのこと。異なるOrganizationの間のルール、規則をコードによって定義する。 一般的にブロックチェーンではSmart Contract(スマートコントラクト)というが、Hyperledger FabricではSmart ContractとChaincodeは同じ意味で使っている。クライアントアプリケーションは、台帳に記録されるトランザクションを生成するために、Fabric SDKを利用してChaincodeを呼び出す。 Orderer(オーダラー) トランザクションの順序付けを行い、ブロックを生成するノードのこと。 Ordererは以下の特徴がある。 ・Ordering Service(Orderer ノードの群のこと)を構成する ・トランザクションの順序を確定し、ブロックを生成する ・生成したブロックをPeerノードに配布する CA(Certification Authority) コンポーネントやユーザに対して、アイデンティティ(証明書)を発行するPKIの認証局のこと。通常、Fabric CAを使うが、ほかのCAを利用してもよい。 Channel(チャネル) Hyperledger Fabricのネットワーク内に構成される 特定のOrganizationの間で通信を行うためのサブネットワークのこと。 システム構成図   図の説明と注意 Organization: ORG1, ORG2, ORG3がHyperledger Fabricのネットワークに参加しています。 Channel: Channel1, Channel2 があり、Channel1にはORG1, ORG2が参加しており、Channel2にはORG1, ORG2, ORG3が参加しています。(Channel 内のChannel PolicyというものでMSPの設定がされるようです) Client Appはクライアントアプリケーションのことです。Fabric SDKを利用して、Peer上のChaincodeを実行します。 Identityは CAによって発行された証明書です。各ノードには証明書があります。 CAは各Organizationに1つは必要なようですが、MSPやCAは現状よくわかっておらず、正確に表現できていない可能性があります。CAと通信する際はFabric CA Clientを利用して通信します。 チャネル内のLedger   各PeerにはChaincodeをインストールと有効化する仕組みがあり、Chaincodeに紐づくLedgerが生成されるので上記のシステム構成図ではChannel ごとに各PeerにLedgerが上記の図のように設定できるようになります。Channel1ではORG3が参加していないため、ORG1,ORG2に関するトランザクションのデータはORG3には共有されません。 まとめ Hyperledger Fabricの特徴とコンポーネントの概略が把握できたかと思います。別の記事でHyperledger Fabricのトランザクションフローについて記載します。 ※誤り等ありましたらコメントいただけますと幸いです。 参考URL https://hyperledger-fabric.readthedocs.io/en/release-2.5/whatis.html https://hyperledger-fabric.readthedocs.io/en/release-2.5/key_concepts.html https://hyperledger-fabric.readthedocs.io/en/release-2.5/glossary.html https://hyperledger-fabric-ca.readthedocs.io/en/latest/operations_guide.html#topology https://go.oracle.com/LP=130709   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Hyperledger Fabric 入門 – Hyperledger Fabricとは、Hyperledger Fabricのコンポーネントの説明 – first appeared on SIOS Tech. Lab .

はじめに 7月2日に岐阜県の長良川国際会議場で開催された国際会議 ERDSE2024 に参加してきました。 大学時代の研究を卒業前に本会議に投稿していたのですが、晴れて採録となったため発表に行ってきました。 このブログには発表した研究の内容と発表した際の感想をまとめようと思います。 研究内容 ざっくり説明するとYes/Noチャートを用いて情報検索をするためのシステムを提案しました。 アキネーターというサービスがありますが、あれに近しいものです。 既存の検索手法は、入力するクエリや膨大な検索結果を吟味する必要があり、検索結果にこだわろうとすると膨大な時間を要してしまうことになります。 一方で、Yes/Noチャートを検索に用いることができると、ユーザは質問にYesかNoで答えるだけで自分にぴったりな情報を入手することができます。 実装上の課題としては、YesかNoで答えられる質問をどのように生成するかがネックになったのですが、ChatGPTに生成してもらうことにしました。 いくつかの入力情報をもとに、それらの特徴を捉えた質問を生成するのはLLMが得意とするところかなと考えてのことです。 ユーザ実験の結果としては、既存の検索手法(Web検索やChatGPT)と比較し、検索時間の短縮や操作の簡便さに大きく寄与することがわかりました。 他方で、システムから提示された情報に納得がいかないユーザが少し多かったことが確認されました。 ChatGPTが生成した質問と、ユーザに提示される情報がかみ合っていないことがしばしばあり、ChatGPTの出力を上手く制御する必要があると感じました。 発表した感想 国際会議ということで英語で発表を行ってきました。 発表の方は事前に練習を重ねていたこともあり、流暢に話すことができました。 一方で、質疑応答についてはかなり苦戦しました。特に訛りの強い英語で質問を受けた際は、内容が聞き取れず狼狽してしまいました。 一旦落ち着いて質問の内容を聞き返すと良かったと思いますが、焦ってしまい的確に応答することができませんでした。 経験をたくさん重ねることで、落ち着いて英語でもコミュニケーションをとれるようになっていければと思いました。 いずれ仕事でも英語を用いる機会があるかもしれませんが、その際に今回の学会発表の経験が生きれば良いかなと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ERDSE2024参加報告 first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの木村です。 今回は、Flutterの環境構築（Macでの手順）から Hello World を表示するまでを書きたいと思います。 コードエディタにはVisual Studio Codeを使います。Visual Studio Codeのインストール手順は含んでおりませんのでインストールしていない方は事前にインストールしておいてください。 Flutterとは Googleが開発したオープンソースのアプリケーション開発用フレームワーク。Dart言語を使用し、単一のコードベースでiOSやAndroid、Web、デスクトップアプリ など様々なプラットフォームのアプリを構築できます。 環境構築 Macでの環境構築の手順を記載します。 拡張機能のインストール VSCodeにて、Flutterの拡張機能をインストールします。 1. VSCodeを起動し、サイドバーの拡張機能のアイコンをクリックします。 2. 「Flutter」と入力すると、検索結果に表示されますので、「インストール」をクリックします。 Flutterをインストールすると、「Dart」の拡張機能も自動でインストールされます。 Flutter SDK のインストール VSCodeにて、Flutter SDK をインストールします。 1. VSCodeにて、メニューバーより「表示」-「コマンドパレット」をクリックしてコマンドパレットを開きます。 2. コマンドパレットにて「flutter」と入力すると、「Flutter:New Project」が表示されるので、選択します。 3. 以下の画像のような SDK のダウンロードを促すプロンプトが表示されますので、「Download SDK」をクリックします。 4. 任意のフォルダを指定し「Clone Flutter」をクリックします。 指定したフォルダ配下に、「flutter」というフォルダが作成されます。こちらのパスをメモしておきます。（メモしたパスは、以降の Path の設定の手順で使います。） Path の設定 FlutterのPathを通します。 1. お使いの Mac のシェルを確認します。ターミナルを起動し、以下のコマンドを実行します。 echo $SHELL 「/bin/zsh」と表示された場合、シェルは zsh です。 「/bin/bash」と表示された場合、シェルは bash です。 2. 以下のコマンドを入力して Path の設定を行います。（以下はシェルが「zsh」の場合のコマンドです。お使いの環境が「bash」の場合は .zshrc のところを .bash_profile としてください。） echo export PATH="$PATH: /bin" >> ~/.zshrc 3. 以下のコマンドを実行して設定を反映させます。（以下はシェルが「zsh」の場合のコマンドです。お使いの環境が「bash」の場合は .zshrc のところを .bash_profile としてください。） source ~/.zshrc 4. ターミナルにて、「flutter」と入力して以下のように表示されれば、Path の設定は完了です。 Android Studio のインストールと設定 1. Android Studio の公式サイト にアクセスします。 2. 「Android Studio Koala をダウンロード」をクリックします。 3. 利用規約の同意にチェックを入れ、お使いの Mac が使用しているチップに応じたもの（チップが「intel」の人は Intel を、「Apple M1」「Apple M2」の人は Apple をダウンロード）をダウンロードします。 お使いの Mac が使用しているチップは、画面の左上にあるメニューバーのAppleアイコンをクリックし、［このMacについて］より確認することができます。 4. ダウンロードしたファイルを開き、案内通りにインストールを進めます。 5. インストールが完了したら、Android Studio を開きます。 6. 画面左の[Plugins]をクリックし、検索欄に「flutter」と入力します。Flutterが検索結果に表示されるので「Install」をクリックします。 7. 「Restart IDE」をクリックします。 8. 「Restart」をクリックします。 9. Android Studio が再起動されます。「More Actions」より「SDK manager」をクリックします。 10. 「SDK Tools」タブを選択し、「Android SDK Command-line Tools」にチェックを入れ、「Apply」をクリックします。 11. 確認ダイアログが表示されますので「OK」をクリックします。 12. 「Finish」をクリックします。 13. ターミナルを起動し、以下のコマンドを実行します。 flutter doctor --android-licenses 何度か確認メッセージが表示されますので、全て「y」を入力します。 以下のメッセージが出れば完了です。 XCode のインストール 1. App Store を起動します。 2. App Store の検索欄に「xcode」と入力し検索します。検索結果に XCode が表示されますので「入手」をクリックしてインストールします。以降は案内通りにインストールを進めます。 Google Chrome のインストール Google Chrome の公式サイト より、ダウンロードしてインストールします。 flutter doctor で確認 環境構築が正しく行えているか確認します。 ターミナルを起動し、以下のコマンドを入力します。 flutter doctor 以下のように、全て緑のチェックマークが表示されれば、完了構築完了です。 「!」や、「×」が表示された場合は、環境に何らかの問題があります。表示されるメッセージの内容に従って対応しましょう。 サンプルアプリで動作確認 VSCodeにて、サンプリアプリを動かしてみましょう。 プロジェクトの作成 1. VSCodeにて、メニューバーより「表示」-「コマンドパレット」をクリックしてコマンドパレットを開きます。 2. コマンドパレットにて「flutter」と入力すると、「Flutter:New Project」が表示されるので、選択します。 3. 「Application」を選択します。 4. 作成するプロジェクトをどこに配置するか聞かれるので、任意のフォルダを選択して「Select a folder to create the project in」をクリックします。 5. 任意のプロジェクト名を入力します。ここでは「flutter_hello_world」とします。 6. プロジェクトの作成が完了すると、以下のように表示されます。 カウンターアプリの実行 作成したプロジェクトにはデフォルトでサンプルアプリとして「カウンターアプリ」の実装が含まれています（lib 配下の main.dart というファイルに記載されています）。まずはこちらをビルドし、動作させてみましょう。 1. 画面右下の「macOS(darwin)」をクリックします。 2. 今回は、iOSのシミュレータで立ち上げます。「Start iOS Simulator」を選択します。 3. シミュレータが立ち上がります。 4. サイドバーの「実行とデバッグ」のアイコンをクリックします。 5. 「実行とデバッグ」をクリックします。 6. シミュレータにて、カウンターアプリが立ち上がります。 右下の「+」をタップすると、画面中央に表示される数字がカウントアップされます。 7. アプリの実行を終了するには、赤い四角のボタンをクリックします。 Hello World 先ほどのカウンターアプリを変更して、Hello World を表示するようにしてみましょう。 「main.dart」の実装を以下のように修正します。 import 'package:flutter/material.dart'; void main() { runApp(const MyApp()); } class MyApp extends StatelessWidget { const MyApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( title: 'My App', theme: ThemeData( colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue), useMaterial3: true, ), home: const MyHomePage(), debugShowCheckedModeBanner: false, ); } } class MyHomePage extends StatelessWidget { const MyHomePage({super.key}); @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: const Text('Home'), backgroundColor: Theme.of(context).colorScheme.primaryContainer, ), body: const Center( child: Text( 'Hello, World!', style: TextStyle(fontSize: 24,), ), ), ); } } 以下、コードの簡単な説明です。 3〜5行目 Flutterアプリでは、lib配下にある「main.dart」ファイルの main 関数がエントリーポイントとなり、ここからアプリが開始されます。 runApp 関数には、アプリケーションのルートウィジェット（アプリ上で最初に展開して欲しいウィジェット）を指定します。ここでは MyApp を呼び出しています。 7〜22行目 MyAppでは MaterialApp というウィジェットで、アプリケーション全体の基本的な設定と構造を定義しています。画面の中身の部分は MyHomePage を呼び出しています。 debugShowCheckedModeBanner: false, と記載すると、画面右上に表示されるDEBUGバナーを非表示にします。 24〜42行目 MyHomePageでは、アプリバーの表示と、「Hello, World!」の文字を画面中央に表示するようにしています。 実行すると、以下のような画面が表示されます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【Dart】 Flutter × VSCode で、環境構築 から HelloWorld まで（Mac） first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの塙です。 今回は、OpenShift(以下、OCP)上で、VMを実行するための機能となるOpenShift Virtualization(以下、OCP Virt)について説明したいと思います。 前提情報 本記事では、現時点では、以下のバージョンを対象としています。 ■バージョン OpenShift v4.15 OpenShift Virtualization v4.15 *1 *1 OCP Virt のバージョンは、v4.8 から OCP と同じになり、OCPと同様に推移していきます。 https://access.redhat.com/support/policy/updates/openshift_operators 概要 OCP Virt は、OCP 上で VM を動作、管理するためのコンポーネントとなります。 OCP Virt は OCP v4.5 から GA となり、OCP WebUI の OperatorHub から OCP Virt の Operator をインストールすることで利用可能となります。 サブスクリプション は、OCP のサブスクリプションで利用できるようになります。 また、OCP Virt は CNCF の Incubating Project である KubeVirt を利用して開発されているようです。 https://www.cncf.io/projects/kubevirt/ 休暇 アーキテクチャの基礎部分 VM を動作させる仕組みとして KVM を使用します。 KVM が RHCOS のカーネルで実行され、QEMU、libvirt はコンテナの内部で実行される形式となります。 概要では、Kubernetes の他の Pod と同様に、以下の枠組みを使用します。 CNI CSI CRD 内部のコンポーネント VM を動作させるには、主に３つのコンポーネントがあります。 ( Building a unified hybrid cloud strategy with Red Hat OpenShift Virtualization  より 引用) virt-controller ：CRD で定義された VM リソースを監視し、VM リソースの Pod をノードに割り当てる virt-handler ：各 Worker ノードで実行される DaemonSet。API や virt-controller と連携して、Pod の作成などの操作を、virt-launcher に指示する役割がある virt-launcher ：libvirtd と連携し、VM の作成や削除を制御する VM のリソース VM のリソースは Kubernetes の CRD を用いて定義を行う形となります。 # VMリソースの例 apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: label: app: demo name: test-vm spec: dataVolumeTemplates: - metadata: name: example-dv spec: pvc: accessModes: - ReadWriteOnce resources: requests: storage: 1G source: http: url: "" running: false template: spec: domain: devices: disks: - name: containerdisk disk: bus: virtio interfaces: - masquerade: {} name: default resources: requests: memory: 1024M networks: - name: default pod: {} volumes: - name: containerdisk containerDisk: image: kubevirt/fedora-cloud-container-disk-demo VirtualMachine(VM)リソース：VMIを作成するためのテンプレートを構成するリソース VirtualMachineInstance(VMI) リソース：VM リソースの定義の、稼働中の実態を表すインスタンスのリソース VirtualMachineInstanceMigration リソース：VM をライブマイグレーションするときに構成するリソース DataVolume(DV) リソース：VM のディスクイメージなどのストレージ側の設定を定義するリソース サポート対象のノードと OS サポート対象のノード VM を動作させるノードは、ベアメタルになります。 OCP Virt の サポート対象 のクラスターノードは以下のとおりです。 ブレインメタルサーバー AWS ベアメタル インスタンス IBM Cloud ベアメタルサーバー (TechPreview機能) サポート対象のOS VM の OS としてサポート対象となっている OS が確認できます。 https://access.redhat.com/articles/973163#ocpvirt 参考までに、rhel OS のライセンスは OCP に含まれており、Windows は別途ライセンスが必要になります。 利用のポイント OCP Virt の利用を考える時のポイントを以下に記載していきます。 1. VM管理のメリット VM のディスク、ネットワークなどのリソース定義は、OCP の Pod と同様に、yaml ファイルのマニフェストで管理出来る形になっています。VM 自体を IaC で管理することで、ある程度 VMの管理自体もしやすく、自動化出来る部分もあるのではないでしょうか。 例えば、現在コンテナ環境も運用されており、コンテナ運用を見据えた取り組みをしたいという考えがある場合は、VM と コンテナの運用管理を統一することができ、効率化を図ることができます。 2. コンテナ環境とシームレスに接続 Kubernetes の仕組みとして CSI(Container Storage Interface)*1、CNI(Container Network Interface)*2 を他のPodと同じように使用できます。 これは、VM と Pod 間で通信を行いたいときに、ネットワークがクラ​​スター内で完結できることを意味します。 そして、他のPodの通信方法と同じように、通信の際のVMのIPを意識せずに良いという所もポイントとなります。ただ、IPを指定して通信を行いたいといった要件の場合は、少し難点があるかもしれません。 *1 CSI(Container Storage Interface)：異なるストレージ技術を利用してコンテナに永続的なストレージを提供する仕組み *2 CNI(Container Network Interface)： コンテナ間でのネットワーク接続を管理するためのプラグインを提供する仕組み 3. 他環境からのマイグレーションや、稼働中の変更時のダウンタイム OCP Virt は、MTV というツールを用いて、他の VM 環境から VM をマイグレーションすることが可能です。 これは非常に便利な機能ですが、注意点が一つあります。 現時点では、他環境からマイグレーションをするときに VM のダウンタイムが発生します。移行規模にもよりますが、ダウンタイムを考慮した移行を計画する必要があります。 また、OCP Virt で稼働中のリソースを変更する場合、マニフェストを変更、適用する形となります。マニフェスト適用後に Pod の再起動が発生するので、VM のリブートでダウンタイムが発生することを考慮する必要があります。 まとめ 今回は、OpenShift(以下、OCP)上で、VMを実行するための機能となるOpenShift Virtualization(以下、OCP Virt)について説明しました。 また、より詳細のOCP Virt の機能について紹介出来ればと思います。 本書の記載が読者のお役に立てば幸いです。 参考文献 https://docs.redhat.com/ja/documentation/openshift_container_platform/4.15/html-single/virtualization/index OpenShift Virtualization ( Kubevirt ) でVM管理もCloud Nativeに (1) OpenShift Virtualization、コンテナ基盤で仮想マシンを動かす ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OpenShift Virtualization – OpenShift でのVM管理についてご紹介 first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジーの塙です。 今回はEKS上でGPUを扱う生成AIソリューションのデプロイを試し、実際にGPUがどう使われてどう見えるのかを検証してみたいと思います。 概要 前回は、Kubernetes をベースとしたプラットフォームでGPUを扱っていくための手法について解説してみました。 KubernetesでGPUを扱うためにはどんな準備が必要となるのか、またどんな設定をすれば良いかをまとめています。 ■前回の記事はこちら KubernetesでGPUを使用する   前回までの記事は机上ベースでのまとめをしていたため、今回はEKSを用いて、実際にGPUの設定がどう見えるのかについてまとめてみました。 導入 EKS上での検証は以下の記事を参考にしています。 まずこの記事の内容を参考にして導入していきます。 https://aws.amazon.com/jp/blogs/containers/deploy-generative-ai-models-on-amazon-eks/   ■ 検証の概要 上記記事では、EKSに生成AIソリューションをデプロイします。 JARK Stack と呼ばれるモデルの構築と実行に利用出来るツールを用いており、アーキテクチャとしては、JupyterHub, Argo Workflows, Ray Serve, Kubernetes を指しています。（アーキテクチャの詳細は記事をご参考ください） 今回、それぞれのツールの詳細は割愛していますが、生成AIソリューションの構成時に使用するツール群の調査も追々行っていけたらと思います。 この時使用する生成AIは、 Stable Diffusion というText-to-Imageの画像生成AIの拡散モデルを使用しています。 また、 DreamBooth という特定の対象を事後学習させる学習方法を用いてトレーニングを行い、モデルを作成する一連の工程をEKSのPodで行っている形となります。   ■ 前提情報 検証に必要な前提は以下となります。（バージョンは検証時のバージョン） AWS CLI v2.11.13 kubectl Client Version: v1.24.1 Kustomize Version: v4.5.4 Server Version: v1.29.5-eks-1de2ab1 Terraform v1.8.4 helm v3.13.1 Hugging Face のトークン jq v1.6   検証準備 Aの記事の「Steps to deploy Stable Diffusion Model on Amazon EKS」から順次行っていきます。 1. data-on-eks のGitリポジトリをクローンします $ git clone https://github.com/awslabs/data-on-eks.git 2.ブループリントをデプロイします ai-ml/jark-stack/terraformのブループリントまで移動して、./install.sh スクリプトを実行して、terraformで生成AIソリューションを構築していきます。今回の構築用に不要なアドオンの削除、インスタンスタイプ、VPCネットワークなどを少し修正しデプロイを行います。デプロイは30分ほどかかるので完了するまで少し待ちます。 下記では、Hugging Faceのトークンを使用するためファイルのダミートークンを置き換える内容を加えています。 $ cd data-on-eks/ai-ml/jark-stack/terraform # 必要に応じて、不要なアドオンの削除、インスタンスタイプ、VPCネットワークなどを修正 ..(snip).. # 必要に応じて、Hugging face tokenの修正 # data-on-eks/ai-ml/jark-stack/terraform/variables.tf variable "huggingface_token" { description = "Hugging Face Secret Token" type = string default = "DUMMY_TOKEN_REPLACE_ME" ## hugging face token に置き換える sensitive = true $ ./install.sh 3. 記事と同じように、Stable Diffusion モデルの調整を行っていきます $ kubectl get svc proxy-public -n jupyterhub --output jsonpath='{.status.loadBalancer.ingress[0].hostname} k8s-jupyterh-proxypub-xxx.elb.us-west-2.amazonaws.com 出力されたDNS ホスト名をWebブラウザ経由で開き、jupyterhubを起動します。 jupyterhub-values.yamlに記載されているユーザー名とパスワードを使用してログインします。(これにより新規のPodが立ち上がります) # jupyter-xxx1 が立ち上がっていることを確認する $ kubectl get pods -n jupyterhub NAME READY STATUS RESTARTS AGE continuous-image-puller-d4tqs 1/1 Running 0 90m continuous-image-puller-m6ccv 1/1 Running 0 90m hub-64f87f44dd-xlhd2 1/1 Running 0 90m jupyter-admin1 1/1 Running 0 15m proxy-8685586d98-wklvw 1/1 Running 0 90m 起動すると、Jupyter Notebook のコンソールにリダイレクトされるので、記事に従い Notebookで提供されているPythonを実行していきます。（Pythonの実行に関しては、ここでは割愛） ここまでで今回の趣旨の準備段階が完了です。以降からデプロイ後の構成でGPUを確認していきます。 確認内容 それぞれいくつかの観点で設定の確認を行っていきます。   ■ nvidia-device-plugin の確認 nvidia-device-plugin の確認を行うと、いくつかのリソースが動作していることが分かります。 $ kubectl get all -n nvidia-device-plugin NAME READY STATUS RESTARTS AGE pod/nvidia-device-plugin-gpu-feature-discovery-pkfff 1/1 Running 0 75m pod/nvidia-device-plugin-node-feature-discovery-master-568b4977kb2j 1/1 Running 0 76m pod/nvidia-device-plugin-node-feature-discovery-worker-8gddp 1/1 Running 1 (76m ago) 76m pod/nvidia-device-plugin-node-feature-discovery-worker-xf9mp 1/1 Running 1 (76m ago) 76m pod/nvidia-device-plugin-qwm44 1/1 Running 0 75m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/nvidia-device-plugin-node-feature-discovery-master ClusterIP 10.100.136.70 <none> 8080/TCP 76m NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/nvidia-device-plugin 1 1 1 1 1 <none> 76m daemonset.apps/nvidia-device-plugin-gpu-feature-discovery 1 1 1 1 1 <none> 76m daemonset.apps/nvidia-device-plugin-node-feature-discovery-worker 2 2 2 2 2 <none> NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/nvidia-device-plugin-node-feature-discovery-master 1/1 1 1 76m NAME DESIRED CURRENT READY AGE replicaset.apps/nvidia-device-plugin-node-feature-discovery-master-568b497868 1 1 1 76m 今回用いた data-on-eks では、daemonsetであるnvidia-device-pluginと、付随の機能として備わっているgpu feature discovery(以下、gfd), node feature discovery(以下、nfd)が動作する形となっています。 gfdとnfdはそれぞれ以下の機能を持つものとなっています。 gfd nfdの一部であり、特にGPU関連の機能を検出するために用いるツールとなる nfd  Kubernetesの各ノードのハードウェア機能やカーネル機能などの属性を自動的に検出し、それらの情報をラベルとしてKubernetes APIに公開するツールとなる つまり、gfdとnfdがノードの機能を検出しラベルを付けることで、nvidia-device-pluginがそれらの情報を用いてGPUリソースを管理し適切なPodに割り当てることをしています。   またnvicia-device-pluginのログを確認してみると、GRPCを開始し、Kubeletに nvidia.com/gpu のデバイスプラグインを登録していることが分かります。 $ kubectl logs daemonset.apps/nvidia-device-plugin -n nvidia-device-plugin I0629 07:28:42.381694 1 server.go:165] Starting GRPC server for 'nvidia.com/gpu' I0629 07:28:42.382522 1 server.go:117] Starting to serve 'nvidia.com/gpu' on /var/lib/kubelet/device-plugins/nvidia-gpu.sock I0629 07:28:42.386109 1 server.go:125] Registered device plugin for 'nvidia.com/gpu' with Kubelet ※今回は対象外としていますが、NVIDIA GPU Operator には、gfdとNVIDIA デバイス プラグインの両方が含まれます。   ■ Podから使用しているGPUの見え方の確認 準備段階で立ち上げた、jupyter-xxx1の内容を見てみます。確かにPodからGPUのLimits, Requests でGPUを要求していることが確認出来ます。 $ kubectl describe pod jupyter-admin1 -n jupyterhub Containers: notebook: ..(snip).. Limits: nvidia.com/gpu: 1 Requests: memory: 5368709120 nvidia.com/gpu: 1   ■ EKSのノードからのGPUの見え方の確認 1. kubernetes のコマンドからGPUの見え方の確認 kubectl からノードの状態を確認してみます。 Capacity, Allocatable から nvidia.com/gpu: 1 が確認できます。実際にPodからGPUを消費すると、Allocated resourcesの nvidia.com/gpu の値も更新されるようになります。 $ kubectl get node NAME STATUS ROLES AGE VERSION ip-100-64-105-40.us-west-2.compute.internal Ready <none> 56m v1.29.3-eks-ae9a62a ip-100-64-150-241.us-west-2.compute.internal Ready <none> 56m v1.29.3-eks-ae9a62a # GPU搭載のノードをdescribeで出力 $ kubectl describe node ip-100-64-105-40.us-west-2.compute.internal ..(snip).. Capacity: cpu: 4 ephemeral-storage: 104845292Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 16069056Ki nvidia.com/gpu: 1 pods: 29 Allocatable: cpu: 3920m ephemeral-storage: 95551679124 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 15378880Ki nvidia.com/gpu: 1 pods: 29 Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 180m (4%) 0 (0%) memory 5494538240 (34%) 768Mi (5%) ephemeral-storage 0 (0%) 0 (0%) hugepages-1Gi 0 (0%) 0 (0%) hugepages-2Mi 0 (0%) 0 (0%) nvidia.com/gpu 1 1 ..(snip)..   2. ノード上からnvidia-smi, deviceQueryコマンドでGPUの見え方の確認 AWS のセッションマネージャーから該当のノードにログインして確認してみます。 nvidia-smiコマンドでGPUの状態を出力すると以下のような情報が確認出来ます。この時、検証準備で行ったPythonアプリケーションを動作させているため、PythonのプロセスがGPUを使用していることが分かります。 また、deviceQueryコマンドを用いてGPUの情報が確認出来ます。 sh-4.2$ nvidia-smi Sat Jun 29 08:57:36 2024 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.183.01 Driver Version: 535.183.01 CUDA Version: 12.2 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 Tesla T4 On | 00000000:00:1E.0 Off | 0 | | N/A 33C P0 32W / 70W | 14819MiB / 15360MiB | 21% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | 0 N/A N/A 90855 C /opt/conda/bin/python3.10 14816MiB | +---------------------------------------------------------------------------------------+ sh-4.2$ /usr/local/cuda-12.2/extras/demo_suite/deviceQuery /usr/local/cuda-12.2/extras/demo_suite/deviceQuery Starting... ..(snip).. Device 0: "Tesla T4" CUDA Driver Version / Runtime Version 12.2 / 12.2 CUDA Capability Major/Minor version number: 7.5 Total amount of global memory: 15102 MBytes (15835660288 bytes) (40) Multiprocessors, ( 64) CUDA Cores/MP: 2560 CUDA Cores GPU Max Clock rate: 1590 MHz (1.59 GHz) Memory Clock rate: 5001 Mhz Memory Bus Width: 256-bit L2 Cache Size: 4194304 bytes Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384) Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 1024 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 3 copy engine(s) Run time limit on kernels: No Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Enabled Device supports Unified Addressing (UVA): Yes Device supports Compute Preemption: Yes Supports Cooperative Kernel Launch: Yes Supports MultiDevice Co-op Kernel Launch: Yes Device PCI Domain ID / Bus ID / location ID: 0 / 0 / 30 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 12.2, CUDA Runtime Version = 12.2, NumDevs = 1, Device0 = Tesla T4 Result = PASS   ■ ノードグループからGPUの状態を確認 AWS コンソールからGPUをどう使用しているか確認してみます。 結論から言うと、AWSコンソールからはラベルで情報の確認が出来る程度でした。CUDAに関する情報、GPUに関する情報が見える程度です。 GPUへの共有アクセス方法を試す デプロイ後の構成で、GPUへの共有アクセス方法も出来るか追加で試してみました。 GPUへの共有アクセス方法の設定は、以下の記事の内容を参考にして行っていきます。 https://aws.amazon.com/jp/blogs/containers/gpu-sharing-on-amazon-eks-with-nvidia-time-slicing-and-accelerated-ec2-instances/   ■ Time Slicing の設定 今回は、前回の記事で紹介した方法の中からTime Slicingを試してみたいと思います。 今回の nvidia-device-plugin はhelmでデプロイされているため、helm をアップグレードする方法で試します。 まずリポジトリを追加します。 $ helm repo add nvdp https://nvidia.github.io/k8s-device-plugin $ helm repo update Time Slicingを有効にする前のノードで利用できるGPUの数を確認します。 "nvidia.com/gpu": "1" とまだ利用出来る数は１つです。 $ kubectl get nodes -o json | jq -r '.items[] | select(.status.capacity."nvidia.com/gpu" != null) | {name: .metadata.name, capacity: .status.capacity}' { "name": "ip-xxx.us-west-2.compute.internal", "capacity": { "cpu": "4", "ephemeral-storage": "104845292Ki", "hugepages-1Gi": "0", "hugepages-2Mi": "0", "memory": "16069060Ki", "nvidia.com/gpu": "1", "pods": "29" } } nvidia-device-plugin の helmに渡すvalues.yamlとConfigMap の設定を行い、helm upgrade を行います。 $ cat nvidia-device-plugin-helm-values.yaml gfd: enabled: true nfd: worker: tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule - operator: "Exists" $ cat ndp_helm_upgrade.sh helm upgrade -i nvidia-device-plugin nvdp/nvidia-device-plugin \ --version=0.14.5 \ --namespace nvidia-device-plugin \ --values nvidia-device-plugin-helm-values.yaml \ --set config.name=time-slicing-config $ ./ndp_helm_upgrade.sh Time Slicing を行う設定をConfigMapとして投入します。今回はレプリカ数を４にして設定しています。 $ cat time-slicing-config.yaml apiVersion: v1 kind: ConfigMap metadata: name: time-slicing-config namespace: nvidia-device-plugin data: any: |- version: v1 flags: migStrategy: none sharing: timeSlicing: renameByDefault: false failRequestsGreaterThanOne: false resources: - name: nvidia.com/gpu replicas: 4 $ kubectl apply -f time-slicing-config.yaml ノードで利用できるGPUの数を確認します。 "nvidia.com/gpu": "4" と利用出来る数が増加したことを確認できます。 $ kubectl get nodes -o json | jq -r '.items[] | select(.status.capacity."nvidia.com/gpu" != null) | {name: .metadata.name, capacity: .status.capacity}' { "name": "ip-xxx.us-west-2.compute.internal", "capacity": { "cpu": "4", "ephemeral-storage": "104845292Ki", "hugepages-1Gi": "0", "hugepages-2Mi": "0", "memory": "16069060Ki", "nvidia.com/gpu": "4", "pods": "29" } }   ■ Time Slicing の確認 それでは、サンプルのアプリケーションを実行して、増加させたGPUのレプリカ数をどう使用するのか確認してみます。 サンプルのアプリケーションは、参考にした記事にある eks-gpu-sharing-demo を使用しています。今回はアプリケーションのレプリカ数は２に設定して適用しています。 $ kubectl create ns gpu-demonamespace/gpu-demo created $ kubectl apply -f example-train.yaml $ kubectl get pods -n gpu-demo NAME READY STATUS RESTARTS AGE tensorflow-cifar10-deployment-5df5f55756-k8vgp 1/1 Running 2 (3m50s ago) 6m57s tensorflow-cifar10-deployment-5df5f55756-l4wfm 1/1 Running 2 (3m50s ago) 6m57s sh-4.2$ nvidia-smi Fri Jun 28 07:53:07 2024 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.183.01 Driver Version: 535.183.01 CUDA Version: 12.2 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 Tesla T4 On | 00000000:00:1E.0 Off | 0 | | N/A 39C P0 43W / 70W | 14903MiB / 15360MiB | 16% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | 0 N/A N/A 77803 C python 14074MiB | | 0 N/A N/A 78014 C python 826MiB | +---------------------------------------------------------------------------------------+ nvidia-smiコマンドで確認すると確かに、pythonのプロセスが２つ動作していることが確認出来ています。 Time Slicingを使用して、GPUへの共有アクセスを提供することを簡単に確認しました。   まとめ 今回は、EKS上でGPUを扱う生成AIソリューションのデプロイを試し、実際にGPUがどう使われてどう見えるのかをまとめてみました。 実際に検証してみることで、机上ベースより詳細な情報を確認することが出来ました。 また発展として、MLOpsなどを効率的に回していくための様々なツール群を調査してみるのも面白いと考えています。 本書の記載が読者のお役に立てれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post EKSで生成AIソリューションのデプロイを検証し設定を確認する first appeared on SIOS Tech. Lab .

はじめに こんにちは！5、6月と案件の対応や問い合わせが重なり他のタスクに支障が出てきているなーがです。社会人4年目ということで複数の案件にアサインされていますが、前職ではあまり意識していなかった工数の意識や技術力不足を日々痛感しています。。。 それはさておき、6/14（金）に開催されたOSS推進フォーラム 【第8回】定例テック＆ビジネス勉強会～テーマ：SBOM に参加してきました。 参加から少し時間が経ってしまいましたが、イベントレポートをお送りします。今回のテーマは SBOM基礎編 ということで、2つの講演がありました。 登壇者と概要 サイオステクノロジー株式会社　佐々木 寛太さん タイトル： 開発者目線でのSBOMとの向き合い方 株式会社日立ソリューションズ　ITプラットフォーム事業部　渡邊 歩さん タイトル： SBOM(ソフトウェア構成表)活用の現状と課題 1. 開発者目線でのSBOMとの向き合い方 １つ目の講演は弊社佐々木寛太が弊社におけるSBOMに関する取り組みやSBOMツールを組み合わせたCI/CDのデモを行いました。 弊社のSBOMに関する取り組みは こちら の記事を見てみてください！ デモではSBOM作成ツールとして syft 、管理ツールとして Dependency-Track を使用しました。各ツールの説明や機能、導入方法については、下記の弊社ブログ記事を確認してください！ アーキテクチャは以下の通りです。 あるアプリケーションに機能を追加するために使用するライブラリを追加する状況を想定しており、開発者が変更を加えたブランチをリポジトリにPushすると、GitHub Actionsにより以下のような流れで実行されます。 アプリケーションのDocker Imageを作成 Docker Imageをコンテナレジストリに登録 登録したDocker Imageをpull SyftでDocekr Imageを解析 解析結果をArtifactsに永続化 解析結果をDependency-Trackにアップロード 他人事ながら本番で動くかどうかドキドキしていましたが、無事実行されました。参加されていた方々にもSBOM導入の参考になったと思います。 2. SBOM(ソフトウェア構成表)活用の現状と課題 2つ目の講演は日立ソリューションズの渡邊 歩さんが登壇され、 経産省の手引き の内容についての解説をはじめ、世界の動向と日本の取り組みについての紹介をされていました。経産省の手引きの作成を手伝われた方だったので、手引き作成の背景や裏話も話されていました。 講演を通じての感想としてはアメリカやEUはSBOM標準化に向けた取り組みが進んでおり、日本はかなり遅れていると感じました。 しかし、医療機器に関しては他の産業と比較して特に進んでおり、薬機法改正によりSBOMの提出が義務化の流れに向かっているようです。 特に驚いたのは、EUでは EUサイバーレジデンス法 によりEU市場に投入される全てのデジタル製品に関してSBOMを作成することを義務づける予定であり、違反してた場合は1500万ユーロ（日本円で約20億）または全世界売上の2.5%の罰則があることでした。2025年後半の適用を目指しているようで、あと2年もありません。 また、ドイツ、韓国、中国では独自のSBOMフォーマットを作る動きがあるようでした。国防の観点から独自のフォーマットを作っているのではないかということでした。 まとめ 今回は6/14（金）に開催されたOSS推進フォーラム 【第8回】定例テック＆ビジネス勉強会～テーマ：SBOMについて書きました。 個人的には講演の後にSBOMツール選定についての議論や各社の取り組みについて知る良い機会になったと思います。 次回 は8/2(金)でAI LT大会が開催されるそうなので、興味のある方は是非参加されてみてください！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSS推進フォーラムSBOM勉強会参加レポート first appeared on SIOS Tech. Lab .

はじめに こんにちはPS/SLの佐々木です。 今回はgithubの草が生えてきたので蛇に食べてもらおうと思います。 設定 まず自分のアカウント名と同じ名前のリポジトリを作成してください。 スクリーンショット 2024-06-28 1.46.41.png 私は atomic-kanta-sasaki なのでこの名前のパブリックリポジトリを作ります。 以下Termialで実行してください。 $ mkdir img $ touch img/.keep$ mkdir -p .github/workflows $ vi GenerateSnake.yml 以下GenerateSnake.ymlに貼り付けてください name: GenerateSnake on: workflow_dispatch: schedule: - cron: "0 1 * * *"jobs: update-repository: name: Update this repo's README with repository_owner runs-on: ubuntu-latest permissions: contents: write steps: - name: Checkout uses: actions/checkout@v2 - name: Generate Snake uses: Platane/snk/svg-only@v3 id: snake-gif with: github_user_name: ${{ github.repository_owner }} outputs: | ./img/snake.svg ./img/snake-dark.svg?palette=github-dark - name: Push to GitHub uses: EndBug/add-and-commit@main with: # ブランチ名はデフォルトブランチ名にする(main or master) branch: main message: ':rocket: Update' $ vi README.md 最後にREADME.mdに <picture> <source media="(prefers-color-scheme: dark)" srcset="<https://raw.githubusercontent.com/obregonia1/obregonia1/master/img/snake-dark.svg>"> <source media="(prefers-color-scheme: light)" srcset="<https://raw.githubusercontent.com/obregonia1/obregonia1/master/img/snake.svg>"> <img alt="github contribution grid snake animation" src="<https://raw.githubusercontent.com/obregonia1/obregonia1/master/img/snake.svg>"></picture> これを貼り付ければおけ。 作成したリポジトリにpushすれば document.createElement('video'); https://tech-lab.sios.jp/wp-content/uploads/2024/06/atomic-kanta-sasaki-kanta.sasaki-Google-Chrome-2024-06-28-06-13-25.mp4 こんな感じで食べてくれます。 かわいいですね ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 2人がこの投稿は役に立ったと言っています。 The post Githubの草を蛇に食べさせる技術 first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの佐藤 陽です。 今回は、RAGの評価ツールである Ragas の紹介をしたいと思います。 RAGに限らずですが、生成AIを使ったアプリは評価が難しいとよく言われます。 RAGに関しては、RagasというOSSが評価用のフレームワークが存在しており、 OpenAI社の発表 でも紹介されていました。 そこで今回は、「Ragasをとりあえず使ってみる！」というコンセプトで記事を書いていきたいと思います。 RAGを作ってみたはいいものの、システムの精度が分からない Ragas使ってみたいけど使い方がいまいち分からない といった方は、ぜひ最後までご覧ください！ はじめに Ragasも既に色々なところで紹介されているのですが、 複雑なユースケースに組み込まれていたりしているケースも多くありました。 そこで Ragas単体の挙動や使い方を知りたい！ とりあえずミニマムな感じで使ってみたい！ という方向けに、 最小限の形でRagasを使い、使い方や評価項目について解説したいと思います。 なんなら今回の記事では、RAGの構築さえ行いません！！ RAGが構築されていると仮定して、Ragasへの入力は仮で自前で用意していきます。 そのため今回の評価結果はまったく当てになりません 。 あくまで今回はRagasの概要と手法を学ぶだけです。 そんなチートな内容になっていますが、最後までご覧いただければ幸いです。 なお、今回はAzure OpenAI ServiceとRagasの組み合わせで評価を行っていきたいと思います。 Ragasとは 概要 簡単にRagasの紹介をします。 RagasはOSSとして公開されている、RAGのパイプラインを評価するためのフレームワークになります。 恐らくですが「ラグァス」と読みます。 RAGを構築するにあたっては 使用するLLMモデル チャンクのサイズ VectorStoreの検索方法 プロンプトの内容 など 決めるべきパラーメータが様々があり、その内容によってRAGの性能が決まってきます。 ただレスポンスが自然言語で返ってくることもあり、RAGを評価することはなかなか難しいとされています。 そこを定量的に評価してくれるのがRagasです。 おそらくRAGを評価する方法としてはかなりメジャーなフレームワークであり、 OpenAIの発表 のなかでも紹介されています。  評価方法 まずは何を評価対象(インプット)とするか、について解説したいと思います。 Ragasで評価を行う際に利用する evaluate関数 を見てみると、引数として dataset というオブジェクトを持ちます。 更にdatasetの中身を見ると、 question , contexts , answer , ground_truth の4つの値が含まれています。 この4つがRAGを評価するために利用されるパラメータになります。 それぞれについて解説します。 パラメータ 型 内容 question list[str] ユーザーがRAGに与えた質問 contexts list] RAGが回答を作成するにあたり、参照した情報 (VectorStoreなどの外部DBから、質問に関連した情報として取得された値(チャンク)) answer list[str] questionに対して、実際にRAGから返された回答内容 ground_truth list] questionに対する真の答え (これは評価前にユーザーが自前、もしくはRagasの機能等を利用して用意しておきます。) 評価項目 次に評価項目(アウトプット)を見ていきたいと思います。 表にまとめてみましたが、 正直なところ厳密に正しいかは自信がないです…。 公式ドキュメント の例や、計算方法を読むのが一番わかりやすいかと思います。 個人的にひとつポイントだと思った点としては、 正しい回答を行っていても答えが冗長だとスコアが低くなる点です。 正確かつ簡潔に答えるようにRAGを組み立てていく必要がありそうです。 評価項目 評価内容 評価対象 Faithfulness LLMによって生成されたanswerの内容をステートメントで区切り、それがcontextsの内容から推論できるかが評価されます。 contextsとanswer Answer relevancy LLMを利用して、answerから想定される質問を生成します(リバースエンジニアリング) そしてリバースエンジニアリングした質問と、questionの値のコサイン類似度が評価結果となります。 questionとanswer Context recall ground_truthの回答をステートメントで区切り、区切ったステートメントがcontextsの内容とどれくらい関連しているかが評価されます。 ground_truthの内容を網羅しているようなcontextであれば高いスコアが割り当てられます。 contextsとground_truth Context precision contextsの中にground_truthのワードが含まれ、なおかつそれが上位のチャンクとしてランキングされているかどうかを示します。 ground_truthのワードが上位のチャンクのcontexts中に含まれていると、高いスコアが割り当てられます。 ground_truthとcontexts Context relevancy ユーザーからのquestionに対して、どれだけ関連されたcontextsが取得されたかを表します。 questionと関連の高いcontextsが存在していればスコアが高くなります。 また、必要な情報が含まれていたとしても、冗長な内容が含まれている場合スコアは下がります。 questionとcontexts Context entity recall ground_truthとcontextsに含まれるエンティティ(ワード)にどの程度相関があるかを表します。 ground_truthに含まれるエンティティがcontextsにも多く含まれているほど高いスコアが得られます。 ground_truthとcontexts Answer semantic similarity ground_truthとanswerがどれだけ類似しているかを評価します。 それぞれの値をベクトル化し、これらのコサイン類似度を計算します。 ground_truthとanswer Answer correctness 得られた回答の正確さを評価します。 正確さは、回答が事実であるかという[factual similarity]という側面と、[answer semantic similarity(上記)]という側面の2つの面から評価が行われます。 factual similarityに関しては、ground_truthとanswerの内容の重複度に基づき計算します。 ground_truthとanswer また注意事項として 評価を行う際にChatの応答や、EmbeddingsなどAzure OpenAIの活用を多くしています。 Ragas自体はOSSなため利用にお金はかかりませんが、中の処理でLLMを利用しているため、むやみやたらに評価を行うとコストがかさむ可能性があります。 実装 評価対象および評価項目が分かったところで実際にRagasを使っていきます。 先程も述べた通り、今回はRAGのパイプラインは構築しません。 RAGを組んだつもりになって、自前で上記の評価対象のパラメータを作っていきます。 事前準備 今回は評価を行うにあたり、Azure OpenAI Service上にデプロイしたモデルを利用します。 AOAI上にChatモデルとEmbeddingsモデルをデプロイしておいてください。 サンプルドキュメント RAGを構築しないといっても何にも題材がないと分かりづらいため、RAGに与える文章をChatGPTに考えてもらいました。 架空のミュージシャンの内容なので、一般的なLLMは知る由もありません。 この内容に回答できるよう、RAGを構築していく。 といったケースを想定します。 名前: 白石 玲奈 (Shiraishi Rena) 年齢: 28歳 生年月日: 1996年3月15日 デビューした歳: 20歳 リリースしたアルバムと詳細: 1. 『青い夢』 (Blue Dream) - リリース日: 2016年5月20日 - 詳細: デビューアルバムであり、瑞々しい感性と透明感あふれるボーカルで話題を呼んだ。アルバムには、青春の儚さや未来への希望を描いた曲が多く収録されており、特に「君と見た空」がシングルカットされ大ヒットを記録。楽曲は全て自身が作詞作曲を手掛け、プロデューサーには有名音楽プロデューサーの田中亮を迎えた。 2. 『流星の詩』 (Meteor Poem) - リリース日: 2018年9月12日 - 詳細: セカンドアルバムで、より成熟した音楽性と深みのある歌詞が特徴。人生の様々な局面や感情を詩的に表現した楽曲が揃っており、「夜空に咲く花」がシングルとしてリリースされ、大人のリスナーからも支持を得た。アルバム全体を通じて、一貫したテーマとして「変化」と「成長」が描かれている。 3. 『永遠の一瞬』 (Eternal Moment) - リリース日: 2021年11月25日 - 詳細: 三枚目のアルバムでは、さらに多様な音楽ジャンルに挑戦。エレクトロニカやアンビエントなどの要素を取り入れ、新たなサウンドを追求している。特に「時の砂」が注目を集め、音楽チャートで長期間ランクイン。アルバムのテーマは「時間」と「記憶」であり、聴く者に深い感動を与える作品となっている。 生い立ち: 白石玲奈は、東京の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。 出演したフェス一覧: 1. フジロックフェスティバル (2017, 2019, 2022) - 日本最大級の野外音楽フェスティバルに複数回出演。特に2019年にはメインステージでのパフォーマンスが大絶賛された。 2. サマーソニック (2018, 2021) - 国内外のアーティストが集う都市型音楽フェス。玲奈のパフォーマンスはエネルギッシュで、観客を魅了した。 3. ロック・イン・ジャパン・フェス (2018, 2020, 2023) - 日本最大のロックフェスティバルで、彼女のライブは毎回大きな話題となり、観客を熱狂させた。 4. コーチェラ・フェスティバル (2019) - アメリカ・カリフォルニアで開催される世界的な音楽フェスティバルに出演。日本人アーティストとして初めての参加で、海外でも注目を集めた。 5. グラストンベリー・フェスティバル (2022) - イギリスの伝統ある音楽フェスティバルに出演し、そのパフォーマンスが高く評価された。 白石玲奈は、その卓越した音楽センスとパフォーマンスで、国内外での評価を高め続けている。彼女の今後の活躍にも大いに期待される。 評価対象の準備 先程も述べた通り、Ragasへの入力は以下4つのパラメータです。 question contexts answer ground_truth それぞれの値を以下のように3パターン用意します。 ※くどいほど繰り返しますが、今回はすべてのパラメータをRAGやベクトルストアを使わず、仮想的に自前で用意しています。 case 1 「関連ドキュメントの参照が正しく行われ、回答内容も正しいケース」 contextsの取得が正しく行われており、それに基づくChat LLMの回答内容も正しいケースです。 question contexts answer ground_truth “白石 玲奈は何歳の時にデビューしましたか？” [ “名前: 白石 玲奈 (Shiraishi Rena) 年齢: 28歳 生年月日: 1996年3月15日 デビューした歳: 20歳 リリースしたアルバム 1 アルバム名: 『青い夢』 (Blue Dream) リリース日: 2016年5月20日 詳細: デビューアルバムであり、瑞々しい感性と透明感あふれるボーカルで話題を呼んだ。アルバムには、青春の儚さや未来への希望を描いた曲が多く収録されており、特に「君と見” , “の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2” ] “白石 玲奈がデビューしたのは20歳の時です。” “20歳” case 2 「関連ドキュメントの参照が正しく行われているが、回答内容が正しくないケース」 contextsの取得が正しく行われているが、それに基づくChat LLMの回答内容が誤っているケースです。 question contexts answer ground_truth “2枚目にリリースしたアルバムのタイトルは何ですか？” [ “リリースしたアルバム 2アルバム名: 『流星の詩』 (Meteor Poem)リリース日: 2018年9月12日 詳細: セカンドアルバムで、より成熟した音楽性と深みのある歌詞が特徴。人生の様々な局面や感情を詩的に表現した楽曲が揃っており、「夜空に咲く花」がシングルとしてリリースされ、大人のリスナーからも支持を得た。アルバム全体を通じて、一貫したテーマとして「変化」と「成長」が描かれている。” , “の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2” ] “2枚目にリリースされたアルバムのタイトルは「永遠の一瞬」です。” “『流星の詩』 (Meteor Poem)” case 3 「関連ドキュメントの参照が誤っており、回答内容が正しくないケース」 contextsの取得がうまくいっておらずが、それに伴いChat LLMの回答内容が誤っているケースです。 question contexts answer ground_truth “2019年に出演したフェスは何ですか？” [ “名前: 白石 玲奈 (Shiraishi Rena) 年齢: 28歳 生年月日: 1996年3月15日 デビューした歳: 20歳 リリースしたアルバム 1 アルバム名: 『青い夢』 (Blue Dream) リリース日: 2016年5月20日 詳細: デビューアルバムであり、瑞々しい感性と透明感あふれるボーカルで話題を呼んだ。アルバムには、青春の儚さや未来への希望を描いた曲が多く収録されており、特に「君と見” , “の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2” ] “ロック・イン・ジャパン・フェスとコーチェラ・フェスティバルに出演しました。” “フジロックフェスティバルとコーチェラ・フェスティバル” 実装の流れ 以上の情報に基づき、Ragasの実装に必要最小限な実装を行っていきます。 必要なパッケージのインストール ! pip install python-dotenv ragas langchain_openai datasets 環境変数の設定 import os from dotenv import load_dotenv load_dotenv() os.environ["AZURE_OPENAI_ENDPOINT"] = os.getenv("AZURE_OPENAI_ENDPOINT") os.environ["AZURE_OPENAI_API_KEY"] = os.getenv("AZURE_OPENAI_API_KEY") 読み込むenvファイルとしては以下のものを用意しておきます。 .env AZURE_OPENAI_ENDPOINT = "https://{resource-name}.openai.azure.com/" AZURE_OPENAI_API_KEY = "api-key" 次に評価指標となるパラメータをimportし、評価時の項目として設定します。 from ragas.metrics import (     context_precision,     answer_relevancy,     faithfulness,     context_recall,     context_relevancy,     context_entity_recall,     answer_similarity,     answer_correctness ) # list of metrics we're going to use metrics = [     context_precision,     answer_relevancy,     faithfulness,     context_recall,     context_relevancy,     context_entity_recall,     answer_similarity,     answer_correctness ] 次にRagas内で利用するためのchat_llmやembeddingsを構築していきます。 今回はAzure OpenAI Serviceを利用し、LangChainを経由して使っていきます。 from langchain_openai.chat_models import AzureChatOpenAI from langchain_openai.embeddings import AzureOpenAIEmbeddings chat_llm = AzureChatOpenAI(     openai_api_version="2024-02-01",  # e.g., "2023-12-01-preview"     azure_deployment="gpt-35-turbo-16k",     temperature=0, ) embeddings = AzureOpenAIEmbeddings(     openai_api_version="2024-02-01",  # e.g., "2023-12-01-preview"     azure_deployment="text-embedding-ada-002", ) 次にデータの準備をします。 contextsに関しては配列の形にして入れてあげることに注意です。 # 質問事項 questions = [     "白石 玲奈は何歳の時にデビューしましたか？", # case 1     "2枚目にリリースしたアルバムのタイトルは何ですか？", # case 2     "2019年に出演したフェスは何ですか？" # case3 ] # 根拠となった情報(VectorStoreから取得した情報) contexts = [     # case 1(正しい関連内容を取得)     [         "名前: 白石 玲奈 (Shiraishi Rena) 年齢: 28歳 生年月日: 1996年3月15日 デビューした歳: 20歳 リリースしたアルバム 1 アルバム名: 『青い夢』 (Blue Dream) リリース日: 2016年5月20日 詳細: デビューアルバムであり、瑞々しい感性と透明感あふれるボーカルで話題を呼んだ。アルバムには、青春の儚さや未来への希望を描いた曲が多く収録されており、特に「君と見",         "の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2"         ],     # case 2(正しい関連内容を取得)     [         "リリースしたアルバム 2アルバム名: 『流星の詩』 (Meteor Poem)リリース日: 2018年9月12日 詳細: セカンドアルバムで、より成熟した音楽性と深みのある歌詞が特徴。人生の様々な局面や感情を詩的に表現した楽曲が揃っており、「夜空に咲く花」がシングルとしてリリースされ、大人のリスナーからも支持を得た。アルバム全体を通じて、一貫したテーマとして「変化」と「成長」が描かれている。",         "の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2",         ],     # case 3(誤った関連内容を取得)     [         "名前: 白石 玲奈 (Shiraishi Rena) 年齢: 28歳 生年月日: 1996年3月15日 デビューした歳: 20歳 リリースしたアルバム 1 アルバム名: 『青い夢』 (Blue Dream) リリース日: 2016年5月20日 詳細: デビューアルバムであり、瑞々しい感性と透明感あふれるボーカルで話題を呼んだ。アルバムには、青春の儚さや未来への希望を描いた曲が多く収録されており、特に「君と見",         "の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2"         ]     ] # RAGから得られた回答 answers = [     "白石 玲奈がデビューしたのは20歳の時です。", # case 1(正解)     "2枚目にリリースされたアルバムのタイトルは「永遠の一瞬」です。", # case 2(不正解)     "ロック・イン・ジャパン・フェスとコーチェラ・フェスティバルに出演しました。 ", # case 3(不正解) ] # 正しい答え ground_truths = [     "20歳",     " 『流星の詩』 (Meteor Poem)",     "フジロックフェスティバルとコーチェラ・フェスティバル ", ] 用意したDictionaryをdatasetの形に変換します。 from datasets import Dataset ds = Dataset.from_dict(     {         "question": questions,         "answer": answers,         "contexts": contexts,         "ground_truth": ground_truths     } ) 最後にRagasを使って評価の方を行います。 from ragas import evaluate # 引数としてデータセット・評価項目・ChatLLM・Embeddingsを与える result = evaluate(     ds, metrics=metrics, llm=chat_llm, embeddings=embeddings ) result.to_pandas() 結果と考察 結果が以下のように表示されました。 case faithfulness answer_relevancy context_recall context_precision 1 1.0 0.990947 1.0 1.0 2 1.0 0.946483 1.0 1.0 3 0.0 0.919827 1.0 0.0 case context_relevancy context_entity_recall answer_similarity answer_correctness 1 0.222222 1.0 0.852763 0.963191 2 0.000000 0.0 0.810099 0.202525 3 0.000000 0.5 0.947935 0.611984 今回、インプットは適当に与えているため結果も当てにならないのですが せっかくなので少し考察してみたいと思います。 考察1:Faithfulness 以下のような結果となりました。 case faithfulness 1 1.0 2 1.0 3 0.0 case 1, 3は問題ないように思えるのですが、case 2の1.0に関してはやや疑問が残ります。 faithfulnessなのでインプットパラメータのanswerとcontextsに注目します。 ここで、contextsの内容からanswerの内容が推論できれば高得点です。 そしてcase 2に関しては、「contextsの内容からanswerを推論できていない」という想定でパラメータを用意しています。 しかし、その意図と反してfaithfulnessは1.0という高いスコアが得られました。 answer contexts 2枚目にリリースされたアルバムのタイトルは「永遠の一瞬」です。 [  “リリースしたアルバム 2アルバム名: 『流星の詩』 (Meteor Poem)リリース日: 2018年9月12日 詳細: セカンドアルバムで、より成熟した音楽性と深みのある歌詞が特徴。人生の様々な局面や感情を詩的に表現した楽曲が揃っており、「夜空に咲く花」がシングルとしてリリースされ、大人のリスナーからも支持を得た。アルバム全体を通じて、一貫したテーマとして「変化」と「成長」が描かれている。”,         “の下町で生まれ育つ。幼少期から音楽に親しみ、ピアノとギターを独学で学ぶ。中学生の時に初めて作曲を始め、高校生になると地元のライブハウスで演奏するようになる。高校卒業後、音楽専門学校に進学し、本格的に音楽理論やボーカルトレーニングを学ぶ。20歳の時に自主制作アルバムをリリースし、これがレコード会社の目に留まりプロデビューを果たす。彼女の音楽は、その透明感のある声と詩的な歌詞、そして心に響くメロディで多くのファンを魅了している。出演したフェス一覧:フジロックフェスティバル (2”] faithfulnessの計算を意訳すると faithfulness = |contextsの内容から、分割したanswerを推測できた数| / |ステートメントに分割したanswerの合計数| という形になります。 今回、分母( "2枚目に2枚目にリリースされたアルバムのタイトルは「永遠の一瞬」です。"のステートメント )に関してはanswerの文が短いので恐らく、1.0です。 そしてfaithfulnessの値が1.0であることから、分子に関しても値としては1.0で、contextsの内容からanswerが推測できていると判断されている、と予想できます。 人間から見ると答えが誤っているため、推測できないように思えますが 必ずしも「 contextsの内容にanswerが含まれていない＝推測できていない 」という関係が成り立たないのかな、と思いました。 ここら辺はLLMがどういう判定するか…に依存しそうです。 考察2:Answer relevancy 以下のような結果となりました。 case answer_relevancy 1 0.990947 2 0.946483 3 0.919827 Answer relevancyなので、インプットパラメータのquestionとanswerに注目します。 answerからリバースエンジニアリングした質問内容と、questionの類似度が高ければ高いスコアです。 case question answer 1 白石 玲奈は何歳の時にデビューしましたか？ 白石 玲奈がデビューしたのは20歳の時です。 2 2枚目にリリースしたアルバムのタイトルは何ですか？ 2枚目にリリースされたアルバムのタイトルは「永遠の一瞬」です。 3 2019年に出演したフェスは何ですか？ ロック・イン・ジャパン・フェスとコーチェラ・フェスティバルに出演しました。 スコア的にはcase 1 > case 2> case 3という感じになってます。 answerからどのようなquestionが推論されるかはRagasの実装や、LLM次第かと思うのですが、 超個人的な感想でいえば、妥当なスコアなのかな？と思います。 case 1のanswerを見ると、「デビューした年齢が聞かれているんだろうなぁ」と予想できますし case 3に関しては「answerから2019年という内容を推論するのは難しいので少しスコアが低くなったのかな？」と予想されます。 考察まとめ 今回は2つの結果だけを考察してみました。 今回は仮想で用意したインプットパラメータを評価してるとはいえ faithfulnessの部分は少し疑問が残る部分もあり、完全にRagasの結果をそのまま受け入れるのもいかがなものかな、というように思いました。 しっかりとRagasの評価項目のロジックに関して理解し、結果に対して考察を行える必要がありそうです。 まとめ Ragasを使ってRAGの性能を定量的に測定することができました。 こういった定量的な結果をもとにRAGの各種パラメータを調整することで、要件を満たしているかの評価を行ったり、より精度の高いRAGを構築するための材料にできそうです。 個人的なポイントとしては 評価する際にはRagasの評価項目に対する知見(計算方法、インプット内容など)が必要 全ての項目に高いスコアを求めるのか、仕様に基づいて重要な項目にのみ高いスコアを求めるのかの判断が必要 次回は実際にRAGを組み、そのシステムをRagasで評価していきたいと思います。 ではまた！ 参考 Ragas RAG評価フレームワークのragasを使ってみた RAGの評価のフレームワーク Ragas について 提供されているMetrics（評価指標）を調べる！ RAG評価ツールの “RAGAS” を使って、RAGパイプラインの性能を測定する   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【初心者向け】RAG評価フレームワーク Ragasを必要最低限で使ってみる first appeared on SIOS Tech. Lab .

初めに PS/SLの佐々木です。 今回はオリジナルのNFTを作成できるテンプレートを作成しました。 ぜひEthereumを使用したDapps開発の理解を深めたり、社内外でエンタメとして使用場合に利用してみてください。 リポジトリは こちら 技術スタック アプリケーション Next.js version 14.2.4 TypeScript Azure Blob Storage 画像保存用 Pinata IPFS NFT metadata保存用 Alchemy Ethereum Node Provider Metamask Transaction署名用 スマートコントラクト Solidity 0.8.24 hardhat version: 2.22.5 起動方法 まずアプリケーション起動に必要なサービスのアカウントを作成し、API Keyなどを集めていきます。 application ディレクトリの .env ファイルに必要な情報です。 Azure Blob Storage Azure Portalからストレージアカウントを選択します。 こちらは基本的にデフォルトのまま作成してもらって大丈夫です。(リソースグループは良しなに作成してください。) ストレージが作成できたら ストレージブラウザ > blobコンテナ > コンテナを作成するを選択し、好きな名前でコンテナを作成してください。 次にアクセスキーを取得します。 ストレージブラウザ > セキュリティとネットワーク > アクセスキーから取得できます。 最後にOpenseaなどので作成したNFTを確認したい場合にはパブリックアクセスを許可する必要があります。 ストレージアカウント > 設定 > 構成 からBlobの匿名アクセスを許可しておきましょう 以上の情報をもとに appilcatoin ディレクトリの .env ファイルの以下の項目を設定してください。 AZURE_STORAGE_ACCOUNT_NAME=ストレージの名前(この例だとoscnft) AZURE_STORAGE_ACCOUNT_KEY=取得したアクセスキー AZURE_STORAGE_CONTAONER_NAME=作成したコンテナの名前   Pinata 次にPinataのAPI Keyを取得します。 こちら からアカウントを作成してください。 ログイン後右にあるタブのAPI Keysから生成できます。 PINATA_API_KEY= PINATA_API_SECRET= Alchemy 次にAlchemyのAPI Keyを取得します。 こちら からアカウントを作成してください ログイン後右のタブからAppsを選択しCreate Appを押下します。 Appを作成後データをマスクしている個所にAPI Keyがあります ALCHEMY_API_KEY= Metamask 次にMetamaskです。 こちらはweb3ではおなじみのWalletになります。 こちか らChromeの拡張を入れてアカウントを作成して下さい。 アドレスは赤の線のところからコピーできます。 秘密鍵は右上の三点リーダーからアカウント詳細のところから取得できます。 METAMASK_EOA_ADDRESS=EOAアドレス METAMASK_PRIVATE_KEY=秘密鍵 最後のContractAddressはデプロイしたスマートコントラクトのアドレスを入れてください。(詳細はこの後) 次に smart-contract ディレクトリ側にある .env ファイルの準備です。 以下三点は既出なので省略します。 WALLET_ADDRESS=EOAアドレス SEPOLIA_PRIVATE_KEY=Metamask秘密鍵 ALCHEMY_API_KEY= EtherScan 新しく出てくるのはEtherScanのAPI Keyです。 こちら からEtherScanいログインします。 ログイン後右側のタブから API Keys を選択し Add ボタンからAPI Keyを作成します。 マスクしている個所にAPIKeyがあります 取得したAPI Keyはこちらに追加します。 ETHERSCAN_API_KEY= 以上で事前準備完了です。 SmartContract deploy smart contractをデプロイしていきます。 deployにはEthereumのETHが必要なので こちら から取得して下さい。 今回使用するnetworkがsepoliaなので Sepolia を選択し、Wallet AddressのところにはMetamaskのアドレスを入力し、 Receive 0.0.5 Sepolia ETH を押下してください。しばらくしたらWalletにETHが送られてきます。 smart-contract のディレクトリに移動し以下のコマンドを実行するとコントラクトがデプロイできます。 npm install // 初回のみ npx hardhat compile npx hardhat ignition deploy ignition/modules/Erc721.sol --network sepolia --verify デプロイ後出力されるスマートコントラクトのアドレスを保存しておいてください。 アプリケーション起動 先ほど保存しておいたスマートコントラクトのアドレスを .env ファイルの CONTRACT_ADDRESS= に設定してください。 application ディレクトリで以下のコマンドを事項します。 npm install // 初回のみ npm run dev アプリケーションが起動できます。 名前と画像を選択するとNFTが作成できます。 NFTの確認 openseaで作成したNFTの確認方法です。 こちら にアクセスして検索ボックスに自分のmetamaskのアドレスを入力すると作成できていることが確認できます。 終わりに 以上でNFTを作成するアプリケーションの起動方法になります。 どのようにEthereum networkと通信をしているのかや、スマートコントラクトがどういう作りになっているのかなどの学習の手助けになればと思います。 実装に関する質問は随時受け付けていますので記事のコメントもしくは twitter:@kanta_sasaki_ gmail: ka-sasaki@sios.com まで連絡ください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 自作のNFTを作れるテンプレートを公開しました first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 2024/5/27 (月)、Linux Foundation Research は「2024年日本の技術系人材の現状レポート – 日本の技術セクターにおける人材戦略とモダナイゼーションの取り組みに関する調査結果」を公開しました。 Linux Foundationが「2024年日本の技術系人材の現状レポート」を公開、日本はタレントマネジメント戦略でリード https://codezine.jp/article/detail/19618 トレンドマイクロ社が、ランサムウェア「TargetCompany」の Linux 型新型亜種についての解説を公開しました。 今年は 2024/6/15 (土) ～ 6/16 (日)、7 回目の開催となります。 ランサムウェア「TargetCompany」のLinux型亜種がVMware ESXiの仮想環境を攻撃 https://www.trendmicro.com/ja_jp/research/24/f/targetcompany-s-linux-variant-targets-esxi-environments.html 6/20、ロシア製の Kaspersky 製品が米国で提供禁止となりました。 Commerce Department Prohibits Russian Kaspersky Software for U.S. Customers https://www.bis.gov/press-release/commerce-department-prohibits-russian-kaspersky-software-us-customers ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2024年6月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

今号では、nmcli コマンドの使い方やオプションについてご紹介します！ nmcli コマンドとは nmcli コマンドは、NetworkManager の機能をコマンドライン上から使用できるコマンドです。 GUI が利用できないサーバーやリモートマシンでよく使用されます。 nmcli を使用することで、各ネットワークインターフェースの状態の確認、接続の作成や削除、 IP アドレスの設定などを実行できます。 なお、nmcli コマンドは非常に多機能であり、多くのサブコマンドとオプションがあります。 そのため、数回に分けて各サブコマンド、オプションについて紹介していきます。 今回の記事では、 物理デバイスに関するサブコマンド、オプションをご紹介します。 基本の書式 サブコマンドに “device” もしくは “dev” を指定すると、物理デバイスの情報を表示します。 なお、これはオプションに “status” を指定した時と同じ動作になります。 # nmcli device DEVICE TYPE STATE CONNECTION eth0 ethernet connected System eth0 lo loopback connected (externally) lo nmcli device コマンドのオプション よく使用されると考えられるオプションを抜粋してご紹介します。 オプションに “show” 、その後に対象となるデバイスを指定すると、当該デバイスの 詳細情報を表示します。 # nmcli device show eth0 GENERAL.DEVICE: eth0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 06:EC:94:58:92:9D GENERAL.MTU: 9001 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: System eth0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/2 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 172.31.7.153/20 IP4.GATEWAY: 172.31.0.1 IP4.ROUTE[1]: dst = 172.31.0.0/20, nh = 0.0.0.0, mt = 100 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 172.31.0.1, mt = 100 IP4.DNS[1]: 172.31.0.2 IP4.DOMAIN[1]: ap-northeast-1.compute.internal IP6.ADDRESS[1]: 2406:da14:ac9:2100:8fc0:6d84:a95b:fc9b/128 IP6.ADDRESS[2]: fe80::4ec:94ff:fe58:929d/64 IP6.GATEWAY: fe80::809:7dff:fec0:1 IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 1024 IP6.ROUTE[2]: dst = 2406:da14:ac9:2100::/64, nh = ::, mt = 100 IP6.ROUTE[3]: dst = ::/0, nh = fe80::809:7dff:fec0:1, mt = 100 IP6.ROUTE[4]: dst = 2406:da14:ac9:2100:8fc0:6d84:a95b:fc9b/128, nh = ::, mt = 100 ・ GENERAL.DEVICE: 　デバイス名 ・ GENERAL.TYPE: 　デバイスの種類 ・ GENERAL.HWADDR: 　MAC アドレス ・ GENERAL.MTU: 　1回に送信できる最大のデータサイズ ・ GENERAL.STATE: 　デバイスの状態 (connected は接続済みであることを示す) ・ GENERAL.CONNECTION: 　接続の名前 ・ GENERAL.CON-PATH: 　NetworkManager 上での接続のパス ・ WIRED-PROPERTIES.CARRIER: 　信号の状態 (on は接続がアクティブであることを示す) ・ IP4.ADDRESS[1]: 　IPv4 アドレス、およびサブネットマスク ・ IP4.GATEWAY: 　IPv4 のデフォルトゲートウェイ ・ IP4.ROUTE[1]～[2]: 　IPv4 のルーティング情報 ・ IP4.DNS[1]: 　IPv4 の DNS サーバ ・ IP4.DOMAIN[1]: 　ドメイン名 ・ IP6.ADDRESS[1]: 　IPv6 アドレス ・ IP6.ADDRESS[2]: 　IPv6 アドレス (ローカルアドレス) ・ IP6.GATEWAY: 　IPv6 のデフォルトゲートウェイ ・ IP6.ROUTE[1]～[4]: 　IPv6 のルーティング情報 オプションに “connect” 、その後に対象となるデバイスを指定すると、当該デバイスに 接続します。 # nmcli device connect eth0 Device 'eth0' successfully activated with '5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03'. オプションに “disconnect” 、その後に対象となるデバイスを指定すると、当該デバイスから 切断します。 # nmcli device disconnect eth0 Device 'eth0' successfully disconnected. オプションに “modify” 、その後に対象となるデバイス、対象となるパラメータを指定すると、 当該パラメータの設定内容を変更できます。 例えば、eth0 の MTU (Maximum Transmission Unit) サイズを変更したい場合、下記の様に実行します。 # nmcli device modify eth0 mtu 5000 Connection successfully reapplied to device 'eth0'. nmcli device show eth0 コマンドで各パラメータの内容を確認すると、MTU サイズが 上記で変更した 5000 に変更されています。 # nmcli device show eth0 GENERAL.DEVICE: eth0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 06:EC:94:58:92:9D GENERAL.MTU: 5000 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: System eth0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/4 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 172.31.7.153/20 IP4.GATEWAY: 172.31.0.1 IP4.ROUTE[1]: dst = 172.31.0.0/20, nh = 0.0.0.0, mt = 100 IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 172.31.0.1, mt = 100 IP4.DNS[1]: 172.31.0.2 IP4.DOMAIN[1]: ap-northeast-1.compute.internal IP6.ADDRESS[1]: 2406:da14:ac9:2100:8fc0:6d84:a95b:fc9b/128 IP6.ADDRESS[2]: fe80::4ec:94ff:fe58:929d/64 IP6.GATEWAY: fe80::809:7dff:fec0:1 IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 1024 IP6.ROUTE[2]: dst = 2406:da14:ac9:2100::/64, nh = ::, mt = 100 IP6.ROUTE[3]: dst = ::/0, nh = fe80::809:7dff:fec0:1, mt = 100 IP6.ROUTE[4]: dst = 2406:da14:ac9:2100:8fc0:6d84:a95b:fc9b/128, nh = ::, mt = 100 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！nmcli コマンドの使い方 ～デバイス編～ first appeared on SIOS Tech. Lab .

初めに こんにちは。 PS/SLの佐々木です。 最近輪読会でDDDについての書籍を扱っているのですが、その中でValueObjectを作るのか作らないのか論争が巻き起こっています。 私自身作るに越したことはないと思うのですが、実装量が多くなるのと、必要なものだけ作ればいいのではないかと思う反面、作る作らないの判断が人によると一貫性のないコードになってしまう懸念点があります。 そこで今回はTypescriptでDomainObjectaのコンストラクタで定義されているプロパティからValueObjectを自動生成する ts-vo-generator というライブラリを作成してみました。 ts-vo-generatorの使い方 こちらのライブラリはnpmとyarnで公開しています。( npm registry ) 今回はnpmでインストールする例を紹介します。 npm install -g ts-vo-generator 使用する際には npx typescript-value-object-generator <input_file> <output_directory> このように使用します。 input_file には解析対象のclassのパスを指定し、 output_directory にはValueObjectを生成するディレクトリを指定します。 実際に使用してみる 今回は以下のようなクラスからValuObjectを自動生成してみます。 type MountainType = { id: number; name: string; elevation: number; description?: string; range: string; } // Mountain.ts export class Mountain { private constructor( private id: number, private name: string, private elevation: number, private range: string, private description?: string ) {} static new(props: MountainType): Mountain { return new Mountain( props.id, props.name, props.elevation, props.range, props.description ); } public genMessage(): string { return `${this.name} の標高は ${this.elevation} mです。`; } } 以下のコマンドを実行します。 npx ts-vo-generator ./src/model/Mountain.ts ./src/ValueObject 実行すると /src/ValueObject 配下に Description.ts や Id.ts が生成されていることが確認できます。 // Id.ts export class Id { private constructor(private readonly value: number) {} static create(value: number): Id { if (!Id.isValid(value)) { throw new Error('Invalid value'); } return new Id(value); } getValue(): number { return this.value; } private static isValid(value: number): boolean { // validation logic here return true; } } 生成されたコードを見てみると上記のようなValueObjectのスケルトンコードが生成されています。 この後は好きなロジックを追加していきます。 また一度生成したものに関して再度生成しようとすると上書きするか処理をスキップするかを聞かれます。 今後の展望 現在の ts-vo-generator ではValueObjectを作成後、元のClassの方にも手動でValueObjectを定義しないといけません。 近いうちにこちらの対応も行っていきたいと思います。 最終的には以下のようなところまで自動で生成したいと思っています。(現時点ではこの修正は手動です) import { Id } from '../ValueObject/Id'; import { Description } from '../ValueObject/Description'; import { Elevation } from '../ValueObject/Elevation'; import { Name } from '../ValueObject/Name'; import { Range } from '../ValueObject/Range'; type MountainType = { id: Id; name: Name; elevation: Elevation; description?: Description; range: Range; } // Mountain.ts export class Mountain { private constructor( private id: Id, private name: Name, private elevation: Elevation, private range: Range, private description?: Description ) {} static new(props: MountainType): Mountain { return new Mountain( props.id, props.name, props.elevation, props.range, props.description ); } public genMessage(): string { return `${this.name.getValue()} の標高は ${this.elevation.getValue()} mです。`; } } 終わりに 最後まで読んでいただきありがとうございました。 もしよろしけべばStarやコントリビュートお待ちしています。 gihtub ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post DomainObjectからValueObjectを自動生成するOSS作ってみた ~ ts-vo-generator~ first appeared on SIOS Tech. Lab .

こんにちは。サイオステクノロジー OSS サポート担当 山本 です。 今回は前回紹介した Solr がなぜ早いのかと、Solr を使いこなすためには必須となる概念についてお話ししてみようと思います。 ■Solr の検索が早いカラクリ 繰り返しになりますが Solr の主な強みは 検索が超高速 であることです。 その検索の早さを支えているのは、 インデックス という仕組みです。 Solr のインデックスはその名のとおり 登録されたドキュメント (データ) の 目次 であり、基本的には ドキュメントを登録する際に自動的に作成 されます。 ※ 前回似ていると紹介した RDB にもインデックスという概念はありますが、Solr のそれとはやり方が大きく異なるものです。 そして、検索の際にはこのインデックスから検索を行うことで超高速な文字列検索を実現できる、というわけです。 さて、ではどのようにしてこの「目次」を作っているのかと言うと…… スキーマ において各 フィールド で設定した内容に応じて ドキュメント内の 文章を解析 して、その解析結果から作られています。 特に日本語を使いたい場合、この解析のために必要になってくるのが自然言語処理の一種である 形態素解析 というものです。 ■形態素解析をなんとなく知る 自然言語処理 は非常にざっくり言ってしまえば、 人間が普段使っている言葉をコンピュータで適切に処理できるようにする ための技術・学問です。 形態素解析 は自然言語処理の一分野で、 文章を単語に分け て品詞の種類や原形などを特定する、ということを扱います。 コンピュータの分野では、更に細分化して 単語に分ける部分だけ を トークナイズ などと呼んだりもするようです。 トークナイズの例を考えてみましょう。 以下の文章を単語に分けてみてください。 This is a red pencil. これは… This / is / a / red / pencil / . こうですね。 このように単語に分割するのがトークナイズで、更に分けた単語の品詞などを特定してやれば形態素解析、と言えるでしょう（非常にざっくりとした考え方でよければ、という前提は付きますが）。 さて、この例で見てもらった英語を含め、 大半の言語では最初から単語ごとに スペースで区切って 文章を書きます 。 そのため、コンピュータで扱う場合でも基本的には 機械的に「スペース」という文字が出てきたら区切る 、という処理で単語に分けられる（一部例外はあり）ため、形態素解析というものは原則としてあまり難しいものではないようです。 一方で日本語はというと……例えば以下の文章を単語に分けてみましょう。 これはあかいえんぴつです。 これは… これ / は / あかい / えんぴつ / です / 。 こうなりますね。 さて、我々のように日常的に日本語を使っている人間であれば特に問題なく単語に分割できるでしょうが、これをコンピュータでやりたいとなるとどうでしょう。 日本語というのは改めて見てみると、明確な区切りとなる目安がなく、文法も比較的自由で、活用形だったり造語だったり口語やスラングなど変則的な単語が乱れ飛ぶ…… そうです。 日本語の形態素解析というのは、非常に難しい ものなのです。 現在の日本語の形態素解析は、コンピュータに単語を判別するための 辞書データ を登録した上で、上手く解析するための様々なアプローチ……例えば 　・考えうる区切り方を全て抜き出して、品詞の繋がり方などから一番それっぽい区切り方を選ぶ 　・「ここで区切ると前後が適切な言語になるか」を逐一チェックしていく などのような処理を実装した、いくつかのアルゴリズムがあるとされています。 現在では高い精度で形態素解析をすることができますが、先述のとおり日本語があまりにも変則的で自由な言語であるため、 100% 完璧に正しく形態素解析をできる保証はない 、というのが現状です。 色々ごちゃごちゃとお話しましたが、Solr で日本語を使う上では、 　・ なんか単語に分けてるらしい 　・ 単語に分けるために 形態素解析 って考え方を使うらしい 　・ 形態素解析には 辞書データ ってものが必要らしい 　・ 確実に意図した通りの単語に区切れるとは限らないらしい という点を覚えておいてください。 余談ですが、例えば英語だと同じスペルでも違う品詞だったり全く違う意味を持つ単語が多数あるため、単語に分割した後の適切な意味を判定するステップが難しかったりするなど、それぞれの言語で違った自然言語処理の難しさがあったりします。 ■Solr のインデックス作成の様子を見てみる 前置きが長くなりましたが、最初にお話した Solr の インデックス作成 (= インデキシング ) がどのように行われるか見てみましょう。 Solr ドキュメントの登録時には、 フィルタ と呼ばれる一連の処理を 複数組み合わせ て、その処理結果をインデックスとして登録します。 フィルタはフィールドごとに組み合わせ方を設定 することができます。 また、 検索時にも設定した組み合わせでフィルタの処理を行った結果を、 実際の検索ワード として使用 します。 フィルタにはデフォルトで用意されているものだけでも様々な種類がありますが、一例としては 　・文章を単語に分割して品詞を特定する 　・単語を基本形に戻す 　・半角文字を全角文字に直す 　・助詞・助動詞・代名詞など検索に適さない要素を削除する などのようなものがあります。（ここで形態素解析の概念を使っていますね） 前回見た Solr の管理画面で実際のインデキシングの処理の様子を確認することができる ので、今回もデモ用環境を使って試してみましょう。 デモ環境の立ち上げは以下のコマンドで、 ## 前回の環境を消してしまっている場合 $ podman run -dt --name test-solr -p 8984:8983 solr solr-demo ## 前回の環境から続けて試す場合 $ podman start test-solr 管理用の WebUI はブラウザで以下のアドレスにアクセスすれば OK でしたね。 http://(IPアドレス or ホスト名):8984/solr WebUI にアクセスできたら、「プルダウンから “demo” を選ぶ」→「Analysis」の順に遷移しましょう。 この画面からインデキシングの処理のテストができます。 今回は “ Analyse Fieldname / FieldType ” を、デフォルトで用意されている日本語向けの設定である “ text_ja ” にして試してみましょう。 画面上部の入力部分 にテストしてみたい文章を入れて、” Analyse Values ” ボタンを押下すると、 設定されているフィルタごとの処理結果 が順に表示されるはずです。 実際にインデックスとして登録される（または検索ワードとして使用される）のは、設定された全てのフィルタを適用した結果となる 一番下 に表示されているものです。 ■うまくいかない例も見てみる 折角なので思い通りにいかない例も見てみましょう。 先の “Analysis” のページで、今度は「 うらにわにはにわにわとりがいる。 」という文章を解析させてみましょう。 これはご存じのとおり 裏庭 / に / は / 二羽 / 鶏 / が / いる / 。 なので、このとおりになってほしいところですが…… 結果はご覧のとおり、「うら / に / わに / はにわ / にわとり / が / いる」と何か鰐や埴輪が生えてきてしまっています。あくまで実験として見るだけなら、ちょっと愉快な感じですね。 ともあれ、このように意図した通りの形になってくれないケースもあり得る、ということは覚えておいてください。 余談ですが、解析させる文章を「裏庭には二羽鶏がいる」と漢字も使った形にしてやれば、大体ちゃんと上手くやってくれます。 意図しない形になってしまう可能性があるのは、あくまで 文法として正しい、意図しない分け方 がある場合という点も気を付けてください。 ■最後に 今回は Solr のカラクリの核である “ インデックス ” と、インデックスを考える上で必要不可欠になる “形態素解析” という概念についてお話ししてみました。 見てもらった通り、Solr では 登録されたドキュメントを単語に分割して “インデックス” を作成する ので、例えば登録したデータ (ドキュメント) から 「ぶどう」という 単語が含まれている ものを探す、というような処理に圧倒的に強くなります。 前回似ている部分もあるというお話をした RDB ではこのような機能はないため、同じようなことをしようとすると検索のたびに逐一全てのデータをチェックする必要があり、例えるなら「本の目次から目標を探す」か「その本を全て読みながら目標を探す」かくらいの差が出る、というわけです。 ※ RDB でも “LIKE” 句で似たようなことはできますし、文字列検索という限定的な用法以外では原則 RDB のほうが便利な点には留意してください。 ここさえ押さえてしまえば、あとはデータの登録手順を覚えれば Solr を使えると言っても差し支えないはずです。 あとは思い通りにいかなかった場合の対処案などもありますが……そのあたりはまたいずれ。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Solr って何者？②：早さの秘訣、インデックスのカラクリ first appeared on SIOS Tech. Lab .