เวลาในการอ่าน: 12 minutes

ฉันไม่ได้จ้าง LLM แต่ฉันจ้างผู้ทำข้อมูลนิรนาม ก่อนที่จะทำ RAG pgvector ก่อนที่จะ fine-tune ผู้เชี่ยวชาญ CDA/FPA ก่อนที่จะจัดสรร workspaces ให้ลูกค้า — ต้องมีใครสักคนมาทำความสะอาด "ห้องน้ำ" ของข้อมูล พนักงานคนนี้ก็คือผู้เชี่ยวชาญด้านการทำข้อมูลนิรนาม (MVP0, EPIC 2 ของ codebase-gradle) และเขาคือคนที่ทำให้ผลิตภัณฑ์นี้สามารถทำตลาดได้

ปัญหาที่ทำให้ทุกคนวิ่งหนี

สตาร์ทอัพ AI ทุกรายที่จัดการข้อมูลสำหรับเทรนนิ่งต่างต้องเผชิญกับปัญหาเดียวกันคือ:

----
Données brutes client (SPG, cours, évaluations)
  ├→ Noms de stagiaires en clair dans les PDF
  ├→ Emails dans les métadonnées JSON
  ├→ IP de connexion dans les logs pgvector
  ├→ Identifiants dans les nœuds Graphify
  └→ Références OF pilote dans les schémas SQL
----

ผลลัพธ์คือ: ไม่ว่าคุณจะทำ RAG บนข้อมูลที่สกปรก (การหลอนของ PII, การไม่ปฏิบัติตาม RGPD, ความเสี่ยงทางกฎหมาย) หรือคุณจะไม่ทำอะไรเลย (ไม่มีผลิตภัณฑ์) ซึ่งทางเลือกที่สาม — การทำความสะอาดด้วยมือ — นั้นไม่สามารถขยายขนาดได้ (not scalable)

คำตอบของฉันคือ: อย่าเลี่ยงปัญหา L'**ทำให้เป็นอัตโนมัติ**โปรดระบุข้อความที่คุณต้องการให้แปลครับ

== MVP0 : l'Anonymiseur, พนักงานคนแรกที่จ้างในช่วงทดลองงาน

MVP0 ไม่ใช่ฟีเจอร์ แต่มันคือ**ผู้เชี่ยวชาญด้านสินค้าโภคภัณฑ์**— พนักงานที่คอยทำงานสกปรกแบบซื่อบื้อและใจร้าย ซึ่งไม่มีใครอยากพูดถึงใน pitch decks

สิ่งที่มันทำ:

[source]
----
ENTRÉE : Données brutes multi-sources
  ├→ AsciiDoc (SPG_A2SP.adoc) → noms, dates, OF pilote
  ├→ JSON (catalogue formations) → emails, téléphones
  ├→ YAML (config workspace) → tokens OAuth2
  ├→ SQL (schémas DDL) → IP, adresses
  ├→ pgvector (métadonnées embeddings) → identifiants
  ├→ ONNX (outputs classification) → noms propres
  └→ Graphify (graph.json) → nœuds avec PII

SORTIE : Datasets propres, format standardisé
  ├→ [ANONYMIZED] remplace les PII détectées
  ├→ Classification RGPD (niveau 0→4)
  ├→ Rapport d'audit (quoi a été nettoyé)
  └→ Dataset prêt pour RAG ET fine-tuning
----

มันตรวจจับรูปแบบที่ชัดเจนที่สุดก่อน (emails`.*@.*`, โทเคน`sk-*`, `ghp_*`, IPs) จากนั้นมันจะเริ่มเรียนรู้ ช่วงทดลองงานก็คือสิ่งนี้: เราตรวจสอบให้แน่ใจว่ามันไม่ปล่อยให้มี false negatives หลุดรอดไปก่อนที่จะบรรจุเข้าทำงานจริง

== สิ่งที่ MVP นี้ปลดล็อก (และไม่ใช่แค่เรื่องความสอดคล้องตามกฎระเบียบ)

การทำ anonymisation เป็น MVP0 ไม่ใช่แค่ด่านเก็บค่าผ่านทาง RGPD ก่อนจะขึ้นทางด่วน แต่มันคือตัวทางด่วนเอง และนี่คือสิ่งที่มันเปิดโอกาสให้:

=== ปัจจุบัน: Augmented Reality ใน Prompt

[source]
----
DONNÉES BRUTES CLIENT
    ↓
Anonymiseur MVP0 → datasets propres
    ↓
RAG pgvector (MVP1) → top-K documents similaires (filtrés, anonymisés)
    ↓
LLM (deepseek-v4-pro) → réponse augmentée, zéro PII
----

RAG ไม่ได้ค้นหาในข้อมูลที่สกปรก — แต่มันค้นหาในพื้นที่**สะอาดโดยการออกแบบ**สิ่งนี้เปลี่ยนทุกอย่างสำหรับคุณภาพของคำตอบ: LLM ไม่ต้องเสียเวลาในการหลบเลี่ยง PII ที่มันรู้จักแต่ไม่ได้รับอนุญาตให้ระบุถึง

=== อนาคต: การทำ Fine-Tuning ด้วยข้อมูลที่สะอาด

[source]
----
MVP0 → datasets propres accumulés (session après session)
    ↓
Fine-tuning expert métier (CDA, FPA) sur données zéro PII
    ↓
Modèle fine-tuné exposé via Ollama (sans fuite de données)
----

การทำ fine-tuning ด้วยข้อมูลดิบคือหายนะทางกฎหมายที่รอวันเกิดขึ้น ส่วนการใช้ข้อมูลที่สะอาดนั้นคือ**วิธีการที่ทำซ้ำได้**ลูกค้าแต่ละรายจะสะสมชุดข้อมูลที่ผ่านการทำความสะอาดแล้ว และลูกค้าแต่ละรายสามารถปรับจูน (fine-tune) ผู้เชี่ยวชาญเฉพาะด้านด้วยข้อมูลของตนเองได้ โดยไม่มีการเปิดเผยข้อมูลส่วนบุคคลใดๆ

== ทำไมสิ่งนี้ถึงทำตลาดได้

นี่ไม่ใช่ "เครื่องมือสำหรับความสอดคล้องกับ RGPD" แต่มันคือหนึ่งใน**วิธีการที่ทำซ้ำได้ซึ่งเปลี่ยนปัญหาที่เป็นสากลให้กลายเป็นสินทรัพย์**โปรดระบุข้อความที่ต้องการให้แปล

1. *ทุกธุรกิจการฝึกอบรมมีข้อมูลที่สกปรก (dirty data)* — นั่นคือปัญหา
2. *ไม่มีรายใดมี pipeline การทำความสะอาดข้อมูลแบบหลายแหล่งแบบอัตโนมัติ* — นี่คือสภาพตลาด
3. *ลูป : anonymisation → RAG → fine-tuning เป็นกรรมสิทธิ์* — นี่คือปราการกั้น

SaaS Edster (MVP3) จะไม่ขาย "gradle workspace" แต่จะขาย Closed Loop นี้ และ MVP0 คือประตูทางเข้า

== รูปแบบ SQL ในฐานะทางเลือกที่สามของบริบท

การนำเข้าข้อมูลโครงสร้างไม่ใช่เพียงแค่รูปแบบของการแลกเปลี่ยนเท่านั้น รูปแบบ SQL (DDL) จะระบุถึง**แบบจำลองเอนทิตี-ความสัมพันธ์ของโดเมน**โปรดระบุข้อความที่ต้องการแปลครับ

[source]
----
CREATE TABLE formation (
  id UUID PRIMARY KEY,
  titre VARCHAR NOT NULL,
  referentiel RNCP REFERENCES rncp(id),
  organisme OF REFERENCES of_pilote(id)  -- ← va être anonymisé
);
----

DDL นี้ เมื่อผ่านการทำ anonymized แล้ว (บรรทัด 4) จะกลายเป็นแหล่งข้อมูลบริบทสำหรับ LLM ไม่ใช่ข้อความ แต่เป็น**โมเดลธุรกิจ**. RAG ให้เนื้อหา (ความคล้ายคลึงเชิงเวกเตอร์), Graphify ให้ความสัมพันธ์ (โครงสร้างที่แน่นอน), และ SQL schema ให้**Domain-Driven Design แบบนัย (implicite)**: bounded contexts, agrégats, value objects. LLM เข้าใจธุรกิจเพราะว่ามันอ่าน schema ของธุรกิจนั้นๆ

== Roadmap: จาก MVP0 สู่ SaaS

[source]
----
MVP0 — Anonymiseur (ce que cet article décrit)
  Sortie : datasets propres, reproductible

MVP1 — RAG pgvector (dépend de MVP0)
  Realité augmentée en prompt sur données nettoyées

MVP2 — Graphify + ONNX + SQL DDD (dépend de MVP1)
  Vecteur composite de contexte (règles + similarité + relations exactes)

MVP3 — SaaS Edster (dépend de MVP0-2)
  Provisionnement workspace client complet
----

MVP แต่ละตัวขึ้นอยู่กับตัวก่อนหน้า ไม่มีตัวไหนสามารถส่งมอบได้หากไม่มี MVP0 นี่คือเหตุผลที่ Anonymiseur ไม่ใช่ « P0 » ใน backlog — แต่มันคือ**MVP0**นี่คือสิ่งส่งมอบเชิงพาณิชย์ชิ้นแรก และทุกอย่างที่เหลือขึ้นอยู่กับความสำเร็จของสิ่งนี้

== บทสรุป : งานที่มองไม่เห็นซึ่งทำให้ทุกสิ่งเป็นไปได้

ในสตาร์ทอัพทั่วไป การทำความสะอาดข้อมูลจะถูกจ้างภายนอก ทำด้วยมือ หรือถูกละเลย แต่ในสถาปัตยกรรมนี้ มันคือ**หัวใจสำคัญของผลิตภัณฑ์**. Anonymiseur คือพนักงานคนแรก เพราะหากไม่มีเขา ทุกอย่างก็ไม่สามารถทำงานได้:

* หากไม่มี MVP0 → จะไม่มี RAG ทางกฎหมาย (MVP1)
* ไม่มี MVP0 → ไม่มีการทำ fine-tuning โดยปราศจากข้อมูลรั่วไหล (EPIC 5)
* หากไม่มี MVP0 → จะไม่มี SaaS ที่น่าเชื่อถือ (MVP3)
* ไม่มี MVP0 → ไม่มี augmented reality ใน prompt
* หากไม่มี MVP0 → จะไม่มีบริบททางเลือกที่สาม (SQL DDD)

เขาเป็นคนทำงานสกปรก เขาจะไม่มีวันถูกพูดถึงใน pitch แต่เขาคือคนที่ทำให้โรงงานขับเคลื่อนไปได้

และนั่นคือเหตุผลที่เราจ้างเขาเป็นคนแรก

== เอกสารอ้างอิง

* บทความเกี่ยวกับภววิทยาเชิงพื้นที่และวงจรแห่งความเชื่อมั่น:link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[ออนโทโลจีเชิงพื้นที่ในฐานะกลไกการจัดตำแหน่ง]
* บทความเกี่ยวกับการกำกับดูแล agent แบบ Eager/Lazy:link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[ควบคุม AI Agent ด้วย AsciiDoc]
* บทความเกี่ยวกับกลไก Hot/Warm/Cold:link:../2026/0110_mecanisme_backup_contexte_agent_post.html[Sliding Window และ Vague Froide]
* บทความเปรียบเทียบ LLM ทั้งสามรุ่น:link:../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html[DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1]

บทความที่เกี่ยวข้อง