こんにちは。株式会社アシッドハウスの芦田哲也です。
ネットを見ていると「AIで自動化したら事故が起きた」「AIが勝手に送信してしまった」のような話を見かけませんか？
自分の会社でそんなことが起きたら困る。だから本番の前にしっかり試しておきたい。
でもどこまで試せば安心なのかが分からない。念のためにと試す件数を増やしていくと試運転だけで何日もかかる。いつまでたっても本番に入れない。
このままだと試すこと自体が仕事になりAIを入れた意味がなくなります。逆に試し方の型を決めておけば少ない件数で安心して本番に入れます。
そこでこの記事では本番の前にAIを試す方法を説明します。読み終わるころには何をどれだけ試せば本番に入っていいかを決められます。
結論を言うと件数を増やすのではなく種類を分けて少しずつ試してください。
AIのテストは何件やればいい？
同じような書類を100件試しても分かるのは「その種類の書類なら大丈夫」ということだけです。見たことのない種類の書類が来たときにどうなるかは分かりません。
逆に種類ごとに数件ずつ試せばどの種類でつまずくかが早く見えます。たとえば3つの種類を3件ずつ試す。つまずいた所を直してもう一度試す。これで100件を一度に流すより早く問題の場所が分かります。
つまりこういうことです。
試運転で確かめるのは「件数」ではなく「種類」です。
本番の前に試す3つの種類
- いつもの種類：毎日いちばん多く来るもの。ここで正しく動くことを確かめる
- ちょっと変わった種類：書き方が違う・項目が欠けているなど。ここでおかしな結果を出さずに止まるかを確かめる
- やってはいけない種類：お客さんへの送信や支払いなど、取り消せない操作に関わるもの。ここで勝手に進まず人に確認を求めるかを確かめる
3つ目は特に大事です。正しく動くことより止まるべき所で止まることのほうが会社を守ります。
本番の前に決めておく2つのこと
- 元に戻せるようにしておく：本番で動かす前に元のデータを複製しておく。失敗しても戻せれば怖くありません
- 同じ失敗が続いたら止める：同じ所で2回続けて失敗したら、それ以上くり返さずに止めて頼み方を見直す
失敗を何度もくり返せる仕組みは事故を何度も起こせる仕組みでもあります。止まる条件を先に決めておいてください。
ちょっと考えてみてください。今AIに任せようとしている仕事でいちばん困る失敗は何でしょうか？ その失敗が起きないかを確かめる試運転を、まず1件やってみましょう。
取るべき行動：任せたい仕事について「いつもの・ちょっと変わった・やってはいけない」の3つの種類を書き出し、それぞれ2〜3件ずつ試してください。元のデータは先に複製しておきます。種類で試せば試運転は終わりの見えない作業から、数時間で本番に入れる準備に変わります。
これからの大事なキーワードは『種類で試す』です。
Hi, I'm Tetsuya Ashida of ACIDHOUSE, INC.
Have you seen stories online like "an accident happened after we automated with AI" or "AI sent something on its own"?
You'd be in trouble if that happened at your company. So you want to test thoroughly before going live.
But you don't know how much testing is enough to feel safe. Keep adding test cases "just to be sure," and the trial run alone takes days. You never get to go live.
If this continues, testing itself becomes the job and there's no point in having brought in AI. But if you decide on a pattern for testing, you can go live with confidence after only a few cases.
So in this article I'll explain how to test AI before going live. By the end you'll be able to decide what to test, and how much, before you go live.
The bottom line: don't increase the number of cases. Split them by type and test a few of each.
How many cases should you test AI with?
Test 100 similar documents, and all you learn is "it's fine with that type of document." You still don't know what happens when a type of document it's never seen arrives.
On the other hand, test a few of each type and you quickly see which type it trips on. For example, test three cases each of three types. Fix where it tripped and test again. That finds the problem faster than running 100 cases at once.
In other words:
What a trial run checks isn't "how many." It's "what kinds."
3 types to test before going live
- The usual type: what comes in most often, every day. Here, check that it works correctly
- A slightly unusual type: written differently, missing fields and so on. Here, check that it stops instead of producing strange results
- The type it must not act on: anything involving actions that can't be undone, like sending to customers or making payments. Here, check that it doesn't proceed on its own and asks a person to confirm
The third is especially important. Stopping where it should stop protects your company more than working correctly does.
2 things to decide before going live
- Make it reversible: copy the original data before running it live. If you can roll back after a failure, there's nothing to fear
- Stop when the same failure repeats: if it fails at the same point twice in a row, stop instead of repeating it, and rethink how you're asking
A system that can repeat a failure over and over is also a system that can cause accidents over and over. Decide the conditions for stopping first.
Think about it for a moment. In the work you're about to hand to AI, what's the failure that would hurt most? Start with one trial case that checks whether that failure happens.
What to do: For the work you want to delegate, write down three types, "usual, slightly unusual, and must not act on," and test two or three cases of each. Copy the original data first. Test by type, and a trial run goes from work with no end in sight to a few hours of preparation before going live.
The key phrase from here on: "test by type."