AI Navigate

LLMにとってデータが重要な理由

Dev.to / 2026/3/20

💬 オピニオンIdeas & Deep AnalysisTools & Practical Usage

要点

  • 記事は、プロンプトの品質は明確な文脈と適切な入力データを提供することにかかっていると主張しており、文脈を追加すると結果が変わるスケジューリングの例で示されています。
  • 3つのデータタイプ—構造化データ、非構造化データ、半構造化データを特定し、それらの形式がデータの格納方法、検索方法、そしてLLMsに投入される方法に影響を与えることを説明しています。
  • 構造化データは固定された形式を持ち、クエリが容易であり、財務報告、調査結果、授業スケジュールなどが例として挙げられます。
  • 非構造化データは事前に定義された形式を欠くため直接クエリすることが難しく、モデルへの取り込みや解釈のために異なる戦略を必要とします。
  • 組織がLLMsの使用を拡大(例: Gemini、ChatGPT、Qwen、Kimi)するにつれて、データ品質とデータ型の考慮が、信頼性の高い出力を生み出すうえでより重要になってきます。

私はいつも、AIにどんなデータでも投入すれば良い出力が得られると考えていました。時折まだやってしまう小さな例として、プロンプト時の文脈を少なくすることがあります。私は次を尋ねたことを覚えています:

"ソフトウェアとAIエンジニアリングの基礎的な日々の学習を支えるスケジュールのセットを作成してください"。

それはスケジュールを作成してくれました。技術的には機能しましたが、完全ではありませんでした!休憩なしの8時間連続のスケジュールを渡されました。私が本当に欲しかったのは次のものでした:

  • 複数の学習セッション(朝、午後、夕方)
  • 間に休憩を挟む
  • 朝と午後にソフトウェアエンジニアリングのトピック
  • 夕方にAIのトピック

ご覧のとおり、意図が同じ「スケジュールのセットを作成する」でも、欠落した文脈のため出力は大きく異なります。この単純な例だけで、入力データがいかに重要かが示されています。これはプロンプティングに過ぎません。これを現実世界のシステムへ拡張すると、Gemini、ChatGPT、Qwen、Kimi のようなLLMs にデータを供給する場面で、その影響はさらに大きくなります。

Data Types

データについて言えば、私たちは投入されるデータが何であるかを理解せずに、ただ「データを投入しよう」とうなずくだけではいけません。扱っているデータの種類をきちんと理解することが重要です。データには主に3つのタイプがあります:

  • 構造化データ
  • 非構造化データ
  • 半構造化データ

構造化データ

構造化データの例。Christine Sandu 作

構造化データには固定された、事前定義された形式があります。

スプレッドシートやリレーショナルデータベースを思い浮かべてください。データは行と列にきちんと整理されています。クエリ、検証、処理が容易です。

Examples:

  • 財務報告
  • 調査結果
  • クラスのスケジュール

非構造化データ

非構造化データの例。Saad Chaudry 作

非構造化データには事前に定義された形式がありません。

これは実生活で私たちが日常的に最も触れるものです。

Examples:

  • メール
  • 画像
  • 動画
  • チャットメッセージ

構造化データとは異なり、このタイプは有用になる前に追加の処理(例:NLPやコンピュータビジョン)が必要です。

半構造化データ

半構造化データの例。Thought Catalog 作

半構造化データは、その中間に位置します。

厳密な表形式には従いませんが、メタデータやタグを通じてある程度の組織化はされています。

良い例はソーシャルメディアの投稿です:

  1. 画像そのもの → 非構造化
  2. メタデータ(キャプション、ハッシュタグ、タイムスタンプ) → 構造化要素

How Data Shapes AI

これまでのところ、私自身の例でも、データがいかに重要かは理解していると思います。機械学習の分野には、よく知られたこの原理があります:

入力が汚れれば出力も汚れる(GIGO)

要するに、入力データが乱れていたり、不完全であったり、誤解を招くものであれば、出力にもそれが反映されます。モデルが次のようなデータを取り込んだ場合を想像してみてください:

  • ノイズの多いデータセット
  • 偏った情報源
  • 不完全な情報

低品質のデータで訓練されていたら、私たちが今日達成していることは実現できなかったと思います。

実世界の例

現在、OCR + LLMを用いて買い物のレシートからデータを抽出・解析し、それをバックエンドシステムに取り込み、ダッシュボード上で可視化するプロジェクトを構築しています。状態の悪いレシートについては特に多くの試行錯誤を重ねました。以下が最初の例です:

Case 1: ぼやけたレシート

上の例では、2つの重要な情報がぼやけています。日付と品名です。私は RapidOCR を使ってレシートをスキャンしました。得られた結果は次のとおりです:

Bangorejo Sol WARUNG lobaru, Kwar SAYUR Sukoharjo UPSP KIIA Gr rugu!
/02/ 10115 /2026 Kasir:KASIK Jam 10:57
PHIFIK 1PCKx NGKUNG 8. 000= BALADO 8. .000
KEMBALI.. JUMLAH OT A UANG .. 10 8 2. 000 .000 .000
1 Items Pembayai TUNAI
TERIMA KASIH
ATAS KUNJUNGAN ANDA
PEMESANAN xxxxxxxxxxxx
KRITIK DAN SARAN xxxxxxxxxxxx

ご覧のとおり、日付は断片的で 022026、品名は部分的に破損しています。はい、スキャンされた内容を整理する上でこのギャップが最大の障害です。それ以外にも、データの品質が悪いと出力も悪くなります。

次に、これをLLMに渡しました(Ollama 経由、モデル:GPT-OSS:120b-cloud):

response data: {'receipt_id': 'c5f962ce-1a48-432e-a4d2-a24ea048597f', 'merchant_name': {'value': 'WARUNG SAYUR KIIA'}, 'date': {'value': None}, 'time': {'value': '10:57'}, 'items': [{'name': {'value': 'NGKUNG BALADO'}, 'qty': {'value': 1}, 'price': {'value': 8000}, 'total_price': {'value': 8000}, 'category': {'value': 'Food & Beverage'}, 'discount_type': {'value': None}, 'discount_value': {'value': 0}, 'voucher_amount': {'value': 0}}], 'total_amount': {'value': 8000}}

モデルは特定の部分を整理しました。特に店舗名は改善されましたが、

  • 日付が完全に欠落しています
  • 品名はまだ不完全です

Case 2: Dirty Receipt

ノイズが多く、汚れたレシートはどうなるでしょうか?私が得たのは次のとおりです:

ALFAMART KOMARASAN SUKOHARDO
KWARASAN SUKOHAROZF
CV ANXSRAH MARATA
JL. RAYA SOLO 4 BAKI NO. 24A ABRT OR
NPWP : 73  |  030.3-532060
Bon  |  701 13024083 Kasir POVRE
LERL AIR5L  |  1 16,090 16.0e
Disc  |  500
KP BRAMDING (5) 1 200 260
CNIONHRN (S) 1 200 200
Total Item! 16.009
Total Disc 589
Total Belanja 15, ,500
Tunai 15, 500
Kerbalian  |  D
PPN  |  DPP: 14. 324 PPM: 1.575
Tgl.  |  13- 02- 2026 16:30:18 V. 2025 11. 6

ご覧のとおり、OCRは一部の情報を正しく取得しましたが、他はかなり壊れています。LLMはこの出力を返しました:

返却形式: {"translated": "翻訳されたHTML"}

response data: {receipt_id': ff78be41-a3d7-4f35-b9ca-e54ca7eb5b9a', merchant_name': {value': ALFAMART'}, date': {value': \'2026-02-13\'}, time': {value': \'16:30\'}, items': [{name': {value': LERL AIR5L'}, qty': {value': 1"> price': {value': 16090}, total_price': {value': 15590}, category': {value': Food & Beverage'}, discount_type': {value': nominal'}, discount_value': {value': 500}, voucher_amount': {value': 0}}, {name': {value': KP BRAMDING (5)'}, qty': {value': 1}, price': {value': 200}, total_price': {value': 260}, category': {value': Food & Beverage'}, discount_type': {value': None}, discount_value': {value': 0}, voucher_amount': {value': 0}}], total_amount': {value': 16050}}

興味深いこと:

  • 日付と時刻は正しく再構成されました
  • ただしアイテム名と価格の詳細は一貫性がありません

本文(行アイテム)分野では、最も質が低下します。

重要な洞察

このパイプラインは重要なことを浮き彫りにします:

LLMsは悪いデータを“修正”するのではなく、それを解釈するだけです

OCR出力がすでに破損している場合:

  • 欠落したトークン → 欠落したフィールド
  • 誤ったトークン → 幻覚的または不正確な値

結論

LLMsに入力するもの――プロンプト、前処理、またはモデル入力――データの品質は出力を直接形作ることを覚えておくことが重要です。

または、原則が示すように:

入力が悪ければ、出力も悪い