最近、システムが限界に達した。
クラッシュではなかった。信頼性の問題だった。クライアントのデータセットが取り込まれるのを見て、整理された構造ではなく、システムは重複の混乱を生み出した。同じ組織が知識グラフに3回出現した。ソースデータは3つの異なる命名規則を使用していたからだ:「McKinsey & カンパニー」、「McKinsey アンド カンパニー」、そして*「マッキンゼー」*。人間には明らかに1つのエンティティだが、グラフにとっては3つの別々のノードで、3つの関係のセットが断絶していた。同じ真実の3つの並行バージョン。
それが、私がデータを単に保存するものではなく、設計するものとして考えるようになった瞬間だった。
スキーマが示唆するよりもすべてが混沌としている
人間が生成したデータを処理するシステムを構築するときに、誰もが準備してくれないこと:人間は非常に一貫性がなく、つまり、スキーマが作るすべての仮定を破壊する。
1人の人間が「Python」と書く。別の人間が「Python プログラミング言語」と書く。3人目が「python」と小文字で書く。ナイーブな文字列比較では、これらは4つの完全に異なるエンティティである。4つのノード。4つのグラフの嘘。
私はこの問題を解決しようとしていなかった。ただ、クリーンなデータパイプラインを構築したかった。だが、パイプラインが人間のデータを取り込むとき、この混沌が問題である。ほかはすべてダウンストリームだ。
視覚的階層としてのエンジニアリングプロトコル
技術アーキテクチャに深く踏み込む前に、エンジニアが十分に話し合っていないものについて議論したい:情報がどのように見えるかは、どのような内容であるかと同じくらい重要である。
整理されたレポートやダッシュボードを見たとき、脳が3秒以内に精神モデルを構築する。直感的に、重要なデータがどこにあるか、各セクションの相対的な重要性を知る。これは「デザイン」ではない。データ通信プロトコルだ。
データを提示する方法は、人々がそれから下す決定を形作ります。当システムを構築する際、スキーマの正しさだけを考えることはできません。認知的重みを考える必要があります。人間の目は何に最初に焦点を当てるのか。どのようにしてそれらの優先順位をレンダリングエンジンが実際に作用できるデータ構造にエンコードするのか。
ノードグラフ:関係がデータである
データベーステーブルは事実を格納します。ノードグラフは意味を格納します。
私のグラフでは、すべての情報はノードですが、実際の知能は辺にあります:
- HAS_ATTRIBUTE:エンティティをその特定の、状況依存のプロパティにリンクします。
- BELONGS_TO:レコードをその親組織に結び付けます。その親組織には独自のプロパティと関係があります。
- REQUIRES:プロジェクトまたはレコードを関連する特定の技術またはスキルに接続します。
データがこのようにリンクされると、リストではありません。物語です。構造から自然に生まれるので、「物語生成」コードを特別に書く必要はありません。関係が物語です。
データ密度:制約が特徴である
私はデータ密度に執着しています。視覚的空間の単位あたりの有意義な情報を意味します。密度の高いドキュメントは、混雑したものではありません。各要素がその位置を正当化するものです。私のシステムでは、密度は厳格な構造的制約を通じて強制されます:
- items_per_category: 5:47 の属性をリストアップするのではなく、重要な 5 つをリストアップします。制約は優先順位付けを強制します。
- summary_max_sentences: 2:2 文です。それだけです。何であるか、そしてなぜ重要かを述べます。その他はノイズです。
- 禁止されたフレーズ: 「最高レベルの」 または 「シナジー」 などの空の単語を拒否する実際のバリデーションロジックを書きました。これらはスペースを占有し、何も伝えません。
標準化スタック:見えない配管
その「McKinsey」問題を解決するために、データの完全性を確保するための4層のスタックを構築しました:
- 正規化: 取り込み時に名前をクリーンアップし、冗長なサフィックスを削除します。
- ファジーディュプレケーション: 0.82 類似性しきい値を使用して、「Docker コンテナ」と「Docker」をキャッチするのに十分高いですが、「Go」と「Git」を別々に保持するのに十分低い。
- 決定論的ID: 各ノードにコンテンツから派生したIDが割り当てられます(例: attr_python)。同じ汚れた入力を2回処理して、1回クリーングラフを取得します。
- ミューテーションエンジン: データの出所を失うことなく更新と修正を処理するディスパッチシステム。
失敗から学んだこと
このシステムは、成功よりも多くを教えてくれた失敗を経験しました。高い類似性スコアを共有していたため、「マシーンラーニング」と「マシーンオペレーション」をマージしました。その失敗は、「構造的に有効」と「意味的に有意義」の中にある巨大なギャップを教えてくれました。
自動抽出を信頼できない入力として扱うことも学びました。現在、ノイズパターンフィルタを使用して、システムが存在しないが妥当なレコードを「幻想」しないようにしています。
結論
情報のアーキテクチャは信頼のアーキテクチャです。データが正規化され、意味的にリンクされている場合、出力は信頼されます。孤立したデータや複製が含まれている場合、内容は重要ではありません。
この仕事は単にコードを書くことだけではなく、混沌を問い合わせ可能なものに変えることである。ノイズを知識に変えるのであれば、単にストレージが必要なだけでなく、アーキテクチャが必要である