未分類」カテゴリーアーカイブ

AIMOS USB ボリュームコントローラ

参考URL

初期設定

メモ帳を起動し、フォーカスした状態で、AMOSのノブを押しながらPCと接続する。

iWit USB Controller V4.01
http+//iWit.me

Sort Press ) <1 Second To Enter Windows Mode

Long Press ) >1 Second To Enter Mac Mode
Enter Setup Mode

カスタマイズ

  • WINDOWS MODE –
    1 Clockwise + PageUp
    2 Counterclockwise + PageDown
    3 Press + Volume Mute
    4 Press~Clockwise + Volume~2
    5 Press~Counterclockwise + Volume-2
    6 Long Press + Volum Mute
    @RESTORE DEFAULT[
    @SAV ‘ QUIT[

LLM/RAG環境の構築

実行スクリプト

PS C:\Users\mars> docker run -d -p 3000:8080 –e RAG_EMBEDDING_ENGINE=ollama -e RAG_EMBEDDING_MODEL=bge-m3:latest –add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data –name open-webui-rag –restart always ghcr.io/open-webui/open-webui:main

PS C:\Users\mars>docker run -d -p 3000:8080 -e RAG_EMBEDDING_ENGINE=ollama -e RAG_EMBEDDING_MODEL=bge-m3:latest –gpus all –add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data –name open-webui –restart always ghcr.io/open-webui/open-webui:cuda

埋め込みモデル設定

  • 設定画面 → ドキュメント(Documents)セクションで:
  • セマンティックベクトルエンジン: Ollama
  • モデル名: bge-m3:latest
  • チャンクサイズ: 1500
  • チャンクオーバーラップ: 100
  • その他パラメータはデフォルト維持13
  • **知識ベース作成**
  • 1. Workspace → Knowledge → [+ Create Knowledge Base]
  • 2. 名前と用途(例: Assistance)を設定
  • 3. ドキュメントファイル(PDF/TXT/Markdown)をドラッグ&ドロップでアップロード[2][5]
  • **質問方法**
  • 1. 新規チャット作成時に使用するLLMを選択(例: Qwen2.5系モデル)
  • 2. チャット入力欄に`#`を入力→アップロード済みドキュメントを選択
  • 3. 自然言語で質問を入力[1][5]


openwab-uiの画面のchat controlパラメータで、設定をdefaultから変更した方が良い項目と内容を教えて

推奨される変更例:

以下は、一般的なユースケースにおける例です:

ユースケースMax TokensTemperatureTop-pRepetition Penalty
短い正確な回答1000.50.81.2
長文で詳細な説明3000.70.91.1
創造的・自由な文章生成5001.01.01.0

Grokに問い合わせた結果

Open WebUIのRAG機能を利用する場合、重要なパラメータなどの要素と、その設定値は?

Open WebUIでRAG(Retrieval-Augmented Generation)機能を利用する際、効果的な動作を実現するためには、いくつかの重要なパラメータや設定要素を適切に調整する必要があります。以下に、主要な要素とその設定値について説明します。これらはOpen WebUIの管理者パネル(例: 「設定 > ドキュメント」や「ワークスペース > モデル」)で調整可能な項目に基づいています。


1. 埋め込みモデル (Embedding Model)

  • 役割: ドキュメントをベクトル化し、検索時の類似度計算に使用するモデル。
  • デフォルト: Sentence Transformers(例: all-MiniLM-L6-v2)。軽量だがパラメータ数が少ない。
  • 推奨設定値:
  • 高精度を求める場合: nomic-embed-text(137Mパラメータ)やmxbai-embed-large(334Mパラメータ)など、より大きなモデルを選択。
  • 多言語対応が必要な場合: bge-m3(多言語対応で高性能)。
  • ポイント: デフォルトモデルは軽量だが精度が不足する場合があるため、用途に応じて変更を検討。モデル変更後はドキュメントの再アップロードが必要。

2. モデル再ランキング (Model Reranking)

  • 役割: 検索結果の関連性を再評価し、より適切なドキュメントを上位に配置。
  • デフォルト: 再ランキングなし。
  • 推奨設定値:
  • 軽量モデル: cross-encoder/ms-marco-MiniLM-L-6-v2(高速だが精度は中程度)。
  • 高精度モデル: cross-encoder/ms-marco-MiniLM-L-12-v2(より正確だが処理負荷が増加)。
  • ポイント: 再ランキングを有効にすると回答の質が向上する。特に情報量が多いドキュメントを扱う場合に有効。

3. チャンクサイズ (Chunk Size)

  • 役割: ドキュメントを分割するサイズ。検索精度とコンテキストのバランスに影響。
  • デフォルト: 1500トークン。
  • 推奨設定値:
  • 小規模ドキュメント: 500〜1000トークン(細かい粒度で検索精度を向上)。
  • 大規模ドキュメント: 1500〜2000トークン(コンテキストを広く保持)。
  • ポイント: 小さすぎるとコンテキストが不足し、大きすぎるとノイズが増えるため、ドキュメントの内容に応じて調整。

4. コンテキストの長さ (Context Length)

  • 役割: LLMが回答生成時に参照するコンテキストの最大長。
  • デフォルト: 2048トークン。
  • 推奨設定値:
  • 短い回答: 1024〜2048トークン。
  • 詳細な回答: 4096トークン(モデルが対応している場合)。
  • ポイント: 使用するLLMの最大トークン数に依存。長すぎると処理速度が低下する可能性がある。

5. トップK (Top K)

  • 役割: 検索結果から上位何件のドキュメントをコンテキストとして使用するか。
  • デフォルト: 10。
  • 推奨設定値:
  • 高精度重視: 3〜5(関連性の高いものだけを厳選)。
  • 情報量重視: 10〜15(幅広い情報をカバー)。
  • ポイント: 値が大きいほど多様な情報を含むが、ノイズも増える可能性がある。

6. ドキュメントの前処理

  • 役割: 検索用データの品質を向上させる。
  • 設定値:
  • テキストファイル推奨(PDFやWordは事前にテキスト変換)。
  • ノイズ除去(余分な空白、タブ、改行の整理)。
  • ポイント: 前処理が不十分だと検索精度が落ちるため、きれいなデータを用意することが重要。

7. 生成モデル (LLM)

  • 役割: 検索されたコンテキストをもとに回答を生成するモデル。
  • 推奨設定値:
  • ローカル: gemma2:2b(軽量)、ELYZA-japanese-Llama-2-13b(日本語対応)。
  • API経由: gpt-4o-mini(高精度だがコストがかかる)。
  • ポイント: RAGの効果は生成モデルの性能にも依存。ローカル環境ではハードウェアスペックを考慮。

設定の流れ(例)

  1. 管理者パネル > 設定 > ドキュメントで埋め込みモデルをbge-m3に変更。
  2. モデル再ランキングcross-encoder/ms-marco-MiniLM-L-12-v2を指定。
  3. チャンクサイズを1000、コンテキストの長さを2048、トップKを5に設定。
  4. 前処理済みのテキストファイルをアップロード。
  5. ワークスペース > モデルで生成モデル(例: gemma2:2b)を選択し、RAG用にカスタムモデルを作成。

注意点

  • ハードウェア依存: ローカル環境ではGPUやメモリ容量が処理速度に影響。
  • 再アップロード: 埋め込みモデルやチャンクサイズを変更した場合、既存ドキュメントを削除して再登録が必要。
  • 試行錯誤: 最適な設定はデータや用途により異なるため、実験しながら調整する。

これらのパラメータを適切に設定することで、Open WebUIのRAG機能を最大限に活用し、高精度で有用な回答を得られる環境を構築できます。

100K文字程度のテキストをRAGで検索すると仮定した際に、それぞれのパラメータの最適値は

100K文字程度のテキストをRAG(Retrieval-Augmented Generation)で検索する場合、データ量としては中規模(日本語で約50K〜100Kトークン程度と仮定)に該当します。この規模のテキストを効率的かつ高精度に処理するためには、パラメータの設定に以下の点を考慮する必要があります。以下に、前回の回答をベースに具体的な最適値を提案します。


前提条件

  • テキスト量: 100K文字(日本語の場合、約50Kトークンと仮定。句読点や単語の長さに依存)。
  • 目的: 関連性の高い情報を迅速に検索し、正確な回答を生成。
  • 環境: ローカル(GPUあり)またはクラウド(API利用)を想定。

1. 埋め込みモデル (Embedding Model)

  • 最適値: bge-m3
  • 理由:
  • 100K文字は複数のトピックを含む可能性が高く、多言語対応かつ高精度な埋め込みが必要。
  • bge-m3は約568Mパラメータを持ち、日本語を含む多言語で優れた性能を発揮。
  • 代替案: リソースが限られる場合、all-MiniLM-L12-v2(軽量かつそこそこの精度)。

2. モデル再ランキング (Model Reranking)

  • 最適値: cross-encoder/ms-marco-MiniLM-L-12-v2
  • 理由:
  • 中規模テキストでは検索結果にノイズが混ざりやすいため、再ランキングで精度を向上。
  • L-12-v2は精度と速度のバランスが良く、100K文字程度の処理に適している。
  • 代替案: 高速処理優先ならMiniLM-L-6-v2

3. チャンクサイズ (Chunk Size)

  • 最適値: 800〜1000トークン
  • 理由:
  • 100K文字(約50Kトークン)を50〜60チャンクに分割可能。
  • 800〜1000トークンは、1チャンクで十分なコンテキストを保持しつつ、検索時のノイズを抑える。
  • 補足:
  • 日本語は英語よりトークン数が多くなりがちなので、1000トークン以下に抑えるのが現実的。
  • 小さすぎると(例: 500トークン)コンテキストが不足し、大きすぎると(例: 2000トークン)関連性が薄れる。

4. コンテキストの長さ (Context Length)

  • 最適値: 2048トークン
  • 理由:
  • 検索結果から複数チャンク(例: トップ3〜5)を参照する場合、合計で1500〜2000トークン程度になる。
  • 2048トークンは多くのモデル(例: Llama系やGemma系)が対応可能で、実用的な上限。
  • 補足: 高性能モデル(例: GPT-4o, 128Kトークン対応)を使う場合、4096トークンも検討可能だが、ローカルでは負荷が増大。

5. トップK (Top K)

  • 最適値: 5
  • 理由:
  • 100K文字から50〜60チャンクが生成されると仮定し、上位5件で十分な関連性を確保。
  • 5は精度と情報量のバランスが良く、生成時のコンテキスト過多を防ぐ。
  • 補足: 幅広い情報を求める場合、10まで増やしても可。ただし、ノイズが増えるリスクを考慮。

6. ドキュメントの前処理

  • 最適値:
  • テキストを事前に整形(余分な空白や改行を削除)。
  • 段落ごとに明示的な区切り(例: ---)を挿入。
  • 理由:
  • 100K文字は構造化されていない場合が多く、前処理で検索精度を向上。
  • 日本語特有の曖昧な句読点を整理することで、チャンク分割が自然に。

7. 生成モデル (LLM)

  • 最適値:
  • ローカル: gemma2:9b(9Bパラメータで高精度かつ中規模データに適応)。
  • クラウド: gpt-4o-mini(コスト効率と性能のバランス)。
  • 理由:
  • 100K文字のコンテキストを理解し、自然な日本語で回答するには、中〜大規模モデルが必要。
  • gemma2:9bはローカルで実行可能な高性能モデル、gpt-4o-miniはAPI利用時の最適解。

具体的な設定例

  • 埋め込みモデル: bge-m3
  • 再ランキング: cross-encoder/ms-marco-MiniLM-L-12-v2
  • チャンクサイズ: 1000トークン
  • コンテキストの長さ: 2048トークン
  • トップK: 5
  • 前処理: 整形済みテキスト、段落区切り付き
  • 生成モデル: gemma2:9b(ローカル)またはgpt-4o-mini(クラウド)

想定される動作

  • チャンク数: 100K文字 ÷ 1000トークン ≈ 50チャンク。
  • 検索時間: 埋め込み生成と再ランキングで数秒〜十数秒(ハードウェア依存)。
  • コンテキストサイズ: トップ5 × 1000トークン = 約5000トークン(2048に制限されるため、実質上位2〜3チャンクが使用される)。

調整のポイント

  • 精度不足の場合: トップKを3に減らし、再ランキングモデルの精度を上げる(例: L-12-v2Electra)。
  • 速度不足の場合: チャンクサイズを1200に増やし、チャンク数を減らす。
  • コンテキスト不足の場合: コンテキスト長を4096に拡張(対応モデルが必要)。

この設定なら、100K文字程度のテキストをRAGで効率的に検索し、高精度な回答を生成できるはずです。実際のデータやハードウェアに応じて微調整してください。

Install RTL_SDR Support

https://gist.github.com/derme302/a702e421b7cd133753e5ab87101a01c4

https://github.com/merbanan/rtl_433/tree/master

データの取得例

$ rtl_433  2>/dev/null
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-11-12 21:58:45
model     : Emax-W6      id        : dd9
Channel   : 4            Battery_OK: 1             Temperature: 59.3 F       Humidity  : 81 %
Wind avg speed: 0.0 km/h Wind Direction: 228       Total rainfall: 0.2 mm    UV Index  : 1             Lux       : 0
Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-11-12 21:59:15
model     : Emax-W6      id        : dd9
Channel   : 4            Battery_OK: 1             Temperature: 59.1 F       Humidity  : 80 %
Wind avg speed: 0.0 km/h Wind Direction: 229       Total rainfall: 0.2 mm    UV Index  : 1             Lux       : 0
Integrity : CHECKSUM

$ rtl_433 2>/dev/null | python t.py

$ cat t.py
#!/usr/bin/python
import sys
for line in sys.stdin:
    #print(line.strip())
    res=line.split()
    if len(res) == 34:
        TT=round((float(res[6])-32)/1.8,1)
        HH=res[10]
        WS=round(float(res[15])/3600,1)
        WD=res[19]
        RR=res[22]
        UV=res[27]
        UL=res[30]
        print(TT,HH,WS,WD,RR,UV,UL)
mars@pi4Bu:~/rtl_433 $ rtl_433   2>/dev/null |python t.py
18.4 69 0.0 229 0.2 1 0
18.4 69 0.0 229 0.2 1 0
18.4 69 0.0 229 0.2 1 0
18.4 69 0.0 229 0.2 1 0
18.5 69 0.0 229 0.2 1 0
18.4 69 0.0 229 0.2 1 0
18.4 69 0.0 229 0.2 1 0
18.4 69 0.0 229 0.2 1 0

Apache2 の設定を確認する

  • Ubuntuでのapache2の設定確認方法について説明します:基本的な設定確認コマンド
    構文チェックbash
    sudo apachectl -t
    またはbash
    sudo apache2ctl configtest
  • 詳細な設定確認
    sudo apachectl -S # 仮想ホストの設定確認
  • sudo apachectl -M # 読み込まれているモジュールの確認

今年のノーベル賞はAI祭り

物理学賞2024年のノーベル物理学賞は,「人工ニューラルネットワークによる機械学習を可能にする基礎的発見と発明」の功績で,米プリンストン大学のホップフィールド(John Hopfield)名誉教授とカナダのトロント大学のヒントン(Geoffrey Hinton)名誉教授に授与される。 (日経サイエンス)

化学賞2024年のノーベル化学賞は「コンピューターを用いたタンパク質の設計」の功績で米ワシントン大学のベイカー(David Baker)教授に,「コンピューターを用いたタンパク質の構造予測」で英国Google DeepMindのハサビス(Demis Hassabis)氏とジャンパー(John Jumper)氏に授与される (日経サイエンス)

化学賞受賞のハサビス氏は、世界最高ランクの囲碁棋士である李世乭に5試合中4試合に勝利したAlphaGoプログラムを開発したほか、機械学習のスタートアップであるDeepMindテクノロジーズを共同で立ち上げCEOを務めた。

生成AIを利用した様々なサービスが利用できる昨今ですが、Googleが今のところ無料で公開しているnotebookLMを使ってみました。(料金については、Googleによると「NotebookLM はまだ早期テスト段階であるため、現時点では料金は発生しません」となっていますが、そのうちに課金の対象になるかも?)

Google NotebookLMは、ユーザがアップロードした資料に対して、要約や質問に対する回答などを得ることができます。試しに、自分が2008年に執筆した博士論文のpdf(約100ページ)をアップロードしてみました。Google NotebookLMの興味深い機能の一つに、男女2人が、アップロードしたファイルの内容についての説明・感想を数分程度の会話を音声で聞くことができます。アップロードした資料が日本語であっても、今のところ音声は英語だけなのが残念な点ですが、再生できるようにしてみました。

Google NotebookLMが処理した結果の「要約」は、次のようになりました。Google NotebookLMの出力は、飾りのないテキストなので、多少読みやすくなるよう手動で体裁を整えました。

マルウェア自動解析システムの研究

1. マルウェアの脅威と対策
 近年、マルウェアによる被害が急増しており、その種類や手法も多様化していることを説明。
従来のシグネチャベースの対策では未知のマルウェアへの対応が困難であることを指摘。
マルウェアの挙動解析に基づく自動解析システムの必要性を論述。

2. マルウェア自動解析システムの概要
 本研究で提案するマルウェア自動解析システムの全体構成を図を用いて説明。
システムの主要な機能である、マルウェアの動的解析、挙動データの収集、数値化と類似性判定、そして視覚化について概説。

3. マルウェアの動的解析
 サンドボックス環境を用いたマルウェアの動的解析手法について解説。
APIコール、レジストリへのアクセス、ネットワーク通信など、解析対象となるマルウェアの挙動を列挙。解析結果から得られる情報とその利点について説明。

4. 挙動データの数値化と類似性の判定
 マルウェアの挙動データを数値化するための特徴量抽出方法を説明。
使用する特徴量として、APIコール系列、レジストリキー、通信先ポート番号などを例示。
数値化された挙動データに基づいて、マルウェア間の類似性を判定するためのアルゴリズムを解説。具体的には、ユークリッド距離、マンハッタン距離、コサイン類似度などの距離尺度を用いた類似度計算方法を説明。

5. 挙動データの視覚化
 多次元尺度構成法 (MDS) を用いたマルウェア挙動の視覚化手法について説明。
MDS により、高次元の特徴量空間を2次元または3次元に写像することで、マルウェアの類似性を視覚的に表現。視覚化結果から、マルウェアの分類や未知マルウェアの検出が可能になることを示唆。

6. 実験と評価
 実験に用いたマルウェア検体データセットの概要を説明。
検体数は約8,000個体で、トレンドマイクロ・ウィルスバスター2007を用いてスキャンし、名前が判明したものを使用。提案システムの性能評価指標として、検出率、誤検知率、処理時間を設定。実験結果に基づいて、提案システムが従来手法と比較して高い検出率と低い誤検知率を達成したことを示す。処理時間についても、実用的な範囲内であることを確認。

7. PDBを用いたマルウェア挙動の可視化
 マルウェアの挙動を可視化するために、PDB (Position Dependent Bits) を導入。
PDBを用いることで、マルウェアの挙動をビット列として表現し、視覚的に比較分析することが可能になる。実際に、上位15種類のマルウェアについて、PDBへの変換結果を視覚化し、その特徴を分析。結果として、同種に分類されるマルウェアの挙動は一定ではないものの、利用ポートの状況など、種類ごとに特徴が認められることを示す。

8. 結論と今後の展望
 本研究では、マルウェアの挙動解析に基づく自動解析システムを提案し、その有効性を検証。
提案システムは、未知のマルウェアに対しても高い検出率を達成し、マルウェア対策への貢献が期待される。今後の課題として、解析精度の向上、処理速度の高速化、マルウェアの進化への対応などを挙げ、さらなる研究の必要性を論述。

9. 付録
 上位15種類のマルウェアのPDB可視化結果の詳細を掲載。実験対象とした検体の内訳を、AV製品ごとに「科名」と「科名+亜種名」で分類し、検体数を表示。特徴量抽出に用いたパラメータ (port100_md50_svcN_rootN_host_file4.hex) と、それによって得られたデータセットの分割方法について説明。各分割データセットにおける、F値、F&V値、F-STD、F&V-STD、Totalなどを表形式で表示。

参考文献
本研究に関連する参考文献を列挙。