AREKORE

daikikatsuragawaのアレコレ

アウトプットはいいぞ2022

これは何?

2022年、id:daikikatsuragawaの個人的なアウトプットをまとめます。それぞれに対して「アウトプットはいいぞ」なポイントも記録します。

※以下のアドベントカレンダーに参加しています。

qiita.com

記事投稿

日頃の学びを抽象化し、コードスニペットとして整理し、記事として公開しました。

qiita.com

qiita.com

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • 技術についての理解を深められた
  • 辞書的な扱いができる(便利)

記事投稿企画への参加+受賞

Qiitaの記事投稿企画へ参加しました。

qiita.com

そして、受賞しました🏆

zine.qiita.com

「pandera」×「外部データの読み込み」×「日本語の記事」という点で、新規性と有用性のある内容の記事を公開できたと思っています。正直、「いいね」の数は比較的少ないと感じていましたが、良い評価をしていただき、こんな高価なものまでいただきました。自分とってはトロフィーです。

jp.sharp

  • 技術についての理解を深められた
  • 自身の記事が価値のあるものだと認識できた(評価してもらえた)
  • 賞品(物理)をいただいた
  • 後述する「LTでの登壇」、「カンファレンスでの登壇」に繋げられた
    • 内容についてもだが、プロポーザルの採択につなげる根拠となった

LTでの登壇

地元で開催されている「飛騨高山Pythonの会」にて何度か発表させていただきました。

hida-python.connpass.com

資料は以下に残しています。

speakerdeck.com

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • 技術についての理解を深められた
  • 資料という成果物が残る
  • 情報交換できるコミュニティに参加できた(関連して他コミュニティへの参加にも繋がった)
  • 後述する「カンファレンスでの登壇」に繋げられた
    • 内容についてもだが、プロポーザルの採択につなげる根拠となった

カンファレンスでの登壇

「Open Source Conference 2022 Online Kyoto」に参加し、登壇しました。関連した記事を以下に残しています。

daikikatsuragawa.hatenablog.com

「PyCon JP 2022」に参加し、登壇しました。関連した記事を以下に残しています。

daikikatsuragawa.hatenablog.com

特に、PyCon JP 2022では質疑応答が盛り上がりまして、逆に得られるものが多かったです。以下の記事も書けました。

daikikatsuragawa.hatenablog.com

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • 技術についての理解を深められた
  • CfP(プロポーザル)で採択される経験が得られた
  • 資料という成果物が残る
  • 情報交換できるコミュニティに参加できた(関連して他コミュニティへの参加にも繋がった)
  • 業界への貢献となった(誰かの役に立った)
  • 発表と議論のサイクルにより理解が深まった

スプリントへの参加

PyCon JP 2022ではスプリントがあったのでリーダー(ただしチームは一人)として参加しました。関連した記事を以下に残しています(再掲)。

daikikatsuragawa.hatenablog.com

限られた時間で何かしらの成果を生み出す場というのがよかったです。限られた時間で何かを生み出し切るということは様々なリスクを負って進めたり、諦めたりという意思決定のサイクルを繰り返す必要があり難しいことも多いですが、面白いですね。「better than nothing」の精神で形にしきりました。

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • 成果物を生み出せた(残る)

OSS開発

OSS開発@GitHubはしばしば実施していました。Pythonへの理解が深まったからか、自分から送るプルリクエストの内容も様々になってきました。 特に、研究系のライブラリへのコントリビュートができています。

github.com

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • 改修にあたって関心のある技術の理解を深められた
  • 業界への貢献となった(誰かの役に立った)

特に研究系のライブラリはアイデアが素晴らしい分、その魅力を使用者にそのまま伝えるための貢献が重要だと考えています。

キュレーション

反実仮想説明法のキュレーションを始めています。

github.com

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • 技術についての理解を深められた
  • 技術を集約できる場を生み出せた

アドベントカレンダーの作成

意外となかったことや、去年存在して欲しかったということもあり「機械学習」のアドベントカレンダーを作成しました。

qiita.com

正直、本記事公開時点では埋まっていないですが、Better than Nothingの精神です。こちらについての諸々は後日公開します。

ここで感じた「アウトプットはいいぞ」なポイントは以下です。

  • Better than Nothingの精神を磨くことができた
  • ないものを生み出せた
  • ハードルを乗り越える経験が得られた

その他

その他、アウトプットに関連して記録しておきたいことを残します。全体を通して、「新規性のあることをする」を意識して取り組めたと思っています。自信の学びを目的の一つとしてるものの、同じ、もしくは優良版の発信が世の中に存在していれば、業界としては意味のないものになります。その上で、少なからず業界への貢献もできたのかと思います。またそれを「出し惜しみせず発信と議論(FB)のサイクルを繰り返す」も意識して取り組みました。関心のある技術を知っていること自体をアイデンティティと捉えがちですが、基本出し惜しみせず発信しました。おそらく出し惜しみしていると、より技術力のある方が発信し、いつかは誰もが知る世界になってしまします。そのため、サッサと発信するようにしました。ただ、発信と議論によるサイクルにより、逆に理解も深まったり、視座が広がり、チャンスが得られたり、新たにアイデンティティの種も得られました。どんどん発信することとします。このように意味のある発信はできていることもあり、それぞれが関連付られる状態、もっというと実務にも生きる状態にできたことがよかったです。

「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」の質疑応答

先日、PyCon JP 2022にて「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」という題で発表をしました。

2022.pycon.jp

発表資料は以下です。

speakerdeck.com

とてもありがたいことに、想像以上に多くの方に発表を聞いていただくことができました。今回の発表について、確認しただけでも以下のような反響を得ることができました。ありがとうございます。

  • Twitterにおいて約50件のツイート
  • Slidoにおいて約20件の質問

ただし、質問については、発表後の時間が短かったこともあり、回答しきれないものも多く、整理した情報や意見を十分に伝えることができませんでした。そこで、本記事では、いただいた質問に基づき、質問を整理します。そして、それらの質問に対する回答という形式で、発表を補足していきます。※本記事は随時更新予定です。

質疑応答

ライブラリの仕様

Q:pydanticによってイミュータブルなクラスの定義は可能ですか?

pydanticによって、イミュータブル(つまり生成されたインスタンスの状態の変更が不可能)なクラスの定義は可能です。BaseModel(pydantic.BaseModel)内のConfigにより設定を変更することで実現します。以下2つパラメータによる設定例を紹介します。

  • allow_mutation
  • frozen

まずは、allow_mutationの設定をする場合です。allow_mutationについては以下のとおりです。

whether or not models are faux-immutable, i.e. whether setattr is allowed (default: True)

引用元:https://pydantic-docs.helpmanual.io/usage/model_config/

つまり、allow_mutation=Falseにするとイミュータブルなクラスが実現されます。以下のように設定が可能です。

from pydantic import BaseModel
 
class User(BaseModel):
    name: str
    age: int
  
    class Config:
        allow_mutation = False
 
user = User(name="パイソン 太郎", age=20)
user.name = "パイダンティック 次郎"

上記の実装は、イミュータブルなインスタンスに値の再代入を試みていますが、設定の意図通りにエラーが発生します。

(省略)

TypeError: "User" is immutable and does not support item assignment

続いてfrozenの設定をする場合です。frozenについては以下のとおりです。

setting frozen=True does everything that allow_mutation=False does, and also generates a hash() method for the model. This makes instances of the model potentially hashable if all the attributes are hashable. (default: False)

引用元:https://pydantic-docs.helpmanual.io/usage/model_config/

つまり、frozen=Trueにすると、allow_mutation=Falseになり、イミュータブルなクラスが実現されます。

from pydantic import BaseModel
 
class User(BaseModel):
    name: str
    age: int
  
    class Config:
        frozen = True
 
user = User(name="パイソン 太郎", age=20)
user.name = "パイダンティック 次郎"

上記の実装も、イミュータブルなインスタンスに値の再代入を試みていますが、設定の意図通りにエラーが発生します。

このように、pydanticで定義するクラスをイミュータブルにできます。

Q:pandasのデータフレームではstr型はobject型として扱われます。panderaでstr型のカラムの定義は可能ですか?

※当日、曖昧な回答をしてしまい申し訳ございません。以下が整理された回答です。

panderaでstr型のカラムの定義は可能です。str型を含むobject型は、str型として扱われます。それゆえ、panderaによる型のバリデーションによって弾かれることはありません。それに加え、Fieldクラスを組み合わせることで、文字列における「始まりの文字列」、「終わりの文字列」のバリデーションなども可能です。しかし、object型のうち本来str型ではないであろう要素の通過も許されてしまうという問題があります。つまり、他のint型、float型とは異なる挙動となっています。panderaのプロジェクトでは、本件に関連したIssueが公開されており議論がなされています。今後、str型に関するバリデーションについて対応されるかもしれません。

github.com

github.com

以下のような暫定対応により、他のint型、float型と同様の型のバリデーションの実現が可能です。

import pandera as pa
from pandera.typing import Series

class UserSchema(pa.SchemaModel):
    name: Series[str]
    age: Series[int]

    @pa.check("name")
    def check_value_is_string_type(cls, series: Series) -> Series:
        return series.map(lambda v: isinstance(v, str))

Q:pydanticによるバリデーション時のエラーのカスタマイズ(エラーメッセージの変更など)は可能ですか?

可能です。特にエラーメッセージについて説明します。設定方法は大きく2つあります。

まず、Configのerror_msg_templatesに設定を入れることで、エラーメッセージの上書きが可能です。

a dict used to override the default error message templates. Pass in a dictionary with keys matching the error messages you want to override (default: {})

引用元: https://pydantic-docs.helpmanual.io/usage/model_config/

例えば、整数型であるという条件を満たさない場合のエラー(type_error.integer)が発生したときのメッセージとして「整数型ではありません!」を設定しています。

from pydantic import BaseModel
 
class User(BaseModel):
    name: str
    age: int
  
    class Config:
        error_msg_templates = {
            "type_error.integer": "整数型ではありません!",
        }
 
user = User(name="パイソン 太郎", age="二十歳")

整数型ではない値を入れたため、エラーが発生されます。設定した「整数型ではありません!」というメッセージが出力されます。

(省略)

ValidationError: 1 validation error for User
age
  整数型ではありません! (type=type_error.integer)

error_msg_templatesに要素を追加することで、各種エラーにおけるメッセージの設定が可能です。 Fieldに設定した最小値の条件を満たさないエラー(value_error.number.not_ge)に対して「自然数ではありません!」というメッセージを設定します。

from pydantic import BaseModel, Field
 
class User(BaseModel):
    name: str
    age: int = Field(ge=0)
  
    class Config:
        error_msg_templates = {
            "type_error.integer": "整数型ではありません!",
            "value_error.number.not_ge": "自然数ではありません!",
        }
 
user = User(name="パイソン 太郎", age=-1)

自然数ではない値を入れたため、エラーが発生されます。設定した「自然数ではありません!」というメッセージが出力されます。

(省略)

ValidationError: 1 validation error for User
age
  自然数ではありません! (type=value_error.number.not_ge; limit_value=0)

続いて、@validatorpydantic.validator)というデコレーターを付与しているメソッドにおけるエラーに対してメッセージを設定することでもメッセージの指定が可能です。以下は、上記のコードに加え、文字列に空白を含むことを期待するモデルです。

from pydantic import BaseModel, Field, validator
 
class User(BaseModel):
    name: str
    age: int = Field(ge=0)
  
    class Config:
        error_msg_templates = {
            "type_error.integer": "整数型ではありません!",
            "value_error.number.not_ge": "自然数ではありません!",
        }
  
    @validator("name")
    def check_contain_space(cls, v):
        if " " not in v.strip(): # 前後の半角空白を無視
            raise ValueError("半角空白が含まれていません!")
        return v.strip() # 前後の半角空白を削除
 
user = User(name="パイソン太郎", age=20)

半角空白が含まれていない値を入れたため、エラーが発生されます。設定した「半角空白が含まれていません!」というメッセージが出力されます。

ValidationError: 1 validation error for User
name
  半角空白が含まれていません! (type=value_error)

以上の方法でpydanticに関するエラーメッセージの指定(上書き)が可能です。

類似するライブラリとの比較

Q:TypedDictとpydanticの違いは何ですか?

TypedDictとpydanticについて以下のように特徴を比較します。

比較軸 TypedDict pydantic
インストールの要否 標準ライブラリである。PyPIからのインストールは不要。 外部ライブラリである。PyPIからのインストールが必要。
型チェックの精度 構造の表現が可能なのでより詳細な辞書型の方チェックが可能になる。 構造の表現が可能なのでより詳細な辞書型の方チェックが可能になる。
バリデーションの実現方法 あくまで型なので、単体では特にバリデーションは実施されない。 クラスおよびフィールドの定義のみで型についてのバリデーションが実施される。Fieldモジュールにより簡単なバリデーションの実現が可能である。メソッドを定義することにより詳細なバリデーションの実現が可能である。
シリアライズ・デシリアライズの仕様(辞書型) あくまで型なので、特にシリアライズ・デシリアライズなどの振る舞いはない。 辞書型とのシリアライズ・デシリアライズが可能。辞書がネストされている場合も意図どおりインスタンスをの生成が可能である。
シリアライズ・デシリアライズの仕様 (JSON あくまで型なので、特にシリアライズ・デシリアライズなどの振る舞いはない。 JSONとのシリアライズ・デシリアライズが可能。JSONがネストされている場合も意図どおりインスタンスをの生成が可能である。

上記のように、それぞれに異なるメリット・デメリットが存在します。使用状況によって導入を検討してください。

Q:dataclassとpydanticの違いは何ですか?

dataclassとpydanticについて以下のように特徴を比較します。

比較軸 dataclass pydantic
インストールの要否 標準ライブラリである。PyPIからのインストールは不要。 外部ライブラリである。PyPIからのインストールが必要。
型チェックの精度 構造の表現が可能なのでより詳細な型チェックが可能になる。 構造の表現が可能なのでより詳細な型チェックが可能になる。
バリデーションの実現方法 クラスおよびフィールドの定義のみではバリデーションが実施されない。メソッドを定義することにより詳細なバリデーションの実現が可能である。 クラスおよびフィールドの定義のみで型についてのバリデーションが実施される。Fieldモジュールにより簡単なバリデーションの実現が可能である。メソッドを定義することにより詳細なバリデーションの実現が可能である。
シリアライズ・デシリアライズの仕様(辞書型) 辞書型へのシリアライズ・デシリアライズが可能。ただし、ネストされている要素に関してはインスタンスには変換されず、辞書型として格納される。 辞書型とのシリアライズ・デシリアライズが可能。辞書がネストされている場合も意図どおりインスタンスをの生成が可能である。
シリアライズ・デシリアライズの仕様 (JSON dataclasses-jsonという外部ライブラリを使用することでJSONとのシリアライズ・デシリアライズが可能。ネストされている場合も意図どおりインスタンスをの生成が可能である。 JSONとのシリアライズ・デシリアライズが可能。JSONがネストされている場合も意図どおりインスタンスをの生成が可能である。

上記のように、それぞれに異なるメリット・デメリットが存在します。使用状況によって導入を検討してください。

Q:dataclassからpydanticへの移行について有用な情報はありますか?

既存のdataclass(dataclasses.dataclass)を使用したコードに対して、比較的少ない変更でpydanticへ移行する時に有用なモジュールとしてdataclass(pydantic.dataclasses.dataclass)があります。

Dataclasses

If you don't want to use pydantic's BaseModel you can instead get the same data validation on standard dataclasses (introduced in Python 3.7).

引用元:https://pydantic-docs.helpmanual.io/usage/dataclasses/

@dataclassというデコレーターを付与することでバリデーションをしてくれるクラスにしてくれます。つまり、使用している@dataclassdataclasses.dataclass)というデコレーターを付与しているクラスの内容を変更する必要がなく、インポートをするモジュールの差し替えのみでpydanticの使用が可能です。

例えば、従来のdataclass(dataclasses.dataclass)を使用した以下のコードがあったとします。これは期待しない値の格納を許してしまいます。

from dataclasses import dataclass

@dataclass
class User:
     name: str
     age: int

User(name="パイソン 太郎", age="二十歳")

dataclassモジュールをdataclasses.dataclassからpydantic.dataclasses.dataclassに差し替えます。差分は以下です。

- from dataclasses import dataclass
+ from pydantic.dataclasses import dataclass

モジュールを差し替えるのみで、バリデーションが実現され、期待しない値の格納を防いでいます。

from pydantic.dataclasses import dataclass

@dataclass
class User:
     name: str
     age: int

User(name="パイソン 太郎", age="二十歳")
(省略)

ValidationError: 1 validation error for User
age
  value is not a valid integer (type=type_error.integer)

以上より、既存のdataclass(dataclasses.dataclass)を使用しているコードにおいて、モジュールをdataclass(pydantic.dataclasses.dataclass)に差し替えることで、バリデーションを実施してくれるクラスに変えることができます。

ただし、dataclass(pydantic.dataclasses.dataclass)とBaseModel(pydantic.BaseModel)の挙動が異なるようなので注意してください。

Note

Keep in mind that pydantic.dataclasses.dataclass is a drop-in replacement for dataclasses.dataclass with validation, not a replacement for pydantic.BaseModel (with a small difference in how initialization hooks work). There are cases where subclassing pydantic.BaseModel is the better choice.

For more information and discussion see pydantic/pydantic#710.

引用元:https://pydantic-docs.helpmanual.io/usage/dataclasses/

使用場面についての見解

特定の場面に対して「導入すべきか?」という質問が多く挙げられました。断定できないことが恐縮ですが、導入するか否かの意思決定については、各々個人やプロジェクトのさまざまな事情なども組み合わせて検討することをお勧めします。私自身も限られた経験の中で、導入する(したい)場面や、導入しない(したくない、できない)場面が、条件付きで導入できる場面があり、ケースバイケースだと思っています。それゆえ、以降の内容を意思決定の材料とすることをお勧めします。

Q:pydanticとpanderaによるデータのバリデーションにかかる時間を見過ごせない状況では、ウェブアプリケーション全体ではなく、バッチ処理のみに導入するという選択肢はどうですか?

おっしゃるとおり、良い選択肢だと思います。定刻に起動するバッチ処理は比較的、処理時間を気にしなくても良いと思われるので、処理時間に関する懸念は解消されやすいと思われます。場合によっては、期待しないデータを一時的に管理してしまう可能性もありますが、少なくともバッチ処理の頻度では解消できるかと思われます。理想は常にバリデーションしているべきだが、このように、例えば入り口と出口のみだったり、バッチ処理のみなど、部分的にバリデーション を用意するという工夫が考えられます。

Q:機械学習や分析など、ラビットプロトタイピングが有用な場面があります。このような場合にライブラリ(pydanticやpandera)を使用する際、慣れていない場合は開発速度が遅くなります。何か対策はありますか?

私の一意見を回答とさせていただきます。対策としては、状況によって使用するか否かの判断をしています。例に挙げていただいた機械学習や分析、特にGoogle ColaboratoryやJupyter Notebookなど、インタラクティブに実装するものに関して、その判断について考えます。まず判断材料となる要素として「pydanticとpanderaがもたらす」という価値と「慣れていない場合は開発スピードが遅くなる」というリスクを挙げます。この比重は状況によって変わってきます。まず、書き捨てのコードの場合、「使用しない」に比重を置きます。なぜなら、後から再実行しない、つまり堅牢性が重要ではないためです。それに加え、後から見返す必要がない、つまり可読性が重要ではないためです。逆に後から見返し、管理したい、再実行することを考えると、長い目では「使用する」に比重をおいた方が良いと思います。そのとき、ある程度のめどが立つまでは使用はせず、リファクタリングの段階で使用するのが良いのではないかと考えています。また、計算ミスなどが深刻な影響を与える場合、「pydanticとpanderaがもたらす価値」が上がる可能性もあるかもしれません。

Q:定義しているスキーマの対象のAPIのレスポンスや元のデータにおける仕様に変更があった場合、どのような対応をすると良いですか?後方互換性を持たせるなどですか?

通常の開発における修正と同様に、スキーマを定義し直します。ただし、データのスキーマが変化する過渡期については注意が必要です。リリースにおける切り替えの工夫だったり、おっしゃるとおり後方互換性を持たせるなどの対応が必要かと思われます。試したことはないが、Union型やOption型、可能であれば使用を避けたいが、Any型、スキーマ自体の設定の変更などにより許容するデータを調整できるため、過渡期に用意しておく後方互換性に有用な要素になるかとも思われます。

Q:現実のデータセットは必ずしも整理されているとは限らないということは承知していますが、そのような場合でもスキーマを定義、バリデーションを実施することが望ましいですか?

おっしゃるとおり、元のデータセットは必ずしも整理されているとは限りません。そこで取りうる選択肢もいくつか存在すると思われます。例えば、そのようなデータセットを整形などすると思われますが、まず一次受けのタイミングではそのまま受け取り、その後、整形に伴ってpanderaによるスキーマ定義およびバリデーションを実現するという選択肢も考えられます。もしくは、一次受けのタイミングでわかっている範囲での必要最小限のバリデーションのみ実装するという方法も考えられます。これにより、少なくともどのようなデータを扱っているのかを他者が理解することができると思われます。

Q:pydanticを使用せず、panderaのみの使用は可能ですか?

発表では類似の目的と類似の記述方法を持つ2つのライブラリとして併用することを勧めたが、それぞれ独立したライブラリなので問題ない。ただし、panderaの依存関係にpydanticが含まれているため、インストールは必要となる。どうせインストールされるのであれば、併用してみてはどうかというのが私の意見です。

Q:(本発表において)pydanticとpanderaを併用する意図はどのようなものですか?一方のみの使用でも良いのでは?

前提として、状況に応じて、一方のみの使用でも良いと思います。例えば、データフレームを扱わないのにpanderaを使用する必要はありません。逆にデータフレームを扱うような処理においては併用が有効になる可能性があります。改めて、併用を提案したい理由を列挙します。

  • スキーマ定義およびバリデーションが可能な型の範囲が増えること
  • panderaのSchemaModelを使用する場合に併用時の学習コストが少ないこと
  • 依存関係もあり他方を使用している場合リソースに関する懸念が少ないこと(使用しない理由がないこと)

経験に基づく見解

※今回は個人として発表しました。それゆえ、以降は個人の活動や経験に基づき回答します。

Q:発表内容を実際の業務や研究に活用したことがありますか?

私が個人としてPythonによるコーディングを実施する場面は以下2つです。

  • Google Colaboratoryでの分析
  • OSS(主にライブラリ)開発

Google Colaboratoryでの分析では「何度か実行する」かつ「見返す」ようなコードではがあります。そのようなコードの場合、pydanticやpanderaを使用しています。ある意味ドキュメントの代わりもかねて使用しています。逆に、書き捨てのコードでは恩恵が少ないので使用しません。

OSS開発については使用しません。依存関係を増やしてしまうことが一番の理由です。対象のOSSを使用しているプロジェクトの都合なども考えると、依存関係を増やすのはハードルが高いです。ただし、堅牢性、可読性に関する課題感を抱くことはしばしばあり、開発、テスト時にできることとして、型ヒントおよびmypyの導入をしていたりはします。

Q:処理速度が遅くて困った経験はありますか?

自分には「処理速度が遅くて困った経験」がありませんでした。理由は以下で困りようもないのだと考えられます。

  • リアルタイム性が重要な実装ではない(計算時間を待てる)
  • そもそも扱うデータが大規模ではない(かもしれない)

逆にリアルタイム性が重要であったり、大規模なデータを扱う場合は、処理速度が遅く困ることになるかもしれません。

本記事のまとめ

今回の発表および皆様からのコメントを踏まえ、意思決定の事例やユースケースを、導入したか否かにかかわらず知りたいと思いました。可能であれば、類型化できるのではないかと考えています。引き続き、情報収集に努めます。情報提供や質問などあれば、以下までご連絡をください。よろしくお願いいたします。

forms.gle

PyCon JP 2022の振り返り

先日、PyCon JP 2022にスピーカーおよびスプリントリーダーとして参加してきました。

2022.pycon.jp

本記事はその記録です。

カンファレンス

1日目は不参加でした。ただし、Twitterや発表のアーカイブは閲覧し、雰囲気を感じていました。オンラインの恩恵も受けることができました。

2日目から参加しました。オフラインでの技術系のカンファレンスへの参加は初めてで、新鮮でした。企業ブースもたくさん回りました。

カンファレンス感

そして、「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」という内容で発表しました。

発表直前(サブのモニターがあって発表しやすい)

資料は以下に公開しています。

speakerdeck.com

発表の目的は以下でした。

  • 自分の知見を新たなコミュニティへ伝える(+エコシステムの活性化)
  • 新たなコミュニティへ伝える事により新たなフィードバックを得る

それゆえ、様々な感想や質問をいただいたことは、とてもありがたかったです。こちらについては追々まとめようと思います。

自分の発表以外に、他の方々の発表も聞いていまして、内容から発表時の伝え方や立ち振る舞いまで、様々な観点で学びが多かったです。特に、特定のプロジェクトを軸に話を展開していく方々の話は興味深く、もし次回発表するのであれば、参考にしたいと思いました。

スプリント

3日目は、スプリントに参加しました。遠方からだったこともあり、せっかく参加するのであればと思い、テーマを掲げ、リーダーとして申し込みました。自問自答の末に当初の予定から磨きがかかり、「反実仮想説明法を活用したウェブアプリケーションのMVP開発」というテーマで開発をしました。

これまで執筆した以下の記事に関連したものです。

daikikatsuragawa.hatenablog.com

daikikatsuragawa.hatenablog.com

反実仮想説明法の提供する価値が素晴らしいと思いつつも「具体的にどのように伝えるのが良いか(UI)」という観点で考えたい、可能であれば議論したいと感じていました。そこで、議論の叩きにするためのベースラインとして、まずはウェブアプリケーションとしてカタチにしきろうと思い、MVP開発という体で開発を始めました。

テーマを提案するリーダーでしたが、チームは自分一人でした。そのため、もくもくと作業をしました。「これがもくもく会か…!」とピンときてたりもしました。紆余曲折ありました。本題とは別のところであるライブラリの不具合らしき挙動も発見し、報告したり、個人的に挙動の理解を深めたりできました。ギリギリまでバタバタしましたが、なんとか見せられる状態にしました。当日の成果発表はタイトルだけ書いたスライドを用意し、基本はウェブアプリケーションを実際に動かしながらデモンストレーションをしました。以下はその時の成果発表を後日にまとめたものです。

speakerdeck.com

時間制限があると、これからの時間の取捨選択を強いられ、時間内でのベストを生み出せるのでいいですね。

また、数人の方とお話しさせていただき、それぞれの普段の抱いている課題について共有しました。これがなかなか刺激的で、熱く語り合ってしまいました。

まとめ

そんな様子でPyCon JP 2022に参加してきました。運営の方々、本当にありがとうございました。来年以降も参加したいと思い、すでにネタの思案をしています。様々な観点で、とても学びの多い機会になりました🙋

2022年8月のアレコレ

これは何?

2022年8月のアレコレ(=2022年1月〜2022年8月のアレコレ)を記録します。

👇参考

daikikatsuragawa.hatenablog.com

2022年1月〜2022年8月のアレコレ

特に4月以降ですが、見聞を広める、度胸を得ることを目的とし、「新しいこと(0→1の経験)を続けること」を目標として過ごしていました。結果としてこれまでに以下のような経験をしました。少しずつ詳細を記録します。

4月、地元で開催されている「飛騨高山Pythonの会」にて発表させていただきました。

hida-python.connpass.com

speakerdeck.com

speakerdeck.com

以降、数回の発表の機会をいただいています。

speakerdeck.com

speakerdeck.com

Qiitaの記事投稿キャンペーンに参加し、5月、受賞しました。

zine.qiita.com

「データフレームのバリデーションを実現するためのpandera入門〜ダミーデータによる利用例の紹介」という題の記事です。

qiita.com

PyCon JP 2022のCfPに提出をし、6月、ありがたいことに採択していただきました。「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」という題です。

pyconjp.blogspot.com

7月、OSC2022 Online/Kyotoに講師として参加させていただきました。

event.ospn.jp

以下は再編集版の記事です。

daikikatsuragawa.hatenablog.com

8月、反実仮想説明法(Counterfactual Explanations)のキュレーションを始めました。ほどよく色んな人の力を借りつつ進められたらと思います。 数字に拘ってしまう性分でして、公開日は8月22日(ハンジツ)です。

github.com

9月以降も続けます。

今回はこんなところで。

Pythonによる開発をアップデートするライブラリの紹介

2022年7月29日(金)、30日(土)に開催された「Open Source Conference 2022 Online Kyoto」に参加しました。そこで私(id:daikikatsuragawa)は「Pythonによる開発をアップデートするライブラリの紹介」というテーマで発表しました。

event.ospn.jp

発表資料は以下です。

speakerdeck.com

本記事は、発表に向けて用意した原稿を記事として再構築したものです。目次は以下です。

Pythonによる開発をアップデートするライブラリ

はじめに、Pythonについて説明します。Pythonとは「動的型付けプログラミング言語」のひとつです。その特徴として、さまざまなライブラリがオープンソースソフトウェア(OSS)として公開されていることが挙げられます。例えば、機械学習に関する実装がなされているライブラリが公開されており、それを利用することで機械学習の実現が可能です。PythonサードパーティーソフトウェアリポジトリであるPyPIには、38万を超えるソフトウェアやライブラリが登録されています。

pypi.org

そして、GitHubの調査によると、Pythonは3年連続で人気プログラミング言語の第2位にランクインしており、多くの開発者に親しまれています。

octoverse.github.com

本記事はそんなPythonの開発について紹介します。具体的には「Pythonによる開発をアップデートするライブラリ」を紹介します。

まず、本記事の背景と動機を共有します。まず、「開発における理想と現実」について説明します。みなさん、開発における理想を想像してみてください。私なら「成果物が正常に動作すること」「保守性が高いこと(複数人での開発が可能)」です。 そのような理想に対して、現実が一致しない場合があります。具体的には「成果物に不具合が生じることがあること」や「開発の保守性が高いという自信が無いこと」などが挙げられます。「理想に対して、現実が一致しない場合がある」ということは、「理想と現実にギャップが存在する」と言い換えることが可能です。このギャップを改善することで現実は理想に近づくと考えられます。そのため、ここで言うギャップを整理します。理想が「成果物が正常に動作すること」であるのに対して、現実は「成果物に不具合が生じることがあること」だったとします。この時のギャップは「開発者が不具合を埋め込んでしまうこと」です。理想が「開発の保守性が高い(複数人での開発が可能)」であるのに対して、現実は「開発の保守性が高いという自信が無いこと」だったとします。この時のギャップは「開発者が保守性の低いコーディングをする」です。このように「開発における理想と現実」にはギャップが存在しているということがわかります。

理想 現実 理想と現実のギャップ
成果物が正常に動作すること 成果物に不具合が生じることがあること 開発者が不具合を埋め込んでしまうこと
保守性が高いこと(複数人での開発が可能) 開発の保守性が高いという自信が無いこと 開発者が保守性の低いコーディングをする

ここまでで理想と現実の間にはギャップがあることがわかりました。続いて、そこでギャップを解消する手段について考えます。例えば「個人の能力の向上」が挙げられます。ただし、これは個人に依存する為、不確実性が大きいです。他に「仕組みの導入」があります。つまり、開発プロセスの改善です。これは仕組みを規約とすることで実現可能性が高くなります。以上より、開発プロセスの改善により理想と現実のギャップの解消を試みます。

開発プロセスの改善」を試みるために、理想と現実のギャップを開発プロセスの課題と捉え直します。まず「開発者が不具合を埋め込んでしまうという」という課題は「不具合を埋め込ませない開発プロセスの構築が必要」というような開発プロセスの課題として捉え直すことが可能です。また「開発者が保守性の低いコーディングをする」といった課題は「一定の保守性を担保する開発プロセスの構築が必要」というような開発プロセスの課題と捉え直すことが可能です。つまり、理想と現実のギャップというのは開発プロセスの課題と言えます。

理想と現実のギャップ 開発プロセスの改善
開発者が不具合を埋め込んでしまうこと 不具合を埋め込ませない開発プロセスの構築が必要
開発者が保守性の低いコーディングをする 一定の保守性を担保する開発プロセスの構築が必要

改めてお伝えすると、課題は開発プロセスの課題と変換が可能です。開発プロセスの課題はツールによって改善が期待されます。また、Pythonには様々なライブラリが存在します。これらを加味して、本記事では「有用なライブラリを導入し利用」することで開発プロセスの改善を考えます。以上の背景・動機により「Pythonによる開発プロセスを改善(つまり、開発をアップデート)する有用なライブラリを紹介します。

本記事で紹介するライブラリはこのようになっています。まず、pydanticです。モデルの定義に基づくバリデーションを実現します。次に、panderaです。スキーマの定義に基づくデータフレームのバリデーションを実現します。そして、hypothesisです。入出力に関するプロパティの定義に基づくProperty-based testingを実現します。最後に、streamlitです。必要最小限のウェブアプリケーションを簡単に実現します。pydantic、pandera、hypothesisはそれぞれ導入による堅牢性と可読性の向上が期待されます。streamlitは、早期に提供価値の評価を実現させます。

本記事で紹介するライブラリについて「伝えること」と「伝えないこと」は以下です。

  • 伝えること
    • ライブラリの概要
    • ライブラリの利点
    • 簡単な利用例
  • 伝えないこと
    • 詳細な利用例

それゆえ、本記事を知るキッカケとして捉えていただけると幸いです。そして、気になったら是非調べてみてください。

型ヒントとは?

以後、上記で紹介したライブラリについて紹介します。その前提として、事前に理解しておくことが望ましいPythonの「型ヒント」についての説明をします。型ヒントとは、「変数の定義」、「関数の引数や戻り値の定義」に型のヒントを付与する記法です。Pythonの3.5以降導入されています。以下、型ヒントを使ったコードです。

name: str = "パイソン 太郎"

def calculate_division(numerator: int, denominator: int) -> float:
   return numerator / denominator

例えばこのコードの場合、nameというような変数に文字列を代入しています。これがstring型だということは暗黙的に理解できるのですが、このように明示的に示すこともできます。これが型ヒントです。他にも関数の引数、戻り値の定義にもこのように型ヒントを付与が可能です。これによりこの変数や関数の引数、戻り値がどんな型を期待しているのかという情報を読み取ることが可能です。以上よりコードの可読性の向上が見込まれます

型ヒントの振る舞いについて説明します。実は、実行時に型のチェックはしません。そのため型ヒントに対して、期待していない状態だったとしてもエラーにならないです。あくまで開発者向けのコメントのような扱いです。サードパーティのツール、例えばmypyと組み合わせることで静的チェックを実現したりします。

www.mypy-lang.org

以上より型ヒントを使うこととサードパーティのツールと組み合わせることで堅牢性の向上が見込まれます。

型ヒントの記述方法について説明します。基本は大きく三つ記述方法があります。一つ目は変数に関して、直後にコロン(:)と型を記述します。

name: str = "パイソン 太郎"

続いて、関数の引数については、変数と同じで各引数の直後にコロンと型を記述します。関数の戻り値に関しては関数の定義中のコロンの直前にハイフンと大なりからなる矢印のような記号(->)と型を記述します。

def calculate_division(numerator: int, denominator: int) -> float:
   return numerator / denominator

続いて、複雑な型の指定についてです。先ほどは int型、float型、str型の例を挙げました。それに加えて、dict型やlist型などの構造を持つ型の指定も可能です。念のためお伝えすると、以降で説明に挙げるコードはPython 3.8までの記法です。まず、dict型、list型などの要素の型の指定が可能です。まず、Dictというクラスをインポートし、これを型ヒントとして使います。この時、dict型のキーおよびバリューの型の指定が可能です。

from typing import Dict

user_and_age: Dict[str, int] = {'パイソン 太郎': 20}

複数の型の指定も可能です。以下のコードでは、Unionというクラスをインポートし、型ヒントとして指定したい型を複数種、指定します。

from typing import Union

str_or_int: Union[str, int] = 0 # or パイソン 太郎"

他にも値を持っていることを必須としない変数には、必須ではない(Optional)という指定が可能です。

from typing import Optional

optional_int: Optional[int] = None # or 0

どんな値でも受け入れるという場合は、任意(Any)という指定が可能です。

from typing import Any

any: Any = 0 # or "パイソン 太郎", None, {"パイソン 太郎": 20} ...

関数の返り値が存在しない(None)という指定も可能です。

from typing import Any

def return_none(input: Any) -> None:
    return None # もしくはリターンをしない

最後に、プリミティブな型以外の指定も可能です。先ほどのDictというクラスを使った例なども該当しますが、プリミティブな型以外の指定も可能です。つまり、自作のクラスも型ヒントとしての指定が可能です。例えば、SampleClassというクラスを定義したとします。これに対して、インスタンスを生成する際、そのインスタンスの型はSampleClassです。この時、SampleClassを型ヒントとしての指定が可能です。関数の引数、返り値の場合も同様です。

class SampleClass:
   pass

sample_class: SampleClass = SampleClass()

def return_input(input: SampleClass) -> SampleClass:
   return input

型ヒントについてのまとめをお伝えします。型ヒントとは、変数の定義、関数の引数や戻り値の定義に型のヒントを付与する記法です。型ヒントの振る舞いとしては実行時に型のチェックはしません。それゆえ、たとえ誤っていてもエラーが生じません。そこで、サードパーティのツール、例えばmypyと組み合わせることで静的チェックの実現が可能です。これにより可読性と堅牢性の向上が期待されます。

以降、型ヒントを活かして可読性と堅牢性を向上させるpydanticとpanderaを紹介します。

モデルの定義に基づくバリデーションを実現するpydantic

それでは、モデルの定義に基づくバリデーションを実現するpydanticについて紹介します。

みなさん、複数の部品で構成されるシステムを開発していますか?多くのシステムは、複数の部品で構成されていると考えられます。ここでの部品とは、モジュール、クラス、メソッドなどのことです。基本的には、各部品が役割と責任を持ち、連携して動作します。つまり、各部品の入出力を把握しておけば、システムの全てを把握する必要はありません。不要です。入出力にはdict、JSONといった構造を持つものも多く使われます。

ここでは、複数の部品から構成されるシステムの開発において、そのような課題を2つ取り上げます。まずは「入出力で扱うデータの定義がわからない」という可読性の課題です。他の部品の出力を入力として受け取る場面があるかと思います。この時に他の部品の出力の構造が分からなければ、他の部品の実装を深く調べる必要があるといった可読性の課題が挙げられます。例えば部品Yが部品Zにデータを格納したJSONを渡すとします。この時、部品Zからすると、JSONなのはともかく、その構造、要素は何かが理解できない可能性があります。

また、「入出力で扱うデータが正しくない」という堅牢性の課題が挙げられます。他の部品の出力を把握しているものの期待と異なる、正しくないデータを受け取る場面を指します。例えば、受け取った年齢の値が「−1」、型が異なる、期待しているデータがないといった場合です。例えば部品Yが部品Zにデータを格納したJSONを渡すとします。この時、部品Zはどんな内容のJSONを受け取るのかを把握しているものの、受け取ったデータが正しくない可能性があります。

先に挙げた課題の解決に期待されるライブラリとしてpydanticを紹介します。pydanticとはモデルを定義することでデータのバリデーションを実現するライブラリです。それに加え、dict型やJSONとのシリアライズ/デシリアライズも可能で、部品の入出力に有用です。

pydantic-docs.helpmanual.io

PyPIで公開されており、このコマンドによりインストールが可能です。

!pip install pydantic

ライセンスはMIT Licenseです。

github.com

pydanticを導入することにより先ほどの課題の解決が期待されます。入出力で扱うデータの定義がわからないという課題については、モデルの定義をコードとして記述することにより把握が可能となります。入出力で扱うデータが正しくないという課題については、定義に基づくバリデーションにより正しいデータのみが存在する状態となります。以降、具体的なpydanticの利用方法についてお伝えします。

pydanticの利用例としてまずはモデルの定義について紹介します。以下はpydanticによりモデルを定義しているコードになります。

from pydantic import BaseModel, Field

class User(BaseModel):
   name: str
   age: int = Field(ge=20)

pydanticのモジュールであるBaseModelを継承した任意のクラスがモデルの定義となります。今回はUserというクラスを定義しました。インスタンス変数は名前(name)と年齢(age)の2つです。また、このモデルの定義のさい、型の情報に加え、有効範囲の定義などが可能です。例えば、この年齢は20歳以上の場合に受け付けます。続いて、以下はインスタンスを生成するコードです。

external_data = {
   'name': 'パイソン 太郎',
   'age': 20
}
user = User.parse_obj(external_data)

dict型の変数からインスタンスを生成するparse_objというメソッドがあります。これにより、従来、dict型やJSONを扱っていた場合、このように利用することで、扱っているデータの定義をコードから読み取ることが可能です。つまり、可読性が保たれます。続いて、別のインスタンスを生成します。試しに年齢が19歳という有効範囲外の値を持つインスタンスの生成を試みます。

external_data = {
   'name': 'パイソン 太郎',
   'age': 19
}
user = User.parse_obj(external_data)

この時、ValidationErrorというエラーが生じます。つまり、定義を満たさないインスタンスは生成されません。つまり、堅牢性が保たれます。一部を省略しますが、ValidationErrorの出力は以下のようになっています。

(省略)
ValidationError: 1 validation error for User
age
  ensure this value is greater than or equal to 20 (type=value_error.number.not_ge; limit_value=20)

年齢について「20以上という定義を満たしていない(ensure this value is greater than or equal to 20)」という旨が書かれています。このようにエラーの詳細の確認が可能です。続いて、pydanticによって定義したモデルを引数とする関数について説明します。

from pydantic import validate_arguments

@validate_arguments
def input_user(user : User) -> None:
   pass

実現するために記述する内容は大きく2つです。まずは関数に対して、引数のバリデーションを実行するデコレータであるvalidate_argumentsを付与します。もう一つはpydanticで定義したクラスを引数の型ヒントとして指定します。そして、以下が実行です。

external_data = {
   'name': 'パイソン 太郎',
   'age': 20
}
input_user(external_data)

pydanticのBaseModelを継承したクラスはdict型、JSONとのシリアライズおよびデシリアライズをしてくれるため、dict型のままでの関数への入力が可能です。以下のコードでは定義を満たすため、成功します。有効範囲外の値を持つ場合、ValidationErrorが生じます。

external_data = {
   'name': 'パイソン 太郎',
   'age': 19
}
input_user(external_data)

入力として与えるタイミング、つまり、関数内で記述した処理を実行する前にエラーが発生します。それゆえ、不要な計算は実施されません。続いて、Userというクラスを返り値とする関数について紹介します

def output_user() -> User:
    external_data = {
        'name': 'パイソン 太郎',
        'age': 20
    }
    return User.parse_obj(external_data)

この関数は内部で任意の処理をしたとして、Userインスタンスを生成し、これを返り値とします。また、部品間のやりとりが実行環境が違うという場合は、インスタンスのやり取りができないため、dict型やJSONに変換します。

output_user().dict()

このような場合でも以下のように有効範囲外の値があれば、関数実行中にエラーが生じます。

def output_user() -> User:
    external_data = {
        'name': 'パイソン 太郎',
        'age': 19
    }
    return User.parse_obj(external_data)

つまり、この関数の返り値は正常なものであるということが担保されます。ここまでは簡単な型であったり、数値の有効範囲を満たすか否かを定義し、バリデーションを実現していました。それに加え、詳細なバリデーションの実現も可能です。例えば、名前の要件として、半角空白(” ”)を含むとします。

from pydantic import BaseModel, Field, validator
import unicodedata

class User(BaseModel):
   id: int
   name: str # 半角空白を含む(※前後以外)
   age: int = Field(ge=20)
  
   @validator("name")
   def check_contain_space(cls, v):
       if " " not in v.strip(): # 前後の半角空白を無視
           raise ValueError("ensure this value contains spaces")
       return v.strip() # 前後の半角空白を削除

この要件に対するバリデーションをデコレーターとメソッドにより実現させます。まず、メソッドを用意します。今回はcheck_contain_spaceという、前後を除いて半角空白が含まれるかを判定し、含まれない場合にエラーを発生させるメソッドを用意しました。これに対し、validatorというデコレーターを付与します。ここに対象とするインスタンス変数を指定します。今回はnameを指定します。これにより、デコレーターとメソッドによるバリデーションが可能です。この記述におけるメソッドを工夫すると、詳細なバリデーションの実現が可能です。

ここまでお伝えしたpydanticについてのまとめです。まず複数の部品によって構成されるシステムの開発について各部品が役割と責任を持ち連携しているということをお伝えしました。ただ課題もあります。まだ入出力で扱うデータの定義が分からないという可読性の課題が考えられます。そして、入出力で扱うデータが正しくないという堅牢性の課題が考えられます。そのような課題を解決する手段としてpydanticを紹介しました。これはモデルの定義をすることでデータのバリデーションを実現するライブラリです。モデルの定義により、コードから要件の把握が可能です。また、定義に基づくバリデーションにより正しいデータのみが存在する状態にできます。

スキーマの定義に基づくデータフレームのバリデーションを実現するpandera

続いて、データフレームの定義に基づくバリデーションを実現するpanderaについて紹介します。

みなさん、データフレームを使っていますか?実は様々な種類が存在していますが、今回挙げるデータフレームというのはpandasというライブラリのDataFrameとします。データフレームは、表形式のデータの取り込み、加工、集計、分析に利用されるものです。データ分析や機械学習などで活躍しています。

sepal_length sepal_width petal_length petal_width target
0 5.1 3.5 1.4 0.2 0
1 4.9 3 1.4 0.2 0
2 4.7 3.2 1.3 0.2 0
3 4.6 3.1 1.5 0.2 0
4 5 3.6 1.4 0.2 0

そのようなデータフレームにおける課題を挙げます。まずは「意図していない値を格納してしまう」といった課題です。以下のデータフレームはその例です。

sepal_length sepal_width petal_length petal_width target
146 6.3 2.5 5 1.9 2
147 6.5 3 5.2 2 2
148 6.2 3.4 5.4 2.3 2
149 5.9 3 5.1 1.8 2
150 ◯△□ 3 4.35 1.3 3

例えば、数値を期待しているsepal_lengthという列に「◯△□」という文字列が格納されてしまったりします。また、targetという列は、「0」/「1」/「2」というカテゴリカルな数値を期待しています。しかし、期待されている値ではない「3」が格納されてしまっています。このように意図しない値を格納してしまうという課題が発生します。

次に「他者・未来の自分がコードから内容を読み取れない」といった課題です。例えば、以下はデータフレーム(scikit-learnより取得)を扱うコードです。

scikit-learn.org

import pandas as pd
from sklearn.datasets import load_iris

data = load_iris()
iris = pd.DataFrame(data.data, columns=data.feature_names)
iris["target"] = data.target
iris.head()

このirisという変数はデータフレーム型のインスタンスです。変数名からアヤメについての情報が格納されていることの想像が可能です。しかし、このカラム、およびその値が数値なのか文字列なのかといった要件について、コードから読み取ることは不可能です。これでは、他者がコードから詳細を読み取れず、協調作業は困難になります。それに加え、未来の自分もこの内容を思い出すのは困難でしょう。このように「他者・未来の自分がコードから内容を読み取れない」という課題が発生します。

そこでpanderaというようなライブラリを紹介します。panderaとはスキーマ(つまり、構造)の定義により、データフレームのバリデーションを実現するライブラリです。

pandera.readthedocs.io

PyPIで公開されており、このコマンドによりインストールが可能です。

!pip install pandera

ライセンスはMIT Licenseです。

github.com

panderaは先ほど挙げた課題の解決に有用です。まず「意図しない値を格納してしまう」という課題がありました。panderaを導入することによってデータフレームのバリデーションを実現し、意図しない値の格納を防ぐことが可能です。続いて、「他者・未来の自分がコードから内容を読み取れない」といった課題がありました。panderaを導入に伴いスキーマを明示的に定義することで、コードから内容の読み取りが可能です。続いて、具体的なpanderaの利用例について紹介をします。panderaによってバリデーションを実現する方法として以下2種類のクラスの選択が可能です。

DataFrameSchema SchemaModel

今回はSchemaModelというクラスを使う方法を紹介します。こちらは、スキーマの定義がpydanticとインタフェースが類似しているため、pydanticを利用している方におすすめです。

それではpanderaの利用例について説明します。まず準備としてアヤメのデータセットを準備します。説明を簡単にするために、各カラム名は単純なものに変換しています。

import pandas as pd
from sklearn.datasets import load_iris

data = load_iris()
iris = pd.DataFrame(data.data, columns=data.feature_names)
iris["target"] = data.target
iris = iris.rename(
   columns={
       "sepal length (cm)": "sepal_length",
       "sepal width (cm)": "sepal_width",
       "petal length (cm)": "petal_length",
       "petal width (cm)": "petal_width",
   }
)

先ほどのコードの実行によって、以下のようなデータフレームが生成されます。上から5件のレコードを表示させています。

iris.head()
sepal_length sepal_width petal_length petal_width target
0 5.1 3.5 1.4 0.2 0
1 4.9 3 1.4 0.2 0
2 4.7 3.2 1.3 0.2 0
3 4.6 3.1 1.5 0.2 0
4 5 3.6 1.4 0.2 0

カラムは5つです。がく片、花弁の長さ、幅はfloat型の数値です。アヤメの種類が「0」/「1」/「2」のカテゴリカルな数値として格納されています。また、データの統計情報を確認します。

iris.describe()
sepal_length sepal_width petal_length petal_width target
count 150 150 150 150 150
mean 5.843333 3.057333 3.758 1.199333 1
std 828066 0.435866 1.765298 0.762238 0.819232
min 4.3 2 1 0.1 0
25% 5.1 2.8 1.6 0.3 0
50% 5.8 3 4.35 1.3 1
75% 6.4 3.3 5.1 1.8 2
max 7.9 4.4 6.9 2.5 2

これによりそれぞれのカラムの最大値が分かります。この情報はスキーマの定義の際に使います。それではpanderaを使ってスキーマを定義します。panderaのスキーマはこのように定義します。

import pandera as pa
from pandera.typing import Series

class IrisSchema(pa.SchemaModel):
   sepal_length: Series[float] = pa.Field(gt=0, le=8)
   sepal_width: Series[float] = pa.Field(gt=0, le=5)
   petal_length: Series[float] = pa.Field(gt=0, le=7)
   petal_width: Series[float] = pa.Field(gt=0, le=3)
   target: Series[int] = pa.Field(isin=[0, 1, 2])

   class Config:
       name = "BaseSchema"
       strict = True
       coerce = True

panderaのSchemaModelを継承したIrisSchemaというクラスを定義します。そして、列ごとの要件を設定していきます。がく片、花弁の長さ、幅はfloat型の数値と設定します。それに加え、それぞれの先ほどの統計情報を参考に最小値・最大値を設定します。種類を示す列に「0」/「1」/「2」のいずれかが入ると設定します。それでは。この定義したスキーマを使ってバリデーションを実施してみます。先ほど定義したクラスのメソッドであるvalidateに対して、データフレームを入力として与えることでバリデーションが実施されます。まずは、定義の内容を満たすデータフレームを入力してみます。すると、同じデータフレームが出力されます。何事もないですが、これは問題がなかったことを意味します。これによりデータフレームのバリデーションが実現されます。

iris = IrisSchema.validate(iris)
iris.head()
sepal_length sepal_width petal_length petal_width target
0 5.1 3.5 1.4 0.2 0
1 4.9 3 1.4 0.2 0
2 4.7 3.2 1.3 0.2 0
3 4.6 3.1 1.5 0.2 0
4 5 3.6 1.4 0.2 0

次に、意図しないレコードを追加したデータフレームを用意します。ここでの意図しないレコードとして、targetに「3」を入れます。

invalid_record = {
   "sepal_length": 5.8,
   "sepal_width": 3.0,
   "petal_length": 4.35,
   "petal_width": 1.3,
   "target": 3, # invalid value
}
invalid_iris = iris.append(invalid_record, ignore_index=True)
invalid_iris["target"] = invalid_iris["target"].astype(int)

この列の定義として、「0」/「1」/「2」のいずれかにあてはまるようにしているため、意図しないレコードとなってしまいます。以下が、先ほどのレコードを追加した、バリデーション前のデータフレームです。

invalid_iris.tail()
sepal_length sepal_width petal_length petal_width target
146 6.3 2.5 5 1.9 2
147 6.5 3 5.2 2 2
148 6.2 3.4 5.4 2.3 2
149 5.9 3 5.1 1.8 2
150 5.8 3 4.35 1.3 3

インデックスが150のレコードのtargetに「3」といった意図しない値が入っています。この意図しないレコードを含むデータフレームに対して、バリデーションを実施してみます。

invalid_iris = IrisSchema.validate(invalid_iris)

すると、以下のようなSchemaErrorというエラーが発生しました。

(省略)

SchemaError: <Schema Column(name=target, type=DataType(int64))> failed element-wise validator 0:
<Check isin: isin({0, 1, 2})>
failure cases:
   index  failure_case
0    150             3

エラーの内容を読んでみると、「インデックスが150のレコードでエラーが発生している」ということが書いてあります。このように、panderaによるデータフレームのバリデーションが実現されます。

panderaのまとめです。まずは、データフレーム(pandas.DataFrame)について紹介しました。データフレームは表型式のデータの取り込み、加工、集計、分析に利用されます。 データ分析/機械学習などで活躍します。ただし、「意図しない値を格納してしまう」「他者・未来の自分がコードから内容を読み取れない」という課題を挙げました。そのような課題の解決が期待されるライブラリであるpanderaを紹介しました。これは、データフレームのスキーマ(構造)を定義することでデータフレームのバリデーションを実現するライブラリです。これにより、「バリデーションにより意図しない値の格納を防ぐ」「スキーマを明示的に記述することでコードから内容の読み取りが可能に」ということが実現されます。

入出力に関するプロパティの定義に基づくProperty-based testingを実現するhypothesis

続いて、入出力に関するプロパティの定義に基づくProperty-based testingを実現するhypothesisについて紹介します。

みなさん、単体テストは実施していますか?単体テストはプログラムを構成する小さな部品(関数/メソッド)が意図した振る舞いか否かを検証するテストです。Pythonではunittestやpytestというテスト用のフレームワークが有名です。一般的によくみられる単体テストの種類として「Example-based testing」があります。関数やメソッドに対して、任意の基準で入力値を選択し、出力値や事後状態を確認することにより振る舞いを検証する手段です。任意の基準とは、ランダムに選択したり、境界値テストに従って選択するなどを意味します。)例えば、除算するメソッドに対して、「3」と「12」という入力を与えて「4」が出力されることを確認するテストを指します。

そのようなExample-based testingにおける課題として「テストの品質がテスト作成者に依存してしまう」といったものが挙げられます。それにより、テスト作成者の想定内の内容で不十分になってしまう危険があります。例えば、境界値テストなどの手法を知らず要件を満たさない検証となったといったことが生じます。他にも、除算するメソッドに対して、適当な入出力での検証は実施しているが、分母が「0」の場合、入力が「None(null)」の場合といったエッジケースを見逃すといったことが生じます。また、冗長なテストを書いてしまう危険があります。例えば、複数の例を設定し検証したが特に意味がないといったことです。

そのような単体テストの課題に対して、Property-based testingが有用です。Property-based testingとは、入出力に関するプロパティを定義し多数の入力を与え検証する方法です。入出力に関するプロパティの例として、除算するメソッドに対して、「入力値はint型の自然数、ただし分母に0、入力にNone(null)は許可しない」、「出力はfloat型の数値」といったことが挙げられます。

そのようなProperty-based testingを実現するライブラリとしてhypothesisがあります。入出力に関するプロパティの定義に基づくProperty-based testingを実現するライブラリになっています。PyPIで公開されており、このコマンドによりインストールが可能です。

hypothesis.readthedocs.io

PyPIで公開されており、このコマンドによりインストールが可能です。

!pip install hypothesis

ライセンスはMozilla Public License Version 2.0です。

github.com

Property-based testingを実現するhypothesisは先ほど挙げた単体テストにおける課題に有用です。課題としてテストの品質がテスト作成者に依存してしまうといった課題がありました。これに対して、hypothesisおよびProperty-based testingの導入によりテスト作成者に依存しないテストの品質の担保が実現されます。

それではhypothesisの利用例についてお伝えします。まずはテスト対象の関数を用意します。

# main.py

def calculate_subtraction(a: int, b: int):
  return a - b

calculate_subtractionという関数を用意しました。概要としては、入力された2つの整数を減算します。入力は整数(int型)を2件、出力は整数(int型)になります。

calculate_subtractionに対して、単体テストの作成を試みます。プロパティは、入力がそれぞれint型の自然数xとyです。そして、xがyより大きいとします。この時、出力は0以上1以下となります。ひとまず、このプロパティの実装を試みた結果が以下です。

# test_main.py

from main import calculate_subtraction
from hypothesis import given, strategies

@given(x=strategies.integers(), y=strategies.integers())
def test_calculate_subtraction(x, y):
  assert 0 < calculate_subtraction(x, y)

これにより、入力x、yにはランダムな数字が設定され、テストは複数回実施されます。実はこの単体テストの実装には不備がありまして、その辺りの解消を試みつつhypothesisの挙動を紹介します。pytestコマンドにより実行します

pytest test_main.py

すると、AssertionErrorが生じました。

Falsifying example: test_calculate_subtraction(
   x=0, y=0,
)

(省略)

FAILED test_main.py::test_calculate_subtraction - assert 0 < 0

内容を確認すると、関数の出力がプロパティで設定した要件(0より大きい)を満たさなかった事によるエラーだということがわかります。その時の入力をみてみると、入力として想定していた自然数ではない値(0)が与えられていました。あらかじめ実装したかったプロパティが実現できていないようなので修正します。改めて実装からプロパティを考え直すと、入力を自然数としたいところ、0以下を含む整数となっていたようです。修正した結果が以下のコードです。入力x、yの最小値に1を設定し入力を自然数に限定しています。

  # test_main.py

  from main import calculate_subtraction
  from hypothesis import given, strategies

- @given(x=strategies.integers(), y=strategies.integers())
+ @given(x=strategies.integers(min_value=1), y=strategies.integers(min_value=1))
  def test_calculate_subtraction(x, y):
      assert 0 < calculate_subtraction(x, y)

pytestコマンドにより実行します。すると、AssertionErrorが生じました。

Falsifying example: test_calculate_subtraction(
   x=1, y=1,
)

(省略)

FAILED test_main.py::test_calculate_subtraction - assert 0 < 0

内容を確認すると、関数の出力がプロパティで設定した要件(0より大きい)を満たさなかった事によるエラーだということがわかります。確認すると、入力として想定していたx>yを満たさないことがわかります。改めて、以下は、xがyより大きいという条件を設定していない単体テストです。修正した結果が以下のコードです。

  # test_main.py
  
  from main import calculate_subtraction
  from hypothesis import assume, given, strategies
  
  @given(x=strategies.integers(min_value=1), y=strategies.integers(min_value=1))
  def test_calculate_subtraction(x, y):
+     assume(x > y)
       assert 0 < calculate_subtraction(x, y)

関数の入力に与える前にxとyを比較し、条件を満たすものだけ検証するようにしています。この修正した単体テストを実行してみると、問題なく通ります。このようにhypothesisにより、Property-based testingが実現されます。この時の施行回数は100回でした。具体的には、以下に挙げるような値をランダムに生成し、検証しているようです。

x y
1 30604 30261
2 109 5
3 10694612245883426162890217387823834314 9

hypothesisのまとめです。まず、Example-based testing(一般的によくみられる単体テスト)について説明しました。関数やメソッドに対して、任意の基準(例:ランダム/境界値テスト)で入力値を選択し、出力値や事後状態の確認により振る舞いを検証すると、いう手法です。「テストの品質が実装者に依存」という課題を挙げました。それに対して、Property-based testingを紹介しました。これは、入出力に関するプロパティを定義し多数の入力を与え検証する手法です。そして、hypothesisを紹介しました。これは、入出力に関するプロパティの定義に基づくProperty-based testingを実現するライブラリです。これにより、「Property-based testingによるテスト作成者に依存しないテストの品質を担保」が実現されます。

必要最小限のウェブアプリケーションを簡単に実現するstreamlit

本記事で紹介するライブラリは次が最後です。必要最小限のウェブアプリケーションを簡単に実現するstreamlitについて紹介します。

前提として、Minimum Viable Product(MVP)について説明します。MVPとは、ユーザーに必要な最小限の価値を提供できるプロダクトです。提供しようとしてる価値の評価に有用だと言われています。例えば、ユーザーに移動という価値を与えるために、自動車を開発しているとします。この時、「そもそもユーザーが移動を必要としているのか」を検証したい、とします。しかし、自動車の開発というのはとても大規模で大変なものになります。完成してから価値の評価をすることを考えます。また、「実は移動には想定していた価値がなかった」と評価されたとします。すると、それまでの労力や費用などの損失が大きくなってしまいます。そこで、移動という価値を評価するために、まずはスケートボード、自転車を開発します。これにより、そもそもの移動の価値やそれに伴い、自動車の開発の方向性を定めたりとできます。MVPとはこの時のスケートボードや自転車を指します。これらよりソフトウェア開発、特にウェブアプリケーションの開発においても、必要最小限、動作する状態にすることが望ましいと考えられます。

そこで streamlitというライブラリが有用です。streamlitは ウェブアプリケーション、特にUIの開発を簡単に実現するライブラリです。特に機械学習を扱うような大規模で複雑な開発におけるMVPの開発に有用だと考えられます。

streamlit.io

PyPIで公開されており、このコマンドによりインストールが可能です。

pip install streamlit

ライセンスはApache License 2.0です。

github.com

デモンストレーションとして、streamlitで実現する予測をするウェブアプリケーションを作成したので紹介します。概要としては、学習済みの機械学習モデルによりアヤメの品種を予測するものです。。背景(シナリオ)は、もともとは分析・検証をNotebookで実施していたがそもそも価値があるのかを評価するためにMVPを開発するものとします。ウェブアプリケーションの仕様については、がく片の長さ、がく片の幅、花弁の長さ、花弁の幅を入力とし、最も可能性が高いアヤメの品種を予測し出力するものです。デモンストレーションのために用意したものはひとつのPythonファイルのみです。以下のコマンドにより起動します。

streamlit run app.py

このように一つのPythonファイルのみでもウェブアプリケーションの実現が可能です。以下、streamlitリストによって生成したアヤメ品種予測フォームです。

アヤメ品種予測フォーム(予測前)

フォームには4つの入力欄が表示されています。これらに数値を入力します。数値を入力する際、あらかじめ設定された上限下限の制約に従う必要があります。制約から外れた値の入力はできません。そして、全ての項目を入力後に「予測」と書かれたボタンを押すと、以下のように予測結果が表示されます。

アヤメ品種予測フォーム(予測後)

予測結果の上部には入力値を表示させています。そして、下部には出力として予測されるアヤメの品種を表示させています。また、再度フォームへ入力し、予測を実行することも可能です。

先ほど紹介したようなウェブアプリケーションの実装内容について紹介します。まずは streamlitとは直接関係はないですが、機械学習モデルを作成します。

import pandas as pd
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
import streamlit as st

iris = load_iris()
x = pd.DataFrame(iris.data, columns=iris.feature_names)
y = pd.DataFrame(iris.target, columns=["target"])

model = LogisticRegression(random_state=123)
model.fit(x, y)

参考までに、ロジスティック回帰という分類手法を使ってアヤメの種類の予測を実現する機械学習モデルを作成しました。続いて、streamlitの入力フォームとボタンの作成を行います

st.title("アヤメ品種予測フォーム")

with st.form("アヤメ品種予測フォーム"):
   st.write("アヤメの詳細を入力してください。")
   sepal_length = st.number_input(
       "sepal length (cm)", min_value=0.0, max_value=8.0, value=(0.0+8.0)/2, step=1.0)
   sepal_width = st.number_input(
       "sepal width (cm)", min_value=0.0, max_value=5.0, value=(0.0+5.0)/2, step=1.0)
   petal_length = st.number_input(
       "petal length (cm)", min_value=0.0, max_value=7.0, value=(0.0+7.0)/2, step=1.0)
   petal_width = st.number_input(
       "petal width (cm)", min_value=0.0, max_value=3.0, value=(0.0+3.0)/2, step=1.0)
   submitted = st.form_submit_button("予測")

まずはtitleというメソッドにより「アヤメ品種予測フォーム」というタイトルを生成します。そして、formというメソッドによりフォームを作成します。続いて、フォームの要素としてwriteというメソッドにより補足文を作成します。そして、number_inputというメソッドにより数値入力欄、form_submit_buttonというメソッドによりフォームのサブミットボタンを用意します。数値入力欄は4項目を用意し、それぞれにラベル、下限(min_value)・上限(max_value)、初期値(value)などを設定します。ここまでで、フォームを実現します。続いて、予測結果の取得部分の作成について紹介します。

if submitted:
   st.write("## 予測結果")
   st.write("### 入力")
   input_df = pd.DataFrame(
       {
           "sepal length (cm)": sepal_length,
           "sepal width (cm)": sepal_width,
           "petal length (cm)": petal_length,
           "petal width (cm)": petal_width
       },
       index=["入力値"])
    st.write(input_df)

まず、先ほどのサブミットボタンの返り値であるsubmittedという変数に基づく条件分岐により、サブミットボタンを押した後に表示させる内容を用意します。そこで、いくつかの文字列を表示させます。また、入力された内容を整理したデータフレームも表示させます。先ほどのコードにより、サブミット後の出力を実現します。続いて、予測結果の出力部分を作成します。

   st.write("### 出力")
   pred_df = pd.DataFrame({
       "target_name": iris.target_names.tolist(),
       "probability": model.predict_proba(input_df)[0].tolist(),
   })
   target_name = pred_df.sort_values(
       "probability", ascending=False)["target_name"].tolist()[0]
   st.write(target_name)

まずは機械学習モデルに与えるデータの整理をし、予測結果として、アヤメの種類の名称を変数(target_name)に格納します。そしてこのtarget_nameを表示させます。このコードによってこの予測結果の出力を表示させることができます。

このようにウェブアプリケーションおよびMVPを実現します。そのような便利なstreamlitでしたが、MVP開発を望む前に把握したい事を整理します。元のコードとstreamlitの導入によって実現したMVPが成り立ちます。この時に気になるのが「streamlitの導入コストはどれだけか?」ということです。ここでの導入コストは実装のための学習・保守性などについて、つまり、「簡単さ」と「コード量」です。以上より、streamlitの導入コストを確認するために、「簡単さ」と「コード量」と言う観点で、先ほどのコードを見直します。ウェブアプリケーションを実現するために使ったstreamlitのメソッドについて以下に示します。

メソッド 振る舞い 論理ステップ数
title タイトルの表示 1
form フォームの作成 1
number_input フォーム内の数値入力欄の作成 4
form_submit_button フォームのサブミットボタンの作成(返り値によりサブミット後の動作の指定が可能) 2
write 文字列やデータフレームの表示 6

これらより、先ほどのウェブアプリケーションを実現するために記述していたコードは、どれもメソッドに対する振る舞いがわかりやすく、簡単だと思われます。また、メソッドは5種、論理ステップ数は14件でした。つまり、分析・検証のために記述した元のコードに加えて、簡単かつ多くないコードによるMVPの実現が期待されます。

streamlitのまとめです。MVP について説明しました。これは、ユーザーに必要最小限の価値を提供できるプロダクトであり、提供しようとしている価値の評価に有用です。そのようなMVPの開発に有用となる必要最小限のウェブアプリケーションを簡単に実現するstreamlitを紹介しました。これは、ウェブアプリケーション(特にUI)の開発を簡単に実現するライブラリです。特に機械学習などを扱うような大規模で複雑な開発におけるMVPの開発に有用です。

本記事のまとめ

最後に本記事のまとめをもって締めます。まずPython による開発をアップデートするライブラリについてお伝えしました。背景として、開発における理想と現実のギャップの解消のために開発プロセスを改善すると、良いことをお伝えしました。そこで本記事では「開発プロセスを改善つまり、開発をアップデートする有用なライブラリを紹介する」と説明しました。大きく4つのライブラリを紹介しました。まずは、pydanticという「モデルの定義に基づくバリデーションを実現」するライブラリを紹介しました。次に、panderaという「スキーマの定義に基づくデータフレームのバリデーションを実現」するライブラリを紹介しました。また、hypothesisという「入出力に関するプロパティの定義に基づくProperty-based testingを実現」するライブラリを紹介しました。最後に、streamlitという「必要最小限のウェブアプリケーションを簡単に実現」するライブラリを紹介しました。是非これらライブラリを使ってPythonによる開発をアップデートしてください。

複数の反実仮想説明に基づく複数の意思決定の促進を目的としたひとつの施策の設計を支援する手法の提案

​​以前、筆者(id:daikikatsuragawa)は反実仮想説明を生成するDiCEというPythonで実装されているライブラリに興味を持ちました。DiCEが生成する反実仮想説明は、現在の状態を望んだ状態に変えるために、必要となる具体的な特徴の変化例を算出するという点で、重要業績評価指標(Key Performance Indicator:KPI)の設定に貢献し、意思決定の促進に有効であると考えられます。しかし、複数の意思決定の促進を目的とした施策を設計する場合、考慮すべき課題が挙げられました。そこで、複数の意思決定の促進を目的とした施策の設計を支援することを動機として、複数の反実仮想説明に基づく手法を提案します。

意思決定を促進する反実仮想説明

機械学習を活用したサービスでの目的として「予測」が挙げられます。例えばユーザの特徴に基づき、ユーザの状態を“望ましい状態”か否かの二値で分類します。このようなサービスの中には以下の動機へ対応する目的で提供されているものが存在していると考えられます。

  • ユーザ自身が状態を把握したい
    • “望ましい状態”ではないと予測された場合はそれを覆したい
  • サービス提供者がユーザの状態を把握したい
    • サービス提供者にとって“望ましい状態”のユーザの数を増やしたい

しかし、上述した目的のサービスにおいて、以下の課題が挙げられます。

  • ユーザもしくサービス提供者は状態を覆すための具体的な行動指針がわからない
    • 何をどのように行動(改善)したら良いのかがわからない
    • そもそも決断に至る行動を設定できない
  • 有識者でない人によって考案された行動指針が効果的かわからない
    • 行動指針の信頼性が低いことにより行動の決断に至る可能性が低い
    • 仮に行動指針に従ったところで望ましい状態にならない可能性が高い

以上の理由で、例えば予測を実施する機械学習を活用したサービスでは予測に加えて上記の課題を解決した、意思決定の促進を目的とした情報の提供が必要です。本記事における「意思決定」の定義を「行動を決断すること」、および「行動すること」、その結果として「特徴が変化すること」までとします。また「意思決定者」を行動指針に基づき、「意思決定」を実施するか否かといった判断が可能である人と定義します。ここで挙げる「行動指針」とは意思決定に必要なもので、「自身で判断が可能なもの」、「有識者によって提供されるもの」があると定義します。具体的には何をどれだけ変化させたら状態が覆るのかを表現したものであるとします。

課題の解決に対して、近年、議論や研究がなされている機械学習の解釈手法が有効であると考えられます。これらは予測の結果に対して、それからどういった解釈ができるのかをより詳細にユーザに伝えることを目的としています。その中でも「未来のためにどうしたら良いのか(どんな意思決定をしたら良いのか)」の指針を示すことを目的とした解釈手法があります。この手法により上述した課題の解決が期待されます。

上述した目的の機械学習の解釈手法のひとつとして反実仮想を応用した「反実仮想説明(Counterfactual Explanations)」が提案されています。反実仮想とは以下を意味します。

文法で、事実と反対のことを想定すること。「もし〜だったら…だろうに」のような言い方。

引用元:反実仮想(ハンジツカソウ)とは? 意味や使い方 - コトバンク

このような反実仮想を応用した反実仮想説明は、機械学習の予測に対して、状態が覆る、具体的な特徴の変化例を提案します。「もし〜だったら…だろうに」という伝え方が可能であるため、提案を受けた人は具体的な行動指針の想像が可能です。具体的には、「もし特徴Aがa、特徴Bがbだけ変化した場合、状態が覆る」と言ったことを伝えることが可能です。それゆえ、意思決定の促進に対する有効性が期待されます。

反実仮想説明を生成するDiCE*1というライブラリが開発されています。Pythonで実装されておりPypi*2で公開されています。筆者は個人的にDiCEに興味を持ち、以前、反実仮想説明をサービスとして活用するという観点で考察をしました。

daikikatsuragawa.hatenablog.com

その過程で、複数の意思決定の促進を目的とする場合、特に目的を満たすひとつの施策を設計する場合、工夫が必要であるという課題を挙げました。

複数の意思決定の促進を目的とした場合の課題

改めて課題を把握するために、反実仮想説明が必要となるサービスについて、ユースケースを以下の表にて整理します。2つの軸を設定し、それらに基づき比較します。

意思決定者が少ない/BtoB 意思決定者が多い/BtoC
有識者による解釈が不要(もしくは有識者≒意思決定者) ①意思決定者が反実仮想説明を確認し「行動指針」を理解し自ら行動(組織向け) ②意思決定者が反実仮想説明を確認し「行動指針」を理解し自ら行動(個人向け)
有識者による解釈が必要 有識者が反実仮想説明を解釈して行動指針(施策)を意思決定者に提案 有識者が複数の反実仮想説明を解釈し複数の意思決定を促進する施策を提案

例えば「①意思決定者が反実仮想説明を確認し「行動指針」を理解し自ら行動(組織向け)」は法人向け(Business to Business:BtoB)な形式のサービスに当てはまります。その中でも有識者による解釈が不要、もしくは意思決定者自身が有識者であるため、反実仮想説明を参考にした行動指針の考案、意思決定の実現が可能です。組織を“望ましい状態”にするための分析、提案を提供するサービスがこれに当てはまります。それに対して「②意思決定者が反実仮想説明を確認し「行動指針」を理解し自ら行動(個人向け)」は消費者向け(Business to Consumer:BtoC)な形式のサービスに当てはまります。その中でも有識者による解釈が不要、もしくは意思決定者自身が有識者である例です。個人を“望ましい状態”にするための分析、提案を提供するサービスがこれに当てはまります。例えば、金融業界におけるローン許諾判定システムや、教育における受験の合格判定システムです。ユーザは具体的に何をしたら良いのか、判断できるはずです。次に「③有識者が反実仮想説明を解釈して行動指針(施策)を意思決定者に提案」はBtoBな形式のサービスで、出力される反実仮想説明に有識者による解釈が必要な例です。意思決定者にとって理解が難しい特徴が扱われている場合です。サービスの提供に加えて有識者であるコンサルタントによるサポートが前提となる状況です。

最後に「④有識者が複数の反実仮想説明を解釈し複数の意思決定を促進する施策を提案」です。結論から述べると、この状況への対応に課題が挙げられます。これはBtoCな形式のサービスかつ有識者が必要な例です。この時、BはCの意思決定を促進させたいと思うものの、対象となる意思決定者が複数、つまり対象となる反実仮想説明が複数であることから、施策の設計が困難です。またCに対して個別に施策を設計することも考えられます。しかし、その量の多さから現実的ではありません。それゆえ、この課題を解決するために、複数の反実仮想説明を理解、解釈し、要約したうえで、ひとつ、つまり、一体多の施策を設計する必要があります。これを実現する手法(処理)が必要であると考えられます。

本記事における「施策」の定義を、設定したKPIを達成することを目的としたアクションとします。そのための具体的なアクションのひとつに「複数の意思決定の促進」が属しています。また、それに対して、意思決定の促進を目的とした有識者による一対一のアクションのことを「診断」と定義します。

複数の意思決定の促進を目的としたひとつの施策の設計を支援する手法の提案

課題の解決のために以下の手法を提案します。以前、Minimum Viable Product*3に基づき実用最小限の手法を考えました。この手法を具体化してフレームワークとして提案します。提案手法の概念図を以下に示します。

複数の反実仮想説明に基づく複数の意思決定の促進を目的とした施策の設計の概念図

前提として、いくつかの反実仮想、つまり“望ましい状態”へ状態が覆る特徴の変化例が生成されている状況であるとします。例として、n件の反実仮想が生成されているとします。はじめの処理として、n件の反実仮想をクラスタリングによって、k件のクラスタに分類します。それらをクラスタごとに要約します。本手法における、要約とは、ドメインによって異なるとは思いますが、大きく以下の2点を想定しています。

次の処理として、反実仮想の要約に基づき、有識者が施策を設計します。例えば、クラスタ毎の各特徴の変化例の基本統計量より、特定の特徴の変化例の中央値を確認し、これを元にKPIを設定します。そして、そのKPIを達成させるための施策を設計します。施策の数はクラスタの数と一致すると想定しています。

要約の手法としてクラスタリングを採用した理由を説明します。反実仮想説明において特徴の変化例の正負は重要です。それゆえ、要約の過程で、絶対値をとることや、単純に平均することは回避したいと考えます。そこで、反実仮想説明をクラスタリングします。これにより、要約のために基本統計量、特に平均値などを確認したとしても、反実仮想における特徴の正負が考慮されることになります。

このフレームワークにより、例えば生成したn件の反実仮想説明に対し、そのk件の反実仮想説明の要約が実現されます。そして、それに基づいて、施策の設計をすると、クラスタに特化した施策になります。これにより、クラスタに属する複数の人の意思決定の促進が期待されます。

提案手法の実装

提案手法の実装を紹介します。上述したフレームワークの要約までを対象とします。以下は提案手法をPythonの関数(summarize_cf)として実装した例です。入出力は以下のとおりとします。

  • 入力:DiCEにより生成される反実仮想説明群
  • 出力:反実仮想の要約群(入力に対してクラスタ列が付与)

また、DiCEで出力されるクラス(CounterfactualExplanations)を特徴の変化例で構成されるDataFrameに変換する関数(convert_to_diff_df)も用意します。

from sklearn.cluster import AgglomerativeClustering

def convert_to_diff_df(target_df, dice_exp):
  """
  CounterfactualExplanationsをDataFrameに変換する。
  """
  diff_dfs = []
  for i in range(len(dice_exp.cf_examples_list)):
    final_cfs_df = dice_exp.cf_examples_list[i].final_cfs_df
    test_instance_df = dice_exp.cf_examples_list[i].test_instance_df
    diff_df = final_cfs_df - test_instance_df
    diff_dfs.append(diff_df)
  diff_df = pd.concat(diff_dfs)
  diff_df.index = target_df.index.to_list()

  return diff_df

def summarize_cf(diff_df, n_clusters):
  """
  複数の反実仮想を要約するためにクラスタリングし、クラスタ列を追加する。
  """
  cluster_df = diff_df.copy()
  agglomerative_clustering = AgglomerativeClustering(n_clusters=n_clusters)
  labels = agglomerative_clustering.fit_predict(cluster_df)
  cluster_df["cluster"] = labels

  return cluster_df

上記のスクリプトを含め、本記事で紹介するスクリプトおよび関連するスクリプトのリンクを最後に載せています。

提案手法の有用性の検証

想定するシナリオ

検証のために活用例として想定するシナリオを仮定します。補足としての概念図を以下に掲載します。

提案手法が想定するシナリオの概念図

とある意思決定者群がいたとします。その群では“望ましい状態”になる傾向が高いか否かの2値で分類されるとします。それに加え、傾向は0〜1の範囲で確率としても表現が可能です。しかし、“望ましい状態”になる傾向が高いか否か、どうしたら“望ましい状態”になるのか、行動指針について当人たちは知りません。ただし、有識者に診断してもらうことで“望ましい状態”になるための助言を得たり、サポートを受けて、“望ましい状態”になる傾向を高めることができます。有識者のリソース(コスト)は限られており、診断の対象者が多くなるほど、双方にデメリットが生じます。そこで、提案手法を使うことにします。提案手法により、意思決定者群内の全員の状態を予測し、“望ましい状態”ではない意思決定者の反実仮想説明を生成し、それを要約します。その要約に対して、有識者と相談することで複数の意思決定の促進を目的としたひとつの施策の設計をします。また、シナリオの理解を容易にする目的で、有識者による診断コストと施策の設計コストを同一とします。診断コストと施策の設計コストはそれぞれ1とします。例えば、提案手法によりk件の施策を設計する場合、その施策の設計コストはk(1×k)となります。つまりk人の有識者が必要になるということになります。このシナリオは教育、医療、マーケティングなど様々な分野に当てはめることが可能です。是非、身近なドメインで読み替えてください。

つまり、以下の可能性が確認された場合、提案手法の導入が有用であったと判断できるとします。

  • 意思決定の促進数に対するコストの削減
  • 限られたコストの中での意思決定の促進数の増加

このシナリオに基づき、以下のリサーチ・クエスチョン(RQ)を設定し、これらの検証を通して有用性を確認します。

  • RQ1:クラスタの数を増やすことによりひとつの施策において参考になる特徴の数は厳選されるか?
  • RQ2:設計した施策は複数の意思決定を促進する可能性があるか?

提案手法の実施例

続いて、提案手法の実施例を紹介します。実行環境はGoogle Colaboratory*4プログラミング言語としてPythonを利用します。まずはDiCEをインストールします。

!pip install dice_ml

DiCEで反実仮想説明を生成するために、以下2点が必要です。

  • 学習データ/テストデータ
  • 学習済みモデル

まず、学習データ/テストデータを用意します。今回はsklearn.datasets.make_classificationにより、擬似データを生成します。説明変数は、feature_0、feature_1、feature_2…feature_19の20件、目的変数はlabel(1/0)とします。データ数は1,000件とします。

import numpy as np
import pandas as pd
from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import train_test_split

def generate_sample_df(feature_column_names, label_column_name, n_samples, n_classes,
                       n_informative=10, n_redundant=5, n_clusters_per_class=5, random_state=123):
  """
  サンプルデータを生成する。
  """
  n_features = len(feature_column_names)
  sample_classification = make_classification(
      n_samples=n_samples,
      n_features=n_features,
      n_informative=n_informative,
      n_redundant=n_redundant,
      n_clusters_per_class=n_clusters_per_class, 
      n_classes=n_classes,
      random_state=random_state
      )
  
  sample_df = pd.DataFrame(sample_classification[0], columns = feature_column_names)
  sample_df[label_column_name] = sample_classification[1]
  
  return sample_df

feature_column_names = [
  'feature_0', 'feature_1', 'feature_2', 'feature_3', 'feature_4',
  'feature_5','feature_6', 'feature_7', 'feature_8', 'feature_9', 
  'feature_10', 'feature_11', 'feature_12', 'feature_13', 'feature_14',
  'feature_15', 'feature_16', 'feature_17', 'feature_18', 'feature_19'
]
label_column_name = "label"
n_samples = 1000
n_classes = 2

sample_df = generate_sample_df(feature_column_names, label_column_name, n_samples, n_classes)
sample_df.head()
feature_0 feature_1 feature_2 feature_3 feature_4 feature_5 feature_6 feature_7 feature_8 feature_9 feature_10 feature_11 feature_12 feature_13 feature_14 feature_15 feature_16 feature_17 feature_18 feature_19 label
0 -6.1069 1.50221 -0.920145 3.11483 0.517572 0.0664958 0.819485 8.26875 -0.172542 -1.63748 0.67169 0.1841 -1.60933 -1.30478 1.82454 0.272891 2.42674 -1.60545 3.65572 -2.57617 0
1 2.90556 -2.39181 -1.98608 -0.291323 1.94349 0.609876 -0.70765 -0.493859 3.88505 -3.80109 -0.237092 -11.1492 -3.62402 4.17303 1.4179 1.71246 1.39182 -1.27753 -2.2001 2.04083 0
2 1.38131 -2.23358 0.193688 -2.10218 0.218239 1.67453 -0.932348 -4.75815 2.12282 0.527165 0.931531 -1.12455 -0.0708599 -0.475601 1.79064 0.0427529 -0.201005 -1.14527 -2.13361 0.40052 0
3 -5.76885 1.44654 -0.0165823 1.06346 -0.348609 -1.76193 -0.236788 -3.22219 0.408844 2.89314 0.830156 4.39721 -0.584138 -0.453076 -0.296942 -1.32787 -0.0741044 -3.36125 -0.484488 -1.93662 0
4 2.10656 -0.528755 -0.662955 0.217316 0.126619 -0.501721 -0.381227 3.60504 -4.00343 -1.6433 -0.833339 -0.451738 -1.32528 -1.19022 -0.282072 0.902531 1.10312 1.17115 -1.32348 -0.249233 1

参考までに、生成した擬似データの基本統計量は以下のとおりです。

sample_df.describe()
feature_0 feature_1 feature_2 feature_3 feature_4 feature_5 feature_6 feature_7 feature_8 feature_9 feature_10 feature_11 feature_12 feature_13 feature_14 feature_15 feature_16 feature_17 feature_18 feature_19 label
count 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000
mean -0.22679 -0.356719 -0.0218113 0.441077 -0.0120808 0.0240415 0.00697184 0.692381 -0.0892546 -0.37842 -0.0255278 -1.12954 0.0680271 0.182109 0.865859 -0.0673906 -0.011046 0.329891 -0.333647 -0.555261 0.501
std 4.65845 2.04645 2.09725 2.04333 0.98827 0.966302 1.02004 4.36257 2.0632 1.99052 1.02409 3.89122 2.2191 2.0807 1.85447 2.08003 1.0157 3.34635 2.24569 2.65902 0.500249
min -14.6509 -8.42079 -8.04211 -7.31673 -3.70133 -3.04058 -3.42982 -12.5212 -8.91695 -7.27698 -3.51781 -12.8647 -7.272 -6.03672 -5.4566 -6.25308 -2.97349 -10.4826 -8.35191 -9.11558 0
25% -3.10476 -1.65953 -1.45208 -0.883971 -0.696745 -0.578649 -0.662017 -2.13695 -1.35213 -1.74197 -0.657473 -3.71965 -1.56645 -1.16425 -0.364591 -1.45298 -0.715649 -2.01443 -1.8739 -2.40565 0
50% -0.334114 -0.450487 -0.00115219 0.54274 -0.015385 0.0260954 0.0292148 0.553981 -0.0622885 -0.392014 -0.0357425 -1.21894 0.0365768 0.328775 0.950246 -0.226534 0.007382 0.239435 -0.334767 -0.533561 1
75% 2.47047 0.925326 1.37644 1.82188 0.663336 0.64216 0.669061 3.55 1.15315 0.904647 0.66061 1.12373 1.64833 1.66251 2.02817 1.33499 0.673261 2.34194 1.19304 1.09123 1
max 18.888 7.00507 6.92699 7.08935 3.34537 3.34539 4.52377 14.9244 6.84834 5.7327 3.20739 11.6939 6.81684 6.88055 6.63172 6.97343 3.26358 16.5605 8.1032 8.86344 1

続いて、学習済みモデルを用意します。ここまでで用意した擬似データを学習データとテストデータに分割します。そして、学習データをモデルに学習させます。採用したアルゴリズムはロジスティック回帰です。scikit-learn*5により実装されているものを利用します。

X = sample_df.drop(columns="label")
y = sample_df["label"]

train_x, test_x, train_y, test_y = train_test_split(X, y, test_size=0.2, random_state=123)

model = LogisticRegression(random_state=123)
model.fit(train_x, train_y)

ここまでで、DiCEで反実仮想説明を生成するために必要な「学習データ(train_xtrain_y)/テストデータ(test_xtest_y)」と「学習済みモデル(model)」の用意ができました。

念のため、学習済みモデルの精度を確認します。ある程度の精度が担保されているモデルでない場合、生成される反実仮想に対する信頼性が失われてしまいます。精度の検証は、あらかじめ一つのデータを学習データ/テストデータに分割したホールドアウト検証とします。評価値としてROC曲線、AUCを算出します。

import matplotlib.pyplot as plt
import japanize_matplotlib
from sklearn.metrics import roc_curve

y_predict_proba = model.predict_proba(test_x)[:,1]
fpr, tpr, thresholds = roc_curve(test_y, y_predict_proba)

plt.plot(fpr, tpr)
plt.plot([0, 1], [0, 1], 'k')

plt.xlabel('偽陽性率')
plt.ylabel('真陽性率')
plt.title('ROC曲線')
plt.legend(["学習済みモデル", "基準"] , bbox_to_anchor=(1.05, 1), loc="upper left")
plt.grid()

# plt.show()

学習済みモデルのROC曲線

ROC曲線を確認した限り、おおよそ問題のない結果であると判断します。

from sklearn.metrics import roc_auc_score

auc = roc_auc_score(test_y, y_predict_proba)
auc
0.8513649136892814

AUCは約0.85と算出されました。こちらもおおよそ問題のない結果であると判断します。ROC曲線、AUCより、モデルは信頼できるものだと判断します。本来はドメインに応じて評価することが望ましいです。もし、問題が考えられる結果だった場合、問題が解消されるまでやり直すことが望ましいです。これ以降、テストデータにおけるラベルは未知の結果であるため、使用しません。

今回は“望ましい状態”の人を増やしたいという動機で反実仮想説明を生成します。つまり、“望ましい状態”でないと予測される人を対象とします。

import dice_ml
from numpy.random import seed


seed(123)

target_df = test_x.copy()
y_predict = model.predict(test_x)
target_df["label"] = y_predict
pre_counter = target_df.query('label == 0')
pre_counter = pre_counter.drop(columns="label")

続いて、DiCEにより生成される反実仮想説明群を生成します。

d = dice_ml.Data(dataframe = pd.concat([test_x, test_y], axis=1),
                 continuous_features=[], 
                 outcome_name = "label",
                 random_seed=123
                 )

m = dice_ml.Model(model=model, 
                  backend="sklearn")

exp = dice_ml.Dice(d, m, method='random')

dice_exp = exp.generate_counterfactuals(
    pre_counter,
    total_CFs= 1,
    features_to_vary=pre_counter.columns.to_list(),
    desired_class = 1,
    random_seed=123
)

diff_df = convert_to_diff_df(pre_counter, dice_exp)
diff_df = diff_df.drop(columns="label")

反実仮想の要約群(入力に対してクラスタ列が付与)を生成します。

n_clusters = 10
summarized_cf = summarize_cf(diff_df, n_clusters)
summarized_cf.head()
feature_0 feature_1 feature_2 feature_3 feature_4 feature_5 feature_6 feature_7 feature_8 feature_9 feature_10 feature_11 feature_12 feature_13 feature_14 feature_15 feature_16 feature_17 feature_18 feature_19 cluster
203 20.4505 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5
632 0 0 0 0 0 0 0 0 0 0 0 0 -5.71025 0 0 0 0 0 0 0 6
461 0 0 -3.75703 0 0 0 0 0 0 0 0 0 0 0 -0.720825 0 0 0 0 0 1
924 0 -4.99364 0 0 0 0 0 0 0 -2.8706 0 0 -6.7881 0 0 0 0 0 0 0 6
195 0 0 0 0 0 0 0 0 -5.20829 0 0 0 -5.71097 0 0 0 0 0 0 0 6

例えば、クラスタ1の要約(基本統計量)は以下になります。

target_cluster = 1
summarized_cf[summarized_cf["cluster"] == target_cluster].describe()
feature_0 feature_1 feature_2 feature_3 feature_4 feature_5 feature_6 feature_7 feature_8 feature_9 feature_10 feature_11 feature_12 feature_13 feature_14 feature_15 feature_16 feature_17 feature_18 feature_19 cluster
count 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6
mean 0 0 0 -0.225622 0 0 0 0 0 0 0 0 -0.929857 0 0 -0.456884 0 -9.41295 0 -0.78332 1
std 0 0 0 0.552659 0 0 0 0 0 0 0 0 2.27768 0 0 1.11913 0 1.68538 0 1.91873 0
min 0 0 0 -1.35373 0 0 0 0 0 0 0 0 -5.57914 0 0 -2.74131 0 -11.8436 0 -4.69992 1
25% 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -9.95383 0 0 1
50% 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -9.60744 0 0 1
75% 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -8.8791 0 0 1
max 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -6.71359 0 0 1

この要約に対して、例えば、中央値が0ではないcolumn_7はこのクラスタにおいて参考になる特徴であるという判断が可能になります。この判断からKPIとして意思決定者群のcolumn_7を7.721859(中央値)だけ変化させるなどという考案が可能です。

以上により、反実仮想の要約群が生成されます。続けて、予め設定した2つのRQに答える形式で、提案手法の有用性の検証をします。

RQ1:クラスタの数を増やすことによりひとつの施策において参考になる特徴の数は厳選されるか?

一般的に、参考になる指標の種類が少ないほど、比較的低いコストで、比較的高い精度での施策の設計が期待されます。提案手法では反実仮想をクラスタリングしてその要約を施策の設計の参考にします。この時、クラスタごとの要約で参考になる特徴が変化することが考えられます。つまり、クラスタリングによりひとつの施策において参考になる特徴が厳選されることが期待されます。またそのクラスタの数を増やすことによりより厳選されていくことが期待されます。これに対して、本当に厳選されているのかを確認します。ここでは、参考になる特徴の基準を広くします。クラスタにおいて、少しでも差が発生している特徴を指すこととします。逆に全く差が生じていない、基本統計量において、最小値と最大値が0の場合は参考になる特徴ではないとします。

クラスタの数の変化に伴う参考になる特徴の数の変化

縦軸が「参考になる特徴の数」、横軸が「クラスタの数」です。上記のグラフより、大まかにクラスタの数の増加に伴って、各クラスタにおける参考になる特徴の数が減少傾向にあることがわかります。つまり、クラスタリングによりひとつの施策において参考になる特徴の数は厳選されることがわかります。そしてクラスタの数を増やすことで、参考になる特徴の数はより厳選されることがわかります。各クラスタにおいて対応すべき問題が単純になっていると考えられます。つまり、比較的低いコストで、比較的高い精度での施策の設計が期待されます。

この結果が見られた原因として、クラスタリングにより各クラスタにおけるレコードの数の減少が予想されます。参考までに「クラスタの数の変化に伴う各クラスタに属するレコードの数の変化」を確認します。

クラスタの数の変化に伴う各クラスタに属するレコードの数の変化

予想通り、クラスタの数が増えるに伴い、レコードの数が減少しています。

これにより、提案手法により、比較的低い労力で、比較的高い精度の施策の設計が期待されます。

RQ2:設計した施策は複数の意思決定を促進するか?

次に設計した施策が複数の意思決定を促進するかを確認します。現在の手法では施策の質については有識者の力量次第であり不確実な情報です。それゆえ、シミュレーションを設計し、これに基づき検証をします。シミュレーションにおける施策の設計方法を以下のように定義します。

  • 施策の設計方法
    • 反実仮想の要約より参考になる特徴の条件は「中央値が0ではない」と設定
    • 複数に絞り込まれた参考になる特徴からt件をランダムに選択
    • 施策による特徴の変化量は反実仮想の要約より中央値と変化率cを掛け合わせた結果と設定
    • 各意思決定者に対して成功率pで施策が成功(特徴が変化)

上述した条件に従い、シミュレーションを実施します。シミュレーションでは施策の質を変化させて結果を確認します。シミュレーションにおける施策の質を表現する要素(パラメータ)とそのデフォルトとする基準値は以下の通りです。

  • 参考になる特徴の数(基準値:1)
  • 施策の成功率(基準値:0.5)
  • 施策の特徴の変化率(基準値:0.5)

シミュレーションの理解を容易にするために、施策と比較するための有識者による診断の定義を「確実に“望ましい状態”に変化させること」と設定します。施策に対する診断の質の高さを表現しています。

はじめに、参考になる特徴の数の変化に伴う意思決定が成功した件数の変化を確認します。以下に可視化した結果を示します。

施策における参考にする特徴の数の変化に伴う意思決定が成功した件数の変化

縦軸が「意思決定が成功した数」、横軸が「クラスタの数(有識者・施策の数)」です。参考になる特徴の数を変化させて描画させています。また比較対象として「有識者による診断(基準)」をも描画します。参考になる特徴の数を1から3まで変化させたものの、結果は全て変わらず、重なりました。クラスタの数の変化により意思決定が成功した件数が上昇していますが、今回の条件では有用になる場合がないことがわかります。

続いて、施策の成功率の変化に伴う意思決定が成功した件数の変化を確認します。以下に可視化した結果を示します。

施策における成功率の変化に伴う意思決定が成功した件数の変化

以下の条件で基準以上になっています。

これは、今回の条件で、有用になる場合があることがわかります。

最後に、施策の特徴の変化率の変化に伴う意思決定が成功した件数の変化を確認します。 以下に可視化した結果を示します。

施策における特徴の変化率の変化に伴う意思決定が成功した件数の変化

以下の条件で基準以上になっています。

これは、今回の条件で、有用になる場合があることを意味します。

以上より、条件によっては基準、つまり診断以上の効果が見られるという結果となり、提案手法が有用である可能性を確認しました。具体的には同一コストで意思決定の促進が成功した件数が1〜16件(特徴の変化率が1.0/クラスタの数が8の場合)だけ増加しました。これは、言い換えると、同じ数の意思決定の促進を成功させるために必要なコストが1〜16件(特徴の変化率が1.0/クラスタの数が8の場合)だけ減少したことを意味します。つまり、「設計した施策は複数の意思決定を促進するか?」の回答として、「是」である可能性が示唆されました。

以上より、提案手法の有用性が確認されました。

今後の課題と展望

今後の課題と展望について紹介します。最も課題だと感じている、今後の実施が望ましいこととしてより詳細なシミュレーションの設計、もしくは実証実験が挙げられます。有用性の検証では、シミュレーションを実施しましたが、本来の問題はより複雑で、不確実な点があります。また、施策の質を表現する数値も仮に設定したものです。これらは実社会との差があると考えられます。それゆえ、より詳細なシミュレーションの設計が必要になります。もしくは、提案手法を社会に実装した際、それが本当に有用なのかを検証する必要があります。特に提案手法における反実仮想の要約を有識者に伝える際、それが使い物になるのかの検証は大事です。ドメインによって新たな課題も浮かび挙げられます。以上より、実証実験の実施をしたいのですが、これ以上の個人での実施は難しいため、諸々考える、工夫する必要があります。他にも反実仮想の要約から施策を設計する段階についての議論も必要です。そして、設計する施策の評価についての議論も必要です。

本記事のまとめ

本記事では、複数の反実仮想説明に基づく複数の意思決定の促進を目的としたひとつの施策の設計を支援する手法を提案しました。そして、仮に設定したシナリオに基づくシミュレーションにより有用性を検証しました。その結果、提案手法が対象とする特定の条件において、「複数の意思決定の促進を目的としたひとつの施策の設計を支援する」という点での貢献が期待できます。

本記事は追記、修正する可能性があります。ご了承ください。もし意見、質問、指摘などがあれば、以下に記載されている連絡先に連絡をいただけるととても嬉しいです。

docs.google.com

本記事に関するスクリプトは以下で公開しています。

gist.github.com

ありがとう2021年

これは何?

12月28日、2021年の仕事を納めました。来年に向けて、2021年を“ざっくり”と振り返ります。

“ざっくり”といえば、好きだったざっくりシリーズ、いつの間にかYouTubeチャンネルが開設されていました。2021年に再会しました。オススメです。

www.youtube.com

2021年

イノベーションを生み出すためにはとにかくいろんなことにチャレンジしないと!」というモチベーションで自らの興味の赴くままにいろんなことをしました。特に今年は本当にたくさんの書籍を読みました。「シン・ニホン AI×データ時代における日本の再生と人材育成」が読書をはじめるきっかけになりました。

この時代の日本で、どのようにデータ活用をしたらいいのか、それがいかに難しいのかなどを把握することができました。特に、機械学習という技術と社会実装とのハードルの高さを感じることができました。

「意思決定分析と予測の活用 基礎理論からPython実装まで 」と「施策デザインのための機械学習入門〜データ分析技術のビジネス活用における正しい考え方」で機械学習を使用する目的が「精度の高い予測をすること」ではなく「意思決定を促すこと」であると再認識しました。

機械学習を解釈する技術〜予測力と説明力を両立する実践テクニック」と「Interpretable Machine Learning」(日本語訳版)では機械学習の説明性について背景から手法までを学びました。

hacarus.github.io

説明可能性の文脈で言われている手法に限らず、予測の根拠を提供するというのはサービスとして良いのではないかと考えていました。そんな背景もあり、学生時代の研究で使っていたアソシエーションルールマイニングという手法への再評価をしていました。

daikikatsuragawa.hatenablog.com

daikikatsuragawa.hatenablog.com

そして、説明可能性に関連して出会えた、現状を覆すサンプルを提供する「反実仮想説明」にとても興味を持ちました。

daikikatsuragawa.hatenablog.com

「意思決定分析と予測の活用」では理論による意思決定のモデル化を解説しています。また、「施策デザインのための機械学習入門」では反実仮想というアイデアに基づき、意思決定を促す施策の評価手法について解説しています。そして「機械学習を解釈する技術〜予測力と説明力を両立する実践テクニック」と「Interpretable Machine Learning」でも紹介されているように意思決定を促す、結果に納得してもらうための手法があります。これらが「シン・ニホン」で挙げられたような課題を解決するヒントになったりしないかなと感じました。

まあ、とにかくいろんなことをやりました。

2022年

「「すぐやる人」と「やれない人」の習慣」という書籍があります。

この書籍ではゴールを設定してそれに向かって取り組む「逆算思考」、興味があるからやる「積み上げ思考」が紹介されています。その「積み上げ思考」に重きを置いた一年となった気がします。準備の年でした。それにより、逆算して取り組みたいと思えるゴールも見えて来ました。来年はやります。やる年。

現在は機械学習エンジニアとして研究開発に近いことをしています。とてもやりがいがある上、裁量のあるとてもありがたい環境です。せっかくのこの環境で成果を出すことを一番の目標としたいと思います。そして、この環境のうちにできることを試したいと考えています。

2022年は寅年です。「虎穴に入らずんば虎児を得ず」な感じでいきましょう。「虎の威を借る狐」、いや、虎になりましょうか🐯