さほど昔ではないが、私のシステムは限界に達した。
それは衝突ではなかった。信頼の問題だった。クライアントのデータセットが取り込まれた際、システムは整理された構造ではなく、重複だらけの混乱した状態を生成しました。同じ組織がナレッジグラフに3回登場したのは、ソースデータで使われていた名称表記が「McKinsey & Company」「McKinsey and Company」「Mckinsey」という3つの異なる命名規則に従っていたためです。人間から見れば、これらは明らかに同一のエンティティです。グラフにとって、それは3つの別々のノードであり、3つの互いに接続されていない関係のセットであった。真実の3つの並列版。
それが、私がデータを単に保存するものとしてではなく、設計するものとして捉え始めた瞬間でした。
すべては、スキーマが示唆するよりも複雑である
人間が生成したデータを処理するシステムを開発する際に、誰も教えてくれないこと：人間は非常に一貫性がない。そして、私はそれを魅力的な意味で言っているのではありません。あなたの思考の枠組みが前提とするすべての仮定を崩壊させるような意味で言っています。
1人の人は「Python」と書く。他の人は「Pythonプログラミング言語」と書く。3人目は「python」と小文字で書く。単純な文字列比較では、これらは完全に異なる4つのエンティティである。4つのノード。グラフに4つの嘘がある。
この問題を解決しようとしたわけではなく、ただクリーンなデータパイプラインを構築したかっただけです。しかし、パイプラインが人間のデータを処理する場合、この混乱 こそ が問題となる。他はすべて下流にある。
視覚的階層構造をエンジニアリングプロトコルとして
技術的なアーキテクチャの詳細に入る前に、エンジニアが十分に議論していない事柄について提案させてください。「情報がどのように見えるかは、それが含む内容と同様に重要である」
構造化されたレポートやダッシュボードを一目見た瞬間、脳は3秒未満で心理モデルを構築します。あなたは直感的に、主要なデータがどこにあるか、そして各セクションの相対的な重要性を理解しています。これは「デザイン」ではなく、データ通信プロトコルです。
データの提示方法は、それに基づいて下される判断に影響を与える。情報を構造化するシステムを構築する際、スキーマの正しさだけを考慮することはできません。私は「知覚的な重み」について考えなければならない。人間の目はどこに最初に落ちるのか？どのようにして、レンダリングエンジンが実際に処理できるデータ構造にそれらの優先順位をエンコードしますか？
知識グラフ：関係こそがデータ
データベーステーブルは事実を格納します。ナレッジグラフは意味を保存する。
私のグラフでは、すべての情報がノードですが、実際の知性はエッジにあります：
- HAS_属性: エンティティとその特定の文脈的な属性を結びつける。
- BELONGS_TO: レコードを、独自のプロパティと関係を持つ親組織に関連付けます。
- REQUIRES：プロジェクトまたはレコードを、それに関わる特定の技術やスキルに接続する。
データがこうして結びつけられるとき、それは単なるリストではなく、物語となる。それは構造から自然に生じるものであり、特別な「物語生成」コードを書く必要はない。関係性こそが物語そのものである。
データ密度：制約こそが特徴である
私は「データ密度」、つまり視覚的な空間あたりの意味のある情報量に魅了されています。密度の高いドキュメントとは、ごちゃごちゃしているものではなく、すべての要素がその位置にふさわしいものである。私のシステムでは、密度は厳格な構造的制約によって強制されます。
- カテゴリごとの項目数: 5：47の属性をリストアップしていません。あなたが重要だと思う5つを挙げてみてください。制約が優先順位付けを強制する。
- summary_max_sentences: 2文それです。それが何か、そしてなぜそれが重要かを述べよ。他はすべてノイズである。
- forbidden_filler_phrases: 実際の検証ロジックを実装し、“best-in-class” や “synergy” のような空虚な語句を除外。無意味な語句はスペースを占有し、情報を伝えない。
標準化のスタック：誰も見えない配管
その「McKinsey」の問題を解決するために、データの整合性を確保するため4層のスタックを組みました。
- 正規化： 取り込み時に名前をクリーニングし、冗長な接尾辞を削除する。
- Fuzzy Deduplication: 0.82 の類似度閾値を使用—「Docker Container」や「Docker」を検出できるほど高く、しかし「Go」や「Git」を別々に保つ程度に低く設定。
- Deterministic IDs: 各ノードは内容から導出された ID を取得（例: attr_python）。同一の乱雑な入力を二度処理しても、同一のクリーングラフが得られる。
- 変異エンジン： データの出所（プロベナンス）を失うことなく、更新や修正を処理するディスパッチシステム。
失敗から学んだこと
このシステムは、成功以上に多くのことを教えてくれる形で失敗した。かつて「機械学習」と「機械操作」は高い類似スコアを共有していたため、マージされました。その失敗は、「構造的に有効」と「意味的に有意義」の間の大きな隔たりを私に教え込んだ。
私は自動抽出を信頼できない入力として扱うことも学びました。今では、システムが「幻覚」のように聞こえるが実際には存在しないレコードを生成しないよう、ノイズパターンフィルターを使用しています。
結論
情報のアーキテクチャは、信頼のアーキテクチャである。データが正規化され、意味的にリンクされると、人々は出力を信頼する。孤児や重複だらけの場合、物質性は問題にならない。
仕事は単にコードを書くことではなく、カオスをクエリ可能なものに変換することです。ノイズを知識に変えるには、単なるストレージでは不十分です。あなたはアーキテクチャが必要です