タグ カテゴリ システム (ビジネス指向のデータ資産設計方法論) - 読書メモ 6

第 6 章 テクニック: テクニックと重要な問題

1. ラベル仕様

データを価値のあるものにするためには、ビジネス上の問題を解決し、ビジネス効率を向上させることができるラベルに変換する必要があります。そうしないと、データの負担が大きくなります。データを調整してラベルに変換するプロセスは「ラベリング」と呼ばれます。ラベリングでは、次の 2 つの主要な要素を十分に考慮する必要があります。

  • データの実現可能性はありますか?また、ラベルに加工できる生のコーラル オレンジはありますか?
  • ビジネス価値を反映できるかどうか、つまり、中核的なビジネス ニーズであるか、ビジネス シナリオを革新できるかどうか。

タグ付けの中核は、データ思考を使用してビジネス シナリオを理解し、抽象化し、洗練し、ビジネス上の問題を解決することです。ラベル付けのプロセスでは、標準的な操作をガイドするためにラベル仕様が必要です。

1.1 ラベル表示

1.1.1 ルート ディレクトリはラベルが属するオブジェクトを指します

ルート ディレクトリは、多くの場合、曖昧で広義の単純な名詞または動名詞です。データの物理レベルでは、多くの場合、データは大きな幅のテーブルの主キーにマッピングされます。この大きな幅のテーブルの情報は、主キー オブジェクトの詳細な説明とデータ レコードです。大きな幅のテーブルの列はマッピングされます。レコードは、各タグ属性上の特定のオブジェクトの特定の属性値レコードに対応します。

1.1.2 カテゴリはラベルの分類です

カテゴリは多くの場合名詞で構成されます。カテゴリとそれに関連付けられたタグは、データの物理レベルで特定のテーブルに対応できます。主キーは同じだが情報タイプが異なる複数のデータ テーブルを関連付けて、主キー オブジェクトの下に大きなテーブルを形成できます。

1.1.3 ラベルはオブジェクトの属性であり、フィールドレベルまで細分化されています。

タグは通常、データベースのデータ テーブルのフィールドに対応します。

1.1.4 タグ値はオブジェクト属性の特定の値です

タグ値は通常、データベースのデータ テーブルのフィールドの値に対応します。

1.2 メタタグ

タグのタグはメタタグと呼ばれます。メタ タグはタグ オブジェクトの属性説明であり、フロントエンド ビジネスがタグをよりよく理解できるようにビジネス用語を使用するように設計されています。

1.2.1 ラベルが属するルートディレクトリ

ラベルが属するルートディレクトリとは、そのラベルがどのオブジェクトのラベルであるかを指します。

1.2.2 ラベルが属するカテゴリ

タグが属するカテゴリとは、上述したタグが属する第1階層ディレクトリ、第2階層ディレクトリ、三極ディレクトリ等である。

1.2.3 タグ名

タグの命名は、プライバシーを侵害する誤解を避ける、同じタグには同じタグ名を使用する、類似したタグには類似した文構造を使用するという 3 つの主要な原則に従う必要があります。ラベルネーミングの基本仕様は以下のとおりです。

(1) フォーマット指定

同じタグは同じタグ名にグループ化し、類似したタグは同じ文構造を使用する必要があります。

(2) 語句の使用の指定

  • 「ID カード」、「軌跡」、「測位」、「追跡」、「GPS」、「ユーザーの習慣」、「意図」、「軽微」などの言葉は使用しないことをお勧めします。簡単に不必要な注目や調査を集めてしまいます。
  • アルゴリズム モデルによって生成されるラベルの場合、「家があるかどうかを予測する」など、ラベル名の前に「予測」という単語を追加することをお勧めします。
  • 「田舎者」「男勝り」などの差別用語は使用しないでください。
  • ユーザーの趣味や意図を表すタグは、「ブランドの好みを予測する」などの「好み」で終わる必要があります。
  • 「習慣」は、「習慣」などの行動習慣タグの動詞として単独で使用できます。

(3) コンテンツ仕様

  • 未成年者に関するデータはタグのデータ計算内容に含めるべきではありません
  • タグ データは合法的に取得するか、合法的に使用が許可されている必要があり、違法またはグレーなデータ情報をタグの処理に使用してはなりません。

1.2.4 ラベルの説明

タグ名に含まれる単語が短すぎることによって引き起こされるあいまいさ、あいまいさ、多義性などの問題を避けるために、タグ名を説明するには 1 つまたは 2 つの文を使用します。

1.2.5 ラベル処理の種類

タグは、処理の種類に応じて独自タグ、統計タグ、アルゴリズムタグに分類できます。

(1) 3種類の加工ラベルの定義

  • 元のクラス タグ: 元のデータ テーブルに存在するフィールドは、単純な正規化の後、ビジネス担当者によって使用され、タグになります。
  • 統計タグ: 生データは、合計、平均、正規表現、ルール演算、その他の単純な数学関数演算などの ETL を通じて処理されます。
  • アルゴリズムタグ:パターン認識や深層学習などのアルゴリズムモデル演算後に得られる総合スコアや予測指標など、元のデータに対してアルゴリズムモデルによって計算された深層処理タグ。

(2) 3種類の処理ラベルと属性分類ラベルの関係

  • オリジナルタグは、会員が登録した性別、年齢、名前、携帯電話番号などの基本的な属性タグであることが多い。基本属性は、ある種のオブジェクトの属性、特性、情報を直接記述したもので、重要な情報項目を簡単なクリーニングやデータクリッピングなどでオリジナルのクラスラベルに変換できる万王雷子基本情報テーブルを作成することができます。ビジネス関係者が使用します。
  • 統計タグは、過去 1 か月の合計取引額などの行動タグであることが多く、元の取引記録、収集記録、閲覧記録の ETL 開発を通じて取得されることがよくあります。行動データの詳細な記録が多すぎるため、通常、ビジネス担当者が使用する統計ラベルを取得するには、データを要約して作成する必要があります。
統計複合タグの設計は、アトミックタグをベースに、ある種の属性を詳細に記述または拡張するための次元情報を追加する、つまり[シナリオ] + [時空変更] + の設計テンプレートを参照できます。 [計算方法]+[修飾語]]などの情報を修飾子として組み合わせたものです。
A.  [シナリオ] は、電子商取引、オフライン トランザクションなど、特定の行動シナリオを指すことがよくあります。
B.  [時空間変更] とは、原子ラベルを特定の時間緯度および特定の空間次元に縮小した統計を指します。時間変更には、過去 1 日、過去 7 日間などが含まれます。空間的な変更には、中国東部エリア、浙江エリア、杭州エリア、モバイル端末など、さまざまな地域区分やチャネル タイプが含まれます。
C.  [計算方法] は、さまざまな統計計算方法を指します。一般的な方法には、合計、平均、最大値などが含まれます。
D. 【修飾語】はシーンと密接に関係していることが多く、例えば「電子商取引」のシーンであれば、「電化製品」や「衣料品」などにカテゴリが分けられます。顧客のタイプに応じて、「VIP顧客」、「新規顧客」などに分けることができます。
上記の要素を組み合わせると、過去 1 か月のモバイル電子製品の合計取引額などの統計タグを生成できます。
  • アルゴリズム タグは、多くの場合、興味や趣味、性格の考え方、価値評価などの高レベルの抽象タグに対応します。これらの高度な抽象ラベルの具体的な値を簡単に確認・判断する方法がないため、アルゴリズムによる大量の基礎情報や行動情報をもとにディープラーニングやビッグデータのインテリジェントな判断を行う必要があります。モデリング。元のデータは、データ マイニングや機械学習などのアルゴリズム テクノロジーを使用して、高度な機能を予測および評価します。

(3) 3種類の処理ラベルと人・物・関係下の各種ラベルとのつながり

  • 「人間」オブジェクトの基本的な属性ラベルは原始的なラベルであることが多く、行動関係ラベルは統計的なラベルであることが多く、興味、習慣、思考のラベルはアルゴリズム ラベルに対応することがよくあります。
  • 「物」オブジェクトの基本属性、機能的有用性、およびマスター/スレーブ属性タグは、多くの場合、独自のクラス タグです。受動的動作のクラス タグは、通常、統計的なクラス タグです。値評価のクラス タグは、通常、アルゴリズム クラス タグです。
  • 「関係」オブジェクトの人物クラスタグは、関連する人物や関連する物を一意に識別するために使用される独自のクラスタグであるID基本属性クラスタグを指す場合が多く、関係作成クラスタグや関係プロセスクラスタグは統計クラスタグに相当する場合が多い。クラス タグ; 関係結果のクラス タグ 対応するアルゴリズム評価クラス ラベル。

1.2.6 タグロジック

タグロジックとは、タグの開発方法や処理プロセス、計算ロジックなどを記述したものを指します。

  • 元のクラス タグ: ロジックは通常、単純なクリーニング後にテーブル a の m フィールドを直接使用して表現されます。
  • 統計タグ: ロジックは、履歴の蓄積/過去 N 日間/過去 N か月/最新の XX 行動の発生頻度/頻繁に投稿された時間/頻繁に投稿された場​​所/数量統計/回数統計/金額統計などであることがよくあります。
  • アルゴリズム タグ: 通常、ロジックは明確に定義する必要があり、アルゴリズム モデルの処理、ポジティブおよびネガティブ サンプルの定義または学習サンプル ロジック、モデルの選択とモデル構造、モデルの出力結果フォームとしきい値セグメンテーション設定に含める必要がある重要な機能が必要です。 、希望機種 予想業績指標等

1.2.7 値ラベル

値ディクショナリは、タグのさまざまな可能な値の列挙です。

1.2.8 値の型

値の型は、タグ値のデータ型です。

1.2.9 例

タグ値の例を 1 ~ 2 つ挙げます。主に、網羅的に列挙できない連続数値タグや、数百、数千の列挙項目を持つタグに使用されます。開発者やビジネス担当者がタグの定義をよりよく理解できるようにします。

1.2.10 更新サイクル

更新サイクルとは、一般的にインジケーターのデータ更新サイクルを指します。

  • 元のクラス ラベル: ラベル値が変更される可能性は低く、更新サイクルが長くなる可能性があります。
  • 統計ラベルの場合、元のデータを 1 日ごと、7 日ごと、毎月などに更新して、このラベルの更新サイクルを設計できます。
  • アルゴリズム ラベル: アルゴリズム モデルは、多くの場合、反復的に最適化されるように設計されているため、四半期または半年ごとに更新されます。更新サイクルは、元のクラス ラベルと統計クラス ラベルの間になります。

1.2.11 セキュリティレベル

1 ~ 4 レベル (L1 ~ L4) のセキュリティ評価を構築することをお勧めします。

  • L1: 外部に公開できるパブリック ラベル。最もオープンなデータ ラベルであり、セキュリティ レベルは最も低くなります。
  • L2: 内部タグは、企業/機関内の部門間で直接回覧、申請、使用できるデータ タグであり、セキュリティ レベルは低いです。
  • L3: 社外秘ラベル、社内で部門を越えて使用する場合は承認が必要で、承認後にのみ使用できるラベルで、セキュリティレベルがより高くなります。
  • L4: 機密ラベル。企業/機関内の少数の人材のみが使用でき、配布できないラベルであり、最高のセキュリティ レベルです。

各企業/機関は、それぞれの実情に応じて、L1 ~ L4 レベルのタグに対して異なるアプリケーション、操作、および使用権限を設定できます。

1.2.12 ラベルに対応する物理ストレージ情報

データ サービスを作成するときは、実際のデータ フローの基礎となる物理テーブルにタグをマッピングする必要があります。各ラベルにマップされた物理テーブル名とフィールド名を登録すると、ラベルで問題を発見したりガバナンスを最適化する必要があるときに、対応する物理パスと実際の開発ロジックをすぐに見つけられるようになります。

1.2.13 ラベル担当者

ラベルについて疑問を持った業務担当者が、追跡する際に該当者をすぐに見つけて回答を得ることができるよう、ラベルの責任者リストを登録する必要があります。

1.2.14 完了時間

完了時刻は、タグの最新の論理確認開発が完了した時刻、またはアルゴリズム タイプ タグの最後の安定したモデリング実行のバージョン時刻を指します。

2. 組み合わせタグ

組み合わせタグは、組み合わせの複雑さに応じて 2 つのレベルに分類できます。

2.1 同一オブジェクト内のタグの組み合わせ

単一タグの値処理と複数のタグの値処理が含まれます。処理方法には、正規表現、算術演算子、データ関数などのさまざまな統計演算の使用が含まれます。

2.2 異なるオブジェクト間のラベルの組み合わせ

2.2.1 オブジェクト間のラベルの組み合わせの設計手順

  • ビジネス要件内のオブジェクトを特定する
  • 複数のオブジェクトを含む、条件に関連する「オブジェクト」タグを設計します。
  • ラベルを細部まで分割する
  • 基本タグを複合タグとして設定します。

2.2.2 オブジェクト間のラベルの組み合わせを設計する際の 3 つの注意点

(1) ラベルとデータの結果は異なることに常に注意してください

タグは基本的で再利用可能なデータ資産であり、一般的なビジネスのデータ結果要件は実際にはデータ サービスの要件です。データ サービスは、多くの場合、関連するタグとタグの処理プロセスで構成されます。

(2) 2 つのオブジェクトの関係ラベルを見つけることが非常に重要です

オブジェクトのスパンを実現するには、関連付けられたラベルを介して 2 つのオブジェクトのラベルを 1 つのラベルに結合する必要があります。

(3) ラベルのデザイン工程とラベルの使用工程が逆の工程

複雑なデータ アプリケーション シナリオでは、ラベル設計プロセスは逆方向に作業してビジネス要件の結果を基本タグに分解しますが、タグ使用プロセスは最初の基本タグ操作からビジネス要件結果の出力までです。

3. タグの使い方

3.1 プラットフォームレベルの再利用とは何ですか?

データセンターの本質は、再利用性を高め、ビジネスの試行錯誤コストを削減し、ビジネス担当者の自発性と熱意を最大限に引き出すことです。システム再利用レベルには 4 つのレベルがあります。

  • 最も基本的な [コードレベルの再利用]: 既存のコードの再利用可能な部分を見つけて変更し、再利用します。この種の再利用は最も浅く、コードの移行や使用上のエラーなどの問題が発生します。
  • 第 2 レベル [コンポーネントレベルの再利用]: 特定の機能のニーズを満たす共通コードが要約されてコンポーネントにカプセル化され、このコンポーネントの使用が再利用可能になります。テクニカルミドルウェアは、コンポーネントレベルの再利用としてカウントできます。
  • 第 3 レベル [製品レベルの再利用]: 一部の製品は汎用性と幅広い適用性を備えており、パッケージ化が完了した後、アダプター インターフェイスが残され、製品全体の再利用が実現されます。
  • 最高レベルの[プラットフォームレベルの再利用]: さまざまなコンポーネントや製品などが完全にエコロジカルチェーンの形で存在しており、このプラットフォームでは、システム開発者が必要なビルディングブロックモジュール(再利用可能なユニット)をブロックを構築することで選択でき、素早く組み立てることができます。最終的な技術システムに組み込まれます。

3.2 プラットフォームレベルで再利用するためのタグの使用方法

3.2.1 ラベルの自由な選択

タグはデータ資産レベルの概念であり、データ情報の最小単位であり、データをタグでカプセル化した後は、毎回タグポータル/タグマートで必要なタグを選択するだけで利用・設定が可能です。必要ありません 毎回、テーブルの検索、読み取り、データ テーブルを取得するためのコードの書き込みなどの操作が実行されます。

3.2.2 ラベル構成

サービス コンポーネントには次の 2 つの特徴があります。

  • コンポーネント ツール自体にはデータが含まれていないため、ラベル データ テーブルを自動的に同期するか、最初のステップでのラベル選択を通じてこれらの製品にアクティブにインポートする必要があります。
  • ビジュアルインターフェイスを通じてさまざまな操作を設定およびドラッグでき、基本的にゼロコードまたはローコード開発を実現します。

上記の 2 つのステップ (タグの自由な選択とサービス コンポーネントのゼロコード構成) を通じて、プラットフォーム レベルの再利用を通じてデータ サービス/データ アプリケーション システムの開発を完了できます。このタグの使用方法により、ビジネス側が強化され、タグの使用効率が大幅に向上し、タグの品質が完全に最適化され、データエンドとビジネスエンドの間に価値のあるつながりが確立されます。

3.3 サービス コンポーネント、データ サービス、データ アプリケーション システムとは何ですか?

企業による大規模なデータ使用では、データの価値を最大化し、データ サービスの安定性を確保するために、タグをサービス コンポーネントと組み合わせて使用​​する必要があります。

3.3.1 サービスコンポーネント

サービス コンポーネントは、特定のデータ関数の設計されたカプセル化です。通常、データ タグのインポートまたは関連付け、サービス関数の設定などの操作を実装するための対話型インターフェイスを提供します。出力方法は 2 つあります。

  • API の形式でデータ サービスを生成します。これは、複雑なシステムとのドッキング、またはインターフェイスとシステムのカスタマイズ要件が高い場合に適しています。
  • 生成されたデータ アプリケーション システムには、ビジネス パーティがエンドツーエンドで直接使用できるシンプルで明確な対話型インターフェイスが直接付属しています。

3.3.2 データサービス

データ サービスとは、Tonggu API がビジネス システム コールのニーズを満たす特定のデータ関数を提供することを意味します。

  • 柔軟に使用できるため、複数のデータ サービス API を 1 つのデータ アプリケーション システムに組み合わせることができます。
  • 表示は柔軟であり、API をさまざまなビジュアル コンポーネントに接続して、ビジネス側の対話の固有のニーズを満たすことができます。

3.3.3 データの適用

データ アプリケーションとは、データ機能と対話型インターフェイスの組み合わせをビジネス側に提供することを指し、これはデータ アプリケーションの結果を体系的に提示するものです。

4. ラベルの操作方法

4.1 タグの完全なライフサイクル操作

4.1.1 ラベルデザイン

データ資産設計者は、ビジネス調査、データ調査、その他の準備作業に基づいてラベル設計作業を実行し、ラベル オブジェクト、カテゴリ システム、ラベル名、ラベル処理タイプ、ラベル ロジック、およびラベル オブジェクトを含むラベル カテゴリ システム アーキテクチャ図とラベル設計ドキュメントを作成します。 value フィールド、値の型、例、更新サイクルなどのメタタグ情報。

4.1.2 タグの開発

ラベルのデザインが完了すると、ラベルは処理の種類ごとに分類され、データ開発エンジニアとアルゴリズムエンジニアに提出され、各種ラベルの開発が行われます。オリジナルラベルと統計ラベルはデータ開発エンジニアによって完成され、アルゴリズムラベルはアルゴリズムエンジニアによって完成されます。ラベル開発完了後、データ開発エンジニアは、テーブル名、フィールド名、担当者、完了時刻など、完成したラベルの物理ストレージ情報を記録し、ラベルからデータへのマッピングを完了します。層。

4.1.3 ラベルリスト

タグが開発され、完全なメタ タグ情報が追加された後、タグをタグ管理システムにリストする必要があります。ラベルを棚に置いた後、ラベルを開き、あらゆる末端のビジネス担当者に表示して、ラベル ポータルを通じて閲覧、参照、使用することができます。このプロセス中に、システムはタグのセキュリティ レベル、部門の役割、その他の情報に基づいて、さまざまなアカウントのデータ表示とアプリケーションの権限を決定します。権限には、表示されるタグ セットの範囲、タグの詳細の範囲、適用可能なタグ セットの範囲などが含まれます。

4.1.4 ラベルの使用法

タグはビジネスで使用される場合にのみ価値があります。タグを使用するには次の 3 つの方法があります。

  • データ同期: 処理されたラベル データをビジネス システムのデータベースに直接同期することを指し、通常、この方法で使用するのは中核企業のみです。
  • データ アプリケーション: 外部使用のためにタグ機能を製品インタラクション フォームにカプセル化することを指し、スキルはタグ呼び出しステータスを追跡し、タグ使用の効果を評価します。この手法はビジネス側と深く結びついており、ビジネス担当者の使用習慣の違いやビジネス構築要件の多さから、汎用製品では多くのビジネスフロントエンドの個別ニーズを満たすことが難しく、拡張性も限られています。
  • データサービス: タグの使用は業務システムに接続するための API 形式に急速に成長しており、ビジネス担当者はタグを柔軟に使用でき、タグデータを直接コピーでき、通話状態の追跡と監視が容易です。データ サービスはタグを使用する理想的な方法であり、タグの広範な価値を最もよく反映し、活用することができます。タグの使用中は、安定性、セキュリティ、コンプライアンスを監査するためにタグの呼び出しステータスを監視する必要があります。

4.1.5 タグガバナンス

  • リネージ情報: タグ作成のパスはリネージであり、歴史的事実に基づいて各タグのソース、処理プロセス、アプリケーションのドッキング ステータスなどが記録されます。
  • メタタグの仕様:各タグにはビジネスおよび技術的なメタタグ情報を登録する必要があり、メタタグ管理では統一的な情報登録とタグの検査を行うための統一的な規範システムを形成する必要があります。
  • 品質管理: ラベルの品質管理は、ラベルのデザインから使用、アーカイブまでの全プロセスを実行する必要があり、その中心となるのは、一連のラベル指示管理ルールを策定し、ラベルの品質基準に準拠し、視覚的なラベル品質監視プラットフォームを装備することです。ラベル相互検証ツールなどのテクニカル サポート。
  • 安全管理:「横3本、縦3本」ラベルの安全保証体制。「3 つの垂直分野」とは、セキュリティの概念と全体的な戦略を指します。第 1 に、タグの使用は国のビッグデータ関連のポリシーと規制に準拠する必要があります。第 2 に、すべての顧客のすべてのデータ資産のセキュリティが保証されなければなりません。最後に、特定の使用プロセス、タグの感度登録を評価し、対応するセキュリティ管理戦略とセキュリティ実装計画を策定する必要があります。「3 つの水平」とは、コア ソリューションの導入を指します。1 つ目は三重暗号化メカニズム、2 つ目は不可視タグ セキュリティ システム、3 つ目はすべての ID から生成されるコア ID です。

4.1.6 ラベルマーケティング

ラベル開発完了後は、事業部門担当者がさまざまなラベル情報をできるだけ早く理解できるよう、ラベルの価値を整理し、対外的に広報・宣伝する必要があります。

企業はタグの価値の実現に重点を置き、タグのライフサイクル全体を継続的に運用する必要があります。価値主導のリバースタグ管理の最適化を通じて、タグの使用パフォーマンスは安定し、タグは棚で共有され、タグの開発効率は向上し、新しいタグは最終的にデータ資産の価値の持続的かつ安定した成長を達成できるのは、拡張やその他のリンクの目標を通じてのみです。

4.2 ラベル操作リンクの責任単位

  • 企業がタグ カテゴリ システムを構築する初期段階で、企業レベルで統一タグを構築する必要がある場合は、データ部門がタグの設計、開発、管理、運用を統一することをお勧めします。
  • 各事業部門が一定の深さのデータ思考を形成し、ラベル構築方法を習得した後、ラベルデザインとラベル開発の権限を事業部門、つまり事業部門のデータチームに開放することができます。
  • 各事業者がデザインしたラベルは開発後、自社の事業部のみが使用できるプライベートラベルとして店頭に並べることができます。
  • エンタープライズデータ部門と各ビジネス部門は、独自のタグの公開度を設定できます。レベル 01 は公開されており、他部門が使用する場合に部門によるレビューは必要ありません。レベル 02 は公開されていますが、レビューが必要です。他の部門が使用する場合はその部門が使用する; レベル 03 レベル 04 は対象を絞っておりオープンであり、対象の部門が使用する場合はこの部門によるレビューは必要ありません; レベル 04 は対象を絞っておりオープンですが、次の場合はこの部門によるレビューは必要ありません対象となる部門によって使用されます。
  • ラベル運用チームは、ラベルの命名が標準化されているか、ラベルが一般公開に適しているか、ラベル情報が完全であるかなどをレビューし、統一された監視背景またはフィードバックメカニズムを通じてラベルの品質を判断し、ガバナンスに関する決定を下す必要があります。最適化、運営方法の採用と価値指向であり、レーベルのライフサイクル全体の安定した発展を実現し、企業の強力な参加による運営エコシステムを形成します。

4.3 タグの閉ループ動作

  • 最初のリングは、デザイン開発とレーベルの立ち上げを含むデザインリングです。このリンクでは、データ資産設計者は、現在のビジネス シナリオで誰が必要とされるかを示すラベルを開発するだけでなく、将来起こり得るシナリオに向けて意図的かつ将来を見据えたラベルを設計します。
  • 2 番目のリングは、ラベルの選択、アプリケーション、呼び出しなどの使用リングです。第一段階のラベルデザイン・開発を通じて、ビジネスパーソンが適切なラベルを一元的に選択・申請できるとともに、実際のニーズに基づいた新たなラベルの提案をサポートします。
  • 3つ目は管理リンクで、タグの基本情報の登録、使用状況の評価、使用効果を高めるためのタグの最適化などが含まれます。

5. ラベル品質の見方

ラベルの品質は、データ ソース、ラベル処理プロセス、ラベル使用プロセスの 3 つの主要な側面から評価できます。

5.1 データソースの関連指標

  • データ ソースのセキュリティ: データ ソースのセキュリティ レベル、データ ソースが合法的に取得されたかどうか、ユーザーによって承認されているかどうかなどは、タグのデータ セキュリティに間接的に影響します。
  • データ ソースの精度: データ ソースの精度は、オンサイトで取得されるか、間接的に取得されるか、エッジ計算で取得されるかに関係なく、ラベルの最終的な精度に関係します。
  • データ ソースの安定性: データ ソース データ生成の安定性。生成期間の安定性、生成期間の安定性、生成されるデータ量の安定性、生成されるデータ形式の安定性、生成されるデータの安定性を含みます。価値観など
  • データ ソースの適時性: データ ソース データが最初のサイトで生成されてから、送信および入力されるまでの時間間隔。行動データの適時性は、ラベルの精度に間接的に影響します。
  • データ ソースの包括性: データ ソース データが包括的かどうか、およびグローバルな計算を実行するためにすべてのレベルのデータを統合して公開できるかどうか。

5.2 ラベル付けプロセスに関連する指標

  • ラベル テストの精度: モデリングおよびテストのプロセス中に取得されたラベルの精度は、参考のために、実験の性質と同様の初期精度です。
  • ラベル出力の安定性: 毎日のラベルの計算、処理、出力時間の安定性、およびラベルを予定どおりに作成できるかどうかも、ビジネス担当者がラベルを使用する際に考慮する重要な指標です。
  • タグ生成の適時性: タグ生成間の時間間隔。時間間隔が短いほど、適時性が高くなります。リアルタイム クラス ラベルでは適時性が特に重要です。
  • タグ値カバレッジ: 特定のタグに対して有効なタグ値を持つ個々のオブジェクトの数。個々の被験者のデータの完成度は異なり、同じラベルが異なる被験者グループをカバーする可能性があります。
  • タグの完全性:タグには多くのメタタグ情報、つまりタグの「タグ」が含まれており、このメタタグ情報の完全性がビジネス利用におけるユーザビリティの指標となります。
  • タグの規範性: 既存のタグのメタデータ情報がどの程度準拠しているかなど、タグのメタタグ情報を標準化された形式で登録する必要があります。
  • ラベル値の分散: ラベル値が特定の数値範囲または少数の値に集中しているか、または相対的に分散しているか。分散には絶対的な良し悪しがあるわけではなく、一般的なシナリオでは分散が高いほど良い、つまり特性値の異なるさまざまなグループが見つかることを意味します。

5.3 ラベル使用プロセスに関連する指標

  • タグ使用の精度: タグ使用プロセス中に、ビジネス シナリオの検証とフィードバックを通じて得られるタグの精度は、より現実的な精度の判断となります。
  • タグのコール量: ラベルの 1 日の平均コール量、今日の現在の累積コール量、過去の累積コール量、および過去のコール量ピークのすべてを参照でき、企業がラベルにコールした回数を反映します。
  • タグの対象ユーザーの人気度: タグを申請する事業部門、ビジネス シナリオ、およびビジネス担当者の数。これは、タグの適用性と一般化能力を反映している可能性があります。
  • タグ呼び出しの成功率: 特定のタグの実際の使用シナリオにおける、呼び出しの合計数に対する成功した呼び出しの数 (履歴呼び出しの合計数 - 失敗した呼び出しの数) の比率。
  • タグ障害率: 実際の使用シナリオにおけるタグの合計サービス時間に対する累積障害時間の割合。
  • タグ注目度:検索、閲覧、コレクション、相談、ディスカッションなどのタグポータルにおけるタグの人気度を総合的に計算して算出した人気度。
  • ラベルの継続的な最適化の度合い: ラベルが開発者によって繰り返し最適化され続けているか、まだ一次開発段階にあるかは、ラベルが繰り返し改良され、継続的に最適化されてきた度合いを反映します。
  • タグの継続的な使用: タグが企業での使用に適用された後、平均通話時間、頻度、プロモーション ステータスは、タグが本当に企業に価値をもたらすかどうかを反映します。
  • ラベルのコスト/パフォーマンス比: ラベル処理プロセス中に発生するデータ ソース コスト、コンピューティング コスト、ストレージ コストと、それがビジネスにもたらす価値、通話量、アプリケーションの重要性など、およびその結果として得られるコスト/パフォーマンスを総合的に計算します。インデックスは、コストと価値のバランスパラメータを包括的に表示します。

6. ラベルコストの見方

6.1 タグデータソースの収集と保管のコスト

6.1.1 情報構築

情報化構築の結果、タグ開発に必要なソースデータの保管コストがタグ収集・保管コストの源泉の一つとなっています。

6.1.2 データ埋め込みポイント

データ埋め込みは、オンラインのシステムデータを取得する方法です。データ埋め込みによって得られたログデータには価値の低い情報が多く含まれているため、真に価値のあるデータを見つけるためには、アルゴリズム技術を使用してこれらの行動データをモデル化およびマイニングする必要があります。タグのニーズに応じてデータを埋め込むための技術投資コストと、埋め込まれたデータのストレージ コストが、タグの収集とストレージのコストの 2 つの原因となります。

6.1.3 データ補足記録

基幹情報システム外の一部のオフラインデータ情報については、システムに記録しないことや、既存システムの情報を補完することにより補完することができる。タグの収集および保管コストの 3 つの原因は、タグのニーズに応じた補足データ記録の技術投資コストと補足データの保管コストです。

6.1.4 データ クローラー

クローラー技術により、企業は自社の業務、業務、知識を超えた情報をクローリングし、社会の知恵を最大限に活用することができます。タグのニーズに基づくデータ クローリングへの技術的投資と、クローラ データ ストレージのコストが、タグの収集とストレージのコストの 4 つの原因となります。

6.1.5 データの取得

タグのニーズに基づくデータ取得の資本コストと、取得したデータの保管コストが、タグの収集および保管コストの 5 つの原因となります。

6.1.6 データ連携

共有されるデータは統計結果データであることが多く、企業は詳細なデータ記録を入手できず、一部の情報の補足としてしか利用できません。タグのニーズに応じたデータ連携の投資コストと連携データの保管コストが、タグの収集と保管の6つのソースとなります。

6.2 ラベルのデザインと加工コスト

ラベル デザイン リンクには、データ調査、業界ビジネス シナリオ調査、ラベル カテゴリ システムおよび特定のラベル デザインなどが含まれます。これらのプロセスで発生するコストは基本的に人件費です。ラベル処理リンクには、データ同期、データ クリーニング、データ開発、およびデータが含まれます。ガバナンス 他のサブリンクでは、人件費、技術投資コスト、データの計算と保管のコストが発生します。

6.3 ラベルの使用とマーケティングのコスト

タグの使用にかかるコストには、主にコンピューティングリソースの消費コスト、人件費、タグ情報システムの開発と運用保守コストが含まれます。このうち比較的大きな部分は、タグの使用中に消費されるコンピューティング リソースのコストです。コンピューティング エンジンが異なれば、消費するデータ ストレージとコンピューティング コストも異なります。一般に、シーンが複雑になればなるほど、パフォーマンス要件も高くなり、必要なコンピューティング エンジンのコストも高くなります。

各ラベルやラベルサービスのコストは、収集、保管、デザインと加工、使用とマーケティングなどのコストを整理し、それらを追跡して各ラベルに配分することで計算できます。これは、ラベルおよびラベル付けサービスの商用運営にとって非常に重要です。

7. ラベルの価値は何ですか?

7.1 ラベル値の分類

7.1.1 企業の内部運営および管理の最適化

データ分析や監視、早期警告などのデータ アプリケーションでタグを使用すると、事業者はビジネス プロセス内のコア リンクのステータスをより適切に分析し、異常なアラームが発生しているかどうかを判断し、できるだけ早く対処することができます。

7.1.2 企業の外部データ サービスの強化

タグは対応するデータ エンジンと連携してデータ サービス インターフェイスやデータ アプリケーションを生成し、企業はこれらのデータ サービスやデータ アプリケーションを新しいタイプのデータ サービスとして外部に提供します。このデータビジネスは企業に事業収入をもたらします。

7.1.3 準拠したデータ取引業界

データトランザクションプロセスでは、データのコンプライアンス、セキュリティ、公平性を確保することが最優先事項です。タグサービスの利用者がタグの使用料を支払うという新たな仕組みを検討できれば、プラットフォームが計測するサービス利用料からタグの価値が算出され、最終的にはリバーストレーサビリティが実現できる。

7.1.4 人々の生活に利益をもたらす社会的価値

企業に加えて、政府、機関などもデータ資産の強化を必要としています。多くの都市で建設されているデジタル頭脳とスマートシティはすべてビッグデータサポートモジュールに属しています。政府や機関などは、大量のデータを通じて現状を合理的に評価し、開発傾向やリスクを予測および警告し、全体的な計画を立てることができます。

7.2 ラベル値の測定方法

7.2.1 収入アプローチ

内部ビジネス管理と外部データ ビジネスの強化のプロセスでは、収入法を使用してラベル サービスの価値を測定できます。社内でコスト支出がどれだけ削減されたか、社外で事業収入がどれだけ増加したか、そしてこれらのメリットの金銭的定量化はすべて、ラベル付けサービスが企業にもたらす具体的な価値であると考えられます。

7.2.2 市場アプローチ

準拠したデータ取引業界では、タグ サービスは特定の制作プロバイダーによって見積もられ、消費者は実際のニーズに基づいて反対オファーを出したり、他のタグ サービスをより安い価格で購入したりします。

7.2.3 原価法

一般に公開されているデータ サービスについて、政府、機関、企業は設計、構築、継続的な運用に累計でどれくらいの金額を投資していますか? データ構築コストへの継続的な投資は、ラベリングの価値の尺度として使用できます。サービス。

8. ラベル手法とデータ ウェアハウス モデリングの類似点と相違点

タグ手法とデータ ウェアハウス モデリングはどちらも、データ資産を洗練、運用、処理する方法を検討します。どちらもデータ資産構築手法です。ただし、タグ手法では、企業のグローバル データとビジネスの並べ替え、分類、および分類により重点が置かれています。指向のデータ資産レプリケーション。データ ウェアハウス モデリングは、データ ガバナンス、データ仕様、ドメイン モデリングに重点を置いています。ドメイン モデリングを通じて、特定のビジネス シナリオにおける既存データのスライスを確認して、現在のデータの問題を解決できます。

おすすめ

転載: blog.csdn.net/baidu_38792549/article/details/126664279