omni-ai-optimizer

Omni AI オプティマイザー

Omni のセマンティックモデルを最適化して、Blobby（Omni Agent）が正確で文脈に沿った回答を返せるようにします。

ヒント：変更を加える前に、omni-model-explorer を使って現在の AI コンテキストを確認してください。

前提条件

# Verify the Omni CLI is installed — if not, ask the user to install it
# See: https://github.com/exploreomni/cli#readme
command -v omni >/dev/null || echo "ERROR: Omni CLI is not installed."

# Show available profiles and select the appropriate one
omni config show
# If multiple profiles exist, ask the user which to use, then switch:
omni config use <profile-name>

# Confirm the active profile is authenticated and inspect your permissions:
omni whoami whoami

認証：プロファイルはAPI キーまたはOAuthで認証します。whoami（または任意の呼び出し）が401を返した場合は、ユーザーに引き継ぎ、! omni config login <profile> を実行するよう依頼してください（OAuth 2.1 のブラウザーフローで、ブラウザー上で約 2 分間待機します）。ヘッドレス／CI セッションでは（ブラウザーがないためタイムアウトするので）、自分で config login を実行しないでください。ローカルの対話型マシンでは実行してもかまいません。プロファイルの設定（omni config init --auth oauth）と、--schema を使ったコマンドおよびリクエストボディの形式の確認については、omni-api-conventions ルールを参照してください。

Modeler または Connection Admin の権限が必要です。

コマンドの確認

omni models --help                    # List all model operations
omni models yaml-create --help        # Show flags for writing YAML

ヒント：プログラムで解析するために構造化出力を強制するには -o json を、読みやすい表形式で表示するには -o human を使ってください。デフォルトは auto（TTY では人間向け、パイプ経由では JSON）です。

安全なモデル書き込みのデフォルト

• まずブランチを作成する — ユーザーが本番環境への変更を明示的に求めない限り、AI 最適化 YAML を共有モデルに直接書き込まないでください。モデルブランチを作成するか使用してから、ブランチ ID を omni models yaml-create に渡してください。
• 書き込む前に読み取る — ai_context、ai_fields、sample_queries、説明、同義語を追加する前に、現在のトピック／ビューの YAML を確認してください。求められた最適化がすでに存在する場合は、重複して追加せず、設定済みであることを伝えてください。
• トピックに関する依頼はトピック内で対応する — ユーザーがトピックの改善を求めた場合は、トピックレベルの ai_context、ai_fields、sample_queries を優先してください。フィールドレベルの synonyms は、特定の 1 つのフィールドの別名に関する依頼であることが明確な場合にのみ使用してください。
• トピック全体のマッピングが完了している場合、「補足」の同義語を追加しない — 「Blobby が売上と注文数を混同する」や「これらの用語を正しくマッピングして」といった依頼で、トピックレベルの ai_context がすでにビジネス用語を正しいフィールドにマッピングし、必要な否定的ガードレールも含んでいる場合は、重複する書き込みは不要であると報告して終了してください。この場合、フィールドレベルの同義語を追加するのは冗長であり、プロンプト／トークンの負荷を増やします。
• --name を使ってブランチを作成する — omni models create-branch <model-id> --name <branch-name> は JSON の --body を受け付けません。

Blobby の仕組み

コンテキストの優先順位

Omni は次の順序でコンテキストウィンドウを構成します。

1. Omni Engineering が事前に構築したコンテキストとチューニング
2. モデル、トピック、ビューの ai_context
3. トピックの description
4. トピックの name と base_view
5. 優先されるフィールドプロパティ — name（完全修飾名、view.field）とフィールドの ai_context。削除されることはありません。
6. 削除対象のフィールドプロパティ — 以下の順序で、容量が不足すると他のすべてのプロパティが削除されます。

hidden: true のフィールドは完全に除外されます。ai_chat_topics（モデルレベル）は、Blobby が参照できるトピックを制御します。

削除の優先順位

トピックのメタデータが割り当て上限を超えると、Omni は優先順位の低いプロパティから削除します。各プロパティを次に進む前に、すべてのフィールドから削除します。

all_values → sql → sample_values → description → group_label → label → aggregate_type → data_type → synonyms

覚えておくべき点は 2 つあります。

• all_values が最初に削除されるのは、AI が必要に応じてフィールドの値を取得できるためです。synonyms が最後に削除されるのは、ユーザーの言い回しをフィールドに対応付けるうえで最も重要だからです。
• Omni が特定のトピックのコンテキストを構成する際、どのレベル（モデル、トピック、ビュー、フィールド）でも ai_context は削除されません。それでも収まらない場合、Omni はモデル検索からビュー全体を削除し、それでも解決しない場合はリクエストがエラーで失敗します。肥大化した ai_context は単なる軽微なコストではありません。フィールドメタデータを圧迫し、クエリを完全に失敗させる可能性があります。例外はトピック選択の場合で、この場合はビューレベルの ai_context が最初に削られます（下記の上限表を参照）。

コンテキストは指針であり、指示ではありません

すべてのコンテキストはまとめて LLM に渡され、LLM がその重み付けを判断します。

• モデルレベルの ai_context がトピックレベルの ai_context を確実に上書きするわけではありません。 保証されていない優先順位を前提に設計しないでください。
• 特に複雑な指示や、相互に矛盾する指示は、一部しか従われない、あるいはまったく従われない場合があります。
• 動作は非決定的です — 同じ質問でも、実行ごとに異なるコンテキストが取得されることがあります。

網羅的なルールブックより、少数の明確で矛盾のない指示を優先してください。ワークブックインスペクターを使って、AI が実際に受け取った内容を確認してください。

コンテキストが適用される範囲

Omni Agent だけでなく、埋め込みチャット（トピック選択とモデル検索を含む）、Workbook Agent によるクエリ／SQL 生成、Dashboard Agent の要約、AI による可視化と要約の生成、AI フィルター生成、Modeling Agent にも適用されます。コンテキストを変更すると、これらすべてに影響します。

ai_context の記述

YAML API で追加します。

omni models yaml-create <modelId> --body '{
  "fileName": "order_transactions.topic",
  "yaml": "base_view: order_items\nlabel: Order Transactions\nai_context: |\n  Map \"revenue\" → total_revenue. Map \"orders\" → count.\n  Map \"customers\" → unique_users.\n  Status values: complete, pending, cancelled, returned.\n  Only complete orders for revenue unless specified otherwise.",
  "mode": "extension",
  "branchId": "{branchId}",
  "commitMessage": "Add AI context to order transactions topic"
}'

良い ai_context とは

用語の対応付け — ビジネス用語をフィールド名に対応付けます。

ai_context: |
  "revenue" or "sales" → order_items.total_revenue
  "orders" → order_items.count
  "customers" → users.count or order_items.unique_users
  "AOV" → order_items.average_order_value

データの特性 — フィールド名からは分かりにくい内容を説明します。

ai_context: |
  Each row is a line item, not an order. One order has multiple line items.
  total_revenue already excludes returns and cancellations.
  Dates are in UTC.

「これらの用語を正しく対応付けて」や「Blobby が X と Y を混同する」といった場合は、トピックレベルの ai_context に肯定的な対応付けを追加するのが解決策です。同義語だけでは、競合する 2 つの指標を判別できません。同義語がすでに存在し、トピックコンテキストに使用してはいけないものだけが記されている場合は、同義語を追加するのではなく、不足している肯定的な対応付けを追加してください。

良い例：

ai_context: |
  "revenue" or "sales" -> order_items.total_revenue
  "order count" or "number of orders" -> order_items.count
  Never use order_items.count when the user asks for revenue.

次のような記述だけで終わらせないでください。

measures:
  total_revenue:
    synonyms: [revenue, sales]
  count:
    synonyms: [order count, orders]

動作に関する指針 — よくあるパターンを示します。

ai_context: |
  For trends, default to weekly granularity, sort ascending.
  For "top N", sort descending and limit to 10.

ペルソナのプロンプト — 分析の観点を設定します。

ai_context: |
  You are the head of finance analyzing customer payment data.
  Default to monetary values in USD with 2 decimal places.

コンテキストを簡潔に保つ

ai_context は、負荷が高まったときに Omni が削減できない唯一のプロパティであり、モデル内で最も希少な予算です。最も余裕があるものではありません。冗長な記述はフィールドのメタデータを先に押し出し、最終的にはリクエストが失敗する原因にもなります。

• ai_context の各項目は、1～2 文を目安にしてください。一般的な説明ではなく、曖昧さの解消と注意点に焦点を当てます。
• ラベルは短く、人が読みやすいものにしてください。重複する修飾は避けます（例：「Order Total Revenue Amount」→「Total Revenue」）。
• 長い description の値は、直接的な表現に書き直してください。説明がフィールド名を繰り返している場合は、削除してください。

モデルレベルのコンテキスト

モデルレベルの ai_context は、すべてのトピックで共有される指針を提供し、トピック選択にも影響します。フィールドではなくトピックが誤って選ばれる場合に役立ちます。

通貨、会計年度カレンダー、トーン、プライバシールールなど、インスタンス全体に適用される慣例に使用し、トピック固有の対応付けはトピックに記述してください。

モデルの複数のトピックにまたがるクエリ例には、モデルレベルの sample_queries パラメーターもあります。

高度な ai_context のテンプレート化

以下は、モデル、トピック、ビューの各レベルの ai_context にのみ適用されます。

ユーザー属性を使ったパーソナライズ

クエリ実行時に、{{omni_attributes.<attribute_name>}} は現在のユーザーの属性値に置き換えられます。

ai_context: |
  You are a sales analyst. When someone asks about their team or pipeline,
  always filter by account.segment = {{omni_attributes.segment}}
  and account.region = {{omni_attributes.region}}.

注意点：ディメンションまたはメジャーの ai_context ではサポートされません。その場合、値は置換されず、そのまま使用されます。フィールド参照とフィルター条件もサポートされず、検証警告が発生します。

omni_llm で特定のモデル階層を対象にする

AI モデルの階層（smartest、standard、fastest）を指定して指示の適用範囲を設定することで、コストのかかる推論指示が高速モデルの負担にならないようにできます。セクションには Mustache 構文を使用します。「when」には {{# ... }}、「when not」には {{^ ... }} を使います。

ai_context: |
  This topic focuses on financial transactions.

  {{# omni_llm.smartest }}
  For complex multi-table queries, consider indirect relationships and provide rationale for join path selection.
  {{/ omni_llm.smartest }}

  {{# omni_llm.fastest }}
  Prefer single-table queries when possible.
  {{/ omni_llm.fastest }}

omni_agent で対象エージェントを指定する

読み取り対象のエージェントにコンテキストを絞り、特定のエージェント向けの大きなコンテンツで他のエージェントのコンテキストウィンドウが圧迫されないようにします。

• analyze — モデルの検索とクエリの生成
• build — トピックのメタデータ生成、会話からの学習
• simple_summarize — タイル／可視化の要約、クエリのメタデータ

ai_context: |
  {{# omni_agent.build }}
  Modeling conventions: Always define primary keys. Use snake_case for field names.
  {{/ omni_agent.build }}

  {{^ omni_agent.build }}
  Keep queries focused and efficient.
  {{/ omni_agent.build }}

{{ omni_agent.name }} は、読み取り対象エージェントの名前に置き換えられます。

定数でブロックを再利用する

constants を一度定義し、モデル、トピック、ビュー、サンプルクエリの ai_context 全体で @{constant_name} を使って参照します。これにより、同じトーン／プライバシー／ドメインに関する段落が十数か所に重複する問題を解消できます。

constants:
  tone:
    value: "Keep responses concise and professional."
  privacy_high:
    value: "Never show individual customer names or emails."

ai_context: |
  @{tone} @{privacy_high}

ai_fields でフィールドをキュレーションする

実際の上限

Omni では、モデルのメタデータがコンテキストウィンドウをどれだけ消費できるかに上限を設けています。プルーニングを引き起こすのは、モデルのコンテキストウィンドウ全体ではなく、次の上限です。

上限	値	超過した場合の動作
トピックのフィールド定義	約 75K 文字	プルーニングの順序に従って、フィールドのプロパティがプルーニングされます
トピック選択の要約（全トピック）	約 100K 文字	最初にビューのメタデータ（ビュー単位の ai_context を含む）が削られ、次にサンプルクエリ、最後の手段としてトピックのメタデータが削られます。トピックが選択されると、削られた詳細が復元されます。
トピック外の検索	1 回の検索につき 100 フィールド	AI はプロパティをプルーニングする代わりに、検索範囲を狭めて繰り返し検索します。query_all_views_and_fields が有効な場合に適用されます。

フィールド数を基準に最適化しないでください。 注釈が簡素なフィールドは約 100 文字ですが、詳細な説明、サンプル値、ai_context を含むフィールドはその数倍の文字数になるため、収まるフィールド数は大きく変わります。推測するのではなく、ワークブックインスペクターで実際に渡されるコンテキストを確認してください。

会話履歴は別途予算が設定されています。詳細はconversation_prune_lengthを参照してください。

キュレーション

サイズを小さくするだけでなく、精度を高めるようにキュレーションしてください。適切に説明されたフィールドを絞り込むことで、AI が誤ったフィールドを選ぶ可能性を減らせます。大規模なモデルでは、ノイズを減らしてください。

ai_fields:
  - all_views.*
  - -tag:internal
  - -distribution_centers.*

# Or explicit list
ai_fields:
  - order_items.created_at
  - order_items.total_revenue
  - order_items.count
  - users.name
  - users.state
  - products.category

トピックの fields と同じ演算子を使用できます。ワイルドカード（*）、否定（-）、タグ（tag:）です。

最もメンテナンスしやすい方法は、タグ付けです。ユーザーが実際に尋ねるフィールドにタグを付け、単一のセレクターでキュレーションします。

ai_fields: [tag:use_for_ai]

ai_chat_topics でトピックの表示範囲を制御する

ai_chat_topics は、Blobby が参照できるトピックを制御するモデルレベルのプロパティです。

• ai_chat_topics プロパティがない場合（デフォルト）— Blobby はすべてのトピックを対象にクエリできます。
• ai_chat_topics: []（空のリスト）— Blobby はどのトピックにもクエリできません。実質的に、そのモデルの AI チャットが無効になります。
• 明示的なリスト — リストされたトピック（またはタグとの一致）のみが利用できます。all_topics、タグセレクター（tag:customer_facing）、否定（-tag:internal、-staging_events）をサポートします。

まずここを確認してください。トピックが ai_chat_topics に含まれていない場合、そのトピックに ai_context や ai_fields をいくら設定しても効果はありません。このプロパティを変更するには、omni-model-builder を使用してください。

sample_queries の追加

例を使って Blobby に学習させます。特に、繰り返し寄せられる質問や、Blobby が間違えやすい日付フィルターのパターンに効果的です。

サポートされている作成方法はワークブックを使う方法です。正しい回答を返すクエリを作成し、Model > Save as sample query to topic を選択します。Include in AI context にチェックを入れ（チェックを入れないとトピックの概要に表示されるだけで、AI には渡されません）、任意の Prompt と AI context フィールドに入力します。

代わりに YAML に直接記述するには、ワークブックで正しいクエリを作成して構造を取得し、それをトピックに追加します。

sample_queries:
  revenue_by_month:
    prompt: "What month has the highest revenue?"
    ai_context: "Use total_revenue grouped by month, sorted descending, limit 1"
    query:
      base_view: order_items
      fields:
        - order_items.created_at[month]
        - order_items.total_revenue
      topic: order_transactions
      limit: 1
      sorts:
        - field: order_items.total_revenue
          desc: true

Note: Omni のワークブックからクエリをエクスポートすると、table、join_paths_from_topic_name、および column_name／sort_descending を使った sorts を含む JSON が出力されます。次のように YAML に対応付けます。

• table → base_view
• join_paths_from_topic_name → topic
• column_name → field、sort_descending → desc
• ワークブックの JSON には filters、pivots、limit、column_limit が含まれており、これらも YAML に含められます（ただし、フィルターの構文については Model YAML API docs を直接参照する必要があります）

ユーザーが実際に尋ねる質問に焦点を当てます。どのような質問か分からない場合は、もっともらしい質問を推測するのではなく、ユーザーに尋ねてください。

AI 固有のトピック拡張

extends を使って、Blobby 用に厳選したトピックのバリエーションを作成します。

# ai_order_transactions.topic
extends: [order_items]
label: AI - Order Transactions

fields:
  - order_items.created_at
  - order_items.status
  - order_items.total_revenue
  - order_items.count
  - users.name
  - users.state
  - products.category

ai_context: |
  Curated view of order data for AI analysis.
  [detailed context here]

拡張されたトピックはベーストピックの結合とフィルターを継承するため、異なる部分だけを追加します。より絞り込んだフィールドセット、追加の ai_context、または sample_queries（上記と同じ形式）です。

フィールドの説明を改善する

値の一覧は all_values に、AI 専用のルールは ai_context に記述します。どちらかを説明文で繰り返すと、同じ情報を二重に記述することになります。

dimensions:
  status:
    label: Order Status
    description: Current fulfillment status of the order.
    all_values: [complete, pending, cancelled, returned]
    ai_context: Use 'complete' for revenue calculations.

カテゴリーフィールドの値を列挙する

選択肢が固定された列挙型には all_values を使い、Blobby が有効なフィルター値をすべて把握できるようにします。

dimensions:
  status:
    all_values: [complete, pending, cancelled, returned]
  payment_method:
    all_values: [credit_card, debit_card, bank_transfer, paypal, gift_card]

すべての値を列挙するのが現実的ではない、選択肢が固定されていないカテゴリーフィールドには、代表例を示す sample_values を使います。

dimensions:
  product_category:
    sample_values: [Electronics, Clothing, Home & Garden, Sports, Books]
  city:
    sample_values: [New York, Los Angeles, Chicago, Houston, Phoenix]

Note: all_values は最初に削除対象となるため、コンテキスト容量が限られたトピックでも残るとは限りません。重要な情報は代わりに ai_context に記述してください。

dbt integration が有効な場合、dbt の accepted_values テストは all_values として自動的に取り込まれます。手動で記述する前に確認してください。

同義語の追加

別名、略語、ドメイン固有の用語を対応付け、Blobby がユーザーのクエリを正しいフィールドに結び付けられるようにします。ディメンションとメジャーの両方で使用できます。

dimensions:
  customer_name:
    synonyms: [client, account, buyer, purchaser]
  order_date:
    synonyms: [purchase date, transaction date, order timestamp]

measures:
  total_revenue:
    synonyms: [sales, income, earnings, gross revenue, top line]
  average_order_value:
    synonyms: [AOV, avg order, basket size]

同義語と ai_context の使い分け：フィールドレベルの名称の対応付けには synonyms を使います。トピックレベルの動作指針、データに関する補足、複数フィールド間の関係には ai_context を使います。

追加するタイミング — ユーザーが実際にモデルに含まれていない語（AOV、top line、basket size）を使う場合、同義語を追加する価値があります。フィールドのラベルや名前を言い換えるだけの場合や、トピックレベルの ai_context ですでに定義されている対応付けを補強する場合には、追加する価値はありません。このスキルで最もよくある無駄な書き込みは、トピック上ですでに曖昧さが解消されているフィールドに同義語を追加することです。Safe Model Write Defaults を参照してください。

削除の優先順位：synonyms は description と label の後、最後に削除されます。そのため、別の語彙が本当に必要なフィールドでは、同義語は最も残りやすい記述場所です。ただし、この残りやすさは、その目的には説明文ではなく同義語を選ぶ理由であり、同義語をさらに追加する理由ではありません。

重複を避ける

ai_context と description は対象とする読者が異なります。description は人向けで、フィールドピッカーやドキュメントに表示されます。ai_context は AI 専用のヒントです。同じテキストを両方に記載しないでください。ai_context には、説明で触れていないガイダンス（曖昧さの解消、注意点、どちらのフィールドを使うかなど）を追加します。

共通のコンテキストはビューのレベルに集約します。 ビュー内の複数のフィールドで同じ ai_context（例：「すべての金額は USD」）を共有している場合は、各フィールドに繰り返し記載するのではなく、ビューのレベルの ai_context に移します。フィールドレベルの ai_context は、そのフィールドに固有の内容にしてください。

共通の事実をビューに集約し、description と ai_context にはそれぞれ相手に含まれていない内容だけを記載します。

ai_context: "All monetary values in this view are in USD."

dimensions:
  gross_revenue:
    ai_context: "Revenue before refunds."
    description: "Total revenue before refunds and cancellations are applied."
  net_revenue:
    ai_context: "Revenue after refunds. Use this for profitability analysis."
    description: "Total revenue after refunds and cancellations."

最適化チェックリスト

影響の大きい変更を優先します。意味を変えずに表現を改善してください。

1. omni-model-explorer で現在の状態を確認します
2. モデルレベルの ai_chat_topics を確認し、適切なトピックが AI に表示されていることを確かめます
3. フィールド数ではなく、ユーザーが実際に尋ねるフィールドに絞って ai_fields を調整します
4. ビジネス用語とフィールドを対応付ける ai_context を記述します（1～2 文に収めます。削除されることはありません）
5. 主要なディメンションとメジャーに synonyms を追加します（ラベルと重複する場合は不要です）
6. フィールドの description と label の値を改善します
7. カテゴリーフィールドに all_values／sample_values を追加します
8. 上位 3～5 件の質問に sample_queries を追加します
9. ai_context と description の重複を取り除き、共通のコンテキストはビューのレベルに、共通のブロックは constants に集約します
10. AI 固有のトピックのバリエーションに extends を検討します
11. ティアまたはエージェント固有の指示は、すべてのリクエストでコストがかからないよう omni_llm／omni_agent でスコープを限定します
12. 反復してテストします。Blobby に質問し、改善を重ねてください

Blobby の回答が間違っている場合のトラブルシューティングの順序：トピックにアクセスできることを確認します（ai_chat_topics）→フィールドがコンテキストに含まれていることを確認します（ワークブックインスペクターで、ai_fields／hidden によって削除または除外されていないかを確認します）→その後で ai_context を追加または強化します。AI に届いていないフィールドのコンテキストを増やしても、何も解決しません。

AI モデルの提案

Omni はモデルの改善案を自動で生成できます（CLI ≥ 1.1.2、omni ai-model-suggestions --help）。以下の手動チェックリストを補完するものとして活用し、適用する前に各提案を確認してください。

# Kick off a generation run, then read it back
omni ai-model-suggestions model-suggestions-generate <modelId>
omni ai-model-suggestions model-suggestions-run-latest <modelId>
omni ai-model-suggestions model-suggestions-run-get <modelId> <runId>

# Work the suggestion list
omni ai-model-suggestions model-suggestions-list <modelId>
omni ai-model-suggestions model-suggestions-ignore <modelId> <suggestionId>
omni ai-model-suggestions model-suggestions-restore <modelId> <suggestionId>
omni ai-model-suggestions model-suggestions-delete <modelId> <suggestionId>

# Recurring generation
omni ai-model-suggestions model-suggestions-schedule-enable <modelId>
omni ai-model-suggestions model-suggestions-schedule-disable <modelId>

エージェントスキル

スキルとは、ユーザーがスラッシュコマンドのハンドル（例：/quarterly-report）を呼び出したときに Omni Agent が読み込む、保存済みの指示セットです。ai_context がトピックに関するすべての回答を形作るのに対し、スキルは繰り返し実行できる 1 つのタスクをまとめます。omni skills で管理します（CLI ≥ 1.3.1。実験的な機能のため、フィールドは変更される可能性があります）。本文には --schema を指定して create／update を実行してください。

omni skills list                                   # bodies omitted
omni skills list --identifier quarterly-report     # filter by handle; exact match, still returns a list
omni skills list --q revenue                       # free-text search (CLI ≥ 1.4.0)
omni skills get <skillId>                          # includes the body
omni skills create --body @skill.json              # name, identifier, description, body
omni skills update <skillId> --body '{ "body": "…" }'
omni skills delete <skillId>

• list の結果は呼び出し元の範囲に限定されます。 組織の管理者には組織内のすべてのスキルが表示されます。それ以外のユーザーに表示されるのは自分のスキルのみで、--creator-id／--q を指定するとその範囲内で絞り込まれます。どちらも範囲を広げるものではありません。管理者以外のキーでリストが空でも、誰のスキルにもハンドルが設定されていない証拠にはなりません。他のユーザーのスキルがハンドルを保持している場合、create は引き続き 409 を返します。
• list は body を返しません。 スキルの指示を読むには、リストではなく get を使用します。
• description をもとに、エージェントはどのスキルを選ぶか判断します。 そのスキルの用途と適用される場面を示す、質の高い ai_context の一文と同じように記述してください。
• delete は論理削除です。スキルはすべての読み取り結果から消え、ハンドルは再利用できるようになります。

ドキュメントリファレンス

• Omni AI 向けにモデルを最適化する
• ai_context リファレンス：モデル · トピック · ビュー
• トピックのパラメーター：ai_fields · sample_queries · extends · すべてのトピックパラメーター
• モデルのパラメーター：ai_chat_topics · constants · sample_queries · query_all_views_and_fields · conversation_prune_length
• 同義語 · ユーザー属性 · ワークブックインスペクター
• モデル YAML API · Omni AI の概要 · AI データセキュリティ

関連スキル

• omni-model-explorer — 既存の AI コンテキストを調べます
• omni-model-builder — ビューとトピックを変更します
• omni-query — クエリをテストして、Blobby の出力を検証します