評価 dataset 変更・継承の履歴／ownership／出典・来歴 条件・契約

評価データセットは「固定されたCSV」ではなく、どの原資料から、誰の責任で、どの変換・選別・注釈・承認を経て、どの評価runに使われたかを再現できる統制資産として扱う必要があります。評価結果だけを保存しても、datasetの版・由来・加工履歴・ownerが追えなければ、後から数値の差がモデル差なのかdataset差なのかを切り分けられません。

W3C PROV-Oはprovenanceを Entity / Activity / Agent を中心に表し、used、wasGeneratedBy、wasDerivedFrom、wasAssociatedWith、wasAttributedTo などで、データ、処理、責任主体の関係を記述できます。評価dataset lineageでは、dataset/versionや個別caseをEntity、抽出・変換・注釈・adjudication・split生成をActivity、作成者・承認者・運用主体をAgentとして対応付ける設計が可能です。ただしPROV-Oは汎用provenance ontologyであり、評価データの同意・利用許諾・削除義務・PII分類などを自動的に満たす規格ではありません。

MLflowの現行Dataset Trackingはdatasetのname、digest、source、schema、profileを追跡し、runへdataset inputを記録できます。training / validation / testを別contextとして記録でき、evaluation workflowにもDataset情報を接続できます。これは「どのdatasetをどのrunが使ったか」の実装例として有用ですが、digestだけで法的権利、case単位のauthor/approver、annotation provenance、削除伝播まで証明できるわけではありません。

OpenLineageはDatasetとJob/Runを軸にlineage eventを表現し、dataset version、schema、lifecycle state、ownership、dataset/field lineage等のfacetを持ちます。現行仕様のLineage Dataset Facetは入力dataset/jobとfield-level dependencyを記録でき、Ownership Dataset Facetはownerとtypeを記録できます。これも汎用lineage transportであり、eval-specificなrubric version、case approval、consent basis等は追加metadataとして設計する必要があります。

評価datasetにlineage contractがないと、同名datasetの中身が変わっても評価結果が同じ系列として比較される、annotation rubric改訂後のcaseが旧版へ混入する、削除要求を受けたsource由来caseを逆引きできない、第三者データの利用条件が不明なまま再配布する、評価runから使用datasetを再構成できない、といったfailureが起こります。

一方、lineageを細かく記録すれば自動的に品質が上がるわけでもありません。誤ったsource URI、再現不能な変換、owner名だけの形骸化、hash対象範囲の不一致、case-level lineage欠落があれば「記録がある」だけで追跡可能性は成立しません。provenance graphの存在と、証拠としての完全性・正確性は分けて監査します。

最低限、dataset versionごとに dataset_id / version_id / content_digest / source_locator / created_at / owner / approver / license_or_usage_basis / retention_or_deletion_state / transformation_recipe / parent_version / rubric_version / split_definition を保持します。評価case単位では case_id / source_or_derivation / creator_or_annotator / approval_state / created_at / last_modified / sensitivity_or_restriction / inclusion_reason を追跡し、評価run側には run_id / dataset_id / version_id / digest / model_version / evaluator_or_rubric_version / executed_at を固定します。

変換・filter・dedup・augmentation・annotation・adjudication・split生成は「dataset metadataを書き換える」のではなく、入力versionから出力versionを生成したActivityとして記録します。元versionを上書きせず、derivation edgeとrecipe/versionを残します。datasetを修正した場合、同じversion_idのままdigestだけ変える運用を避けます。

ownerとapproverは分離可能にし、少なくとも「保守責任者」と「利用承認者」を同一概念に固定しません。ownership metadataは責任所在の手掛かりであり、著作権・個人情報処理の適法性・同意の存在を意味しないため、権利根拠は別fieldまたは別registryへ接続します。

削除・利用停止が必要なsourceを受けた場合、source→derived dataset version→case→evaluation runの逆引きができることを受入条件にします。既に実行済みrunの履歴は改竄せず、dataset versionをREVOKED/RETIRED等の状態にして将来利用を止め、必要な再評価対象を列挙します。

PROV-O、MLflow、OpenLineageはいずれも用途が異なります。PROV-Oは汎用provenance model、MLflowはML lifecycle内のdataset/run tracking、OpenLineageはjob/run/dataset間のlineage event交換に強みがあります。どれか一つを採用すればeval governance全体が完成する、という関係ではありません。既存基盤に応じて概念モデル・実装metadata・transportを分離して選択します。

case-levelの完全な原文保存が禁止されるデータでは、lineageのために機密情報を複製しません。stable opaque identifier、restricted source locator、digest、access-controlled registryを使い、provenance store自体を新たな情報漏えい源にしない設計が必要です。

content digestは同一性確認に有効ですが、hash algorithm、serialization、row order、normalization、excluded fieldsが異なれば比較できません。digest contractを固定しない限り「hashが違う＝意味のあるdataset変更」とは限りません。

source lineageが追えても、元source自体が誤っている、権利情報が更新されていない、annotation rationaleが失われている場合があります。また、OpenLineage等の自動収集はpipelineで観測できる関係に強い一方、人手での選定理由・承認・同意・adjudicationは別途入力しなければ欠落します。

• case単位で保持すべきprovenance粒度は、データ種別・契約・privacy要件・再評価コストに依存します。
• dataset digestのcanonical serialization方式は実装ごとに異なり、ツール横断の単一標準値は確定できません。
• consent、copyright、database right、個人情報削除等の法的要件はjurisdictionと契約条件に依存します。
• LLM生成・synthetic eval caseでは、生成model/version/prompt/source groundingをどこまで保存すべきかはrisk tierごとに決める必要があります。

「評価データは、dataset/versionの識別子とdigestだけでなく、source・derivation・作成/承認責任・rubric・split・利用runを追跡し、後から評価結果の再現と影響範囲の逆引きができるようにする。PROV-O、MLflow、OpenLineage等はその一部を実装するための基盤になり得るが、権利・同意・削除・case-level approvalまで自動的に保証するものではない。」

• W3C, PROV-O: The PROV Ontology: https://www.w3.org/TR/prov-o/
• MLflow, Dataset Tracking: https://mlflow.org/docs/latest/ml/dataset/
• MLflow, mlflow.data API: https://mlflow.org/docs/latest/api_reference/python_api/mlflow.data.html
• OpenLineage, Object Model: https://openlineage.io/docs/spec/object-model/
• OpenLineage, Lineage Dataset Facet: https://openlineage.io/docs/spec/facets/dataset-facets/lineage/
• OpenLineage, Ownership Dataset Facet: https://openlineage.io/docs/spec/facets/dataset-facets/ownership/

汎用provenance規格を法的適法性の証明として扱わず、digestを完全なdataset identityと断定せず、特定ツールのmetadata captureをcase-level governanceの代替としません。