Chọn LLM cho DataValue — từ Model Selection đến Model-Neutral AI Architecture

Khi bắt đầu xây AI, câu hỏi hay xuất hiện rất nhanh: “chúng ta nên chọn LLM nào?”. Hợp lý — nhưng với một Data & AI Platform như DataValue, đây chưa phải câu hỏi kiến trúc tốt nhất. Câu hỏi đúng hơn:

“DataValue cần một Model Runtime như thế nào để phục vụ nhiều loại AI workload, có thể thay đổi model theo thời gian, kiểm soát được chất lượng, chi phí, bảo mật và không khóa platform vào một model duy nhất?”

Khác biệt giữa hai câu hỏi rất quan trọng. Nếu bắt đầu từ tên một model, architecture dễ thành Application → Specific LLM. Nếu bắt đầu từ capability, architecture thành AI Application/Agent → Model Runtime → Model Selection → Foundation Model. Đó là cách DataValue tiếp cận:

DataValue không xây AI quanh một LLM. DataValue xây một Model-Neutral AI Architecture, trong đó LLM là Intelligence Engine có thể được lựa chọn theo workload.

LLM không phải toàn bộ AI Architecture

Hiểu nhầm phổ biến nhất là đồng nhất AI = LLM. Thực tế, với DataValue, LLM chỉ là một thành phần trong một architecture lớn hơn. Một Enterprise Agent có thể cần:

flowchart TB
  Q["Business Question"] --> LG["LangGraph · Reason & Orchestrate"]
  LG --> CUBE["Cube"] & KN["Knowledge"] & TOOLS["Tools"]
  CUBE --> CTX["Context"]
  KN --> CTX
  CTX --> LLM["LLM"] --> R["Reasoning"] --> DEC["Decision"] --> N8N["n8n"] --> ACT["Business Action"]

Trong đó: Cube cung cấp Trusted Business Context · LlamaIndex/RAGFlow cung cấp Enterprise Knowledge · LangGraph điều phối reasoning & tools · LLM cung cấp intelligence · n8n đưa decision thành action · Langfuse quan sát & đánh giá. Vì vậy không nên bắt đầu bằng “chúng ta dùng model X” mà bằng “AI workload này cần loại intelligence nào?” — use case first, model second.

LLM là Intelligence Engine

DataValue định vị LLM/Model Runtime là Intelligence Engine, với vai trò: Understand · Reason · Classify · Extract · Summarize · Generate · Interpret · Plan. Ví dụ một Sales Agent cần LLM để hiểu câu hỏi, xác định ý định, phân tích context, reasoning trên business data, kết hợp data với enterprise knowledge, tạo recommendation, diễn giải kết quả bằng ngôn ngữ tự nhiên.

Nhưng LLM không phải nơi lưu Business Logic, cũng không nên tự định nghĩa metric. Revenue, Gross Margin, Active Customer, Inventory Value… không nên được model “tự hiểu” theo cách riêng — chúng thuộc Cube / Semantic Layer.

💡 Ranh giới

Cube định nghĩa sự thật kinh doanh. LLM reasoning trên sự thật đó.

Không nên chọn một LLM cho toàn bộ DataValue

Một Enterprise AI Platform có nhiều loại workload: Classification, Extraction, Summarization, Document Understanding, Complex Reasoning, Agent Planning, Coding, Multimodal Understanding, high-volume simple requests. Không có lý do kiến trúc nào bắt tất cả dùng cùng một model. Ví dụ: Invoice Classification → Small Model; Strategic Business Analysis → Advanced Reasoning Model; Read Contract + Table + Image → Multimodal Model.

flowchart TB
  W["AI WORKLOAD"] --> R["MODEL ROUTING"]
  R --> S["Simple Task → Small Model"]
  R --> C["Reasoning → Advanced Model"]
  R --> M["Multimodal → Vision Model"]

Nguyên tắc: One Platform — Multiple Models, không phải One Platform — One LLM.

Tại sao Model-Neutral quan trọng?

LLM market thay đổi rất nhanh — model tốt nhất cho một workload hôm nay chưa chắc là lựa chọn tốt nhất sau một năm. Enterprise requirement cũng đổi: Higher Quality · Lower Cost · Lower Latency · New Language · New Modality · New Security · New Region · Private Deployment. Nếu business logic gắn chặt vào một provider (Business App → Provider-specific Logic → Specific Model), việc thay model sau này rất khó. DataValue hướng tới:

flowchart LR
  APP["Business Application"] --> AI["Agent / AI Layer"] --> ABS["Model Abstraction"] --> RT["Model Runtime"] --> M["Selected Model"]

Model có thể thay đổi; business capability không phải xây lại — đó là Model-Neutral Architecture.

Model-neutral không có nghĩa model nào cũng giống nhau

Model-neutral không nghĩa “model nào cũng dùng được như nhau”, mà là architecture không bị thiết kế phụ thuộc không cần thiết vào một model cụ thể. Thực tế mỗi model khác nhau về: Capabilities · Context Window · Reasoning Ability · Tool Calling Support · Multimodal Support · Latency · Cost · Region Availability · Deployment Options. (Tài liệu Amazon Bedrock cũng khuyến nghị xem capabilities, modality, context, tool use, endpoint/API, Region, cost và throughput khi chọn model.)

Không hỏi “Model nào tốt nhất?” — hỏi “Workload cần gì?”

Ví dụ ba use case của DataValue:

• A — Phân loại Customer Request: Very High Volume · Simple Task · Fast Response · Low Cost → không cần model reasoning mạnh nhất.
• B — CFO Analysis Agent: Complex Business Context · Multi-step Reasoning · Structured Metrics · Contracts/Policies · Tool Calling → workload hoàn toàn khác.
• C — Contract Intelligence: Long Documents · Tables · Images · Vietnamese + English · Precise Extraction → profile khác nữa.

Selection process nên bắt đầu: Use Case → Workload Profile → Model Requirement → Evaluation → Model Selection — không phải Model → Find Something To Use It For.

Bảy tiêu chí chọn model cho DataValue

DataValue nên có một Model Selection Framework thống nhất với bảy nhóm tiêu chí:

#	Tiêu chí	Nội dung
1	Business Quality	Accuracy · Reasoning Quality · Instruction Following · Business Relevance
2	Capability Fit	Text? Vision? Long Context? Tool Calling? Structured Output? Reasoning?
3	Latency	500ms? 3s? 30s? 2 phút? (deep-analysis agent vs realtime assistant khác SLA)
4	Cost	Không chỉ cost/token — Cost/Request, /User, /Agent, /Business Transaction, /Business Outcome
5	Security & Data Governance	Data Handling · Data Residency · Access Control · Audit · Retention · Enterprise Contract
6	Operational Fit	Availability · Throughput · Rate Limits · Regional Availability · Lifecycle · Version Management
7	Business Value	Model có tạo đủ giá trị để justify cost & complexity không? (quan trọng nhất)

Quality không đồng nghĩa “model lớn nhất”

Sai lầm phổ biến: model càng lớn càng tốt. Không nhất thiết. Nếu nhiệm vụ là phân loại Complaint / Inquiry / Order / Support, dùng một advanced reasoning model tạo ra Excellent Accuracy + Unnecessary Cost + Higher Latency. Nguyên tắc: Use the smallest model that reliably meets the business requirement — không phải nhỏ nhất bằng mọi giá, mà đủ năng lực với workload cụ thể.

Reasoning Model chỉ cho bước thực sự cần reasoning

Trong một agent (Identify Intent → Get Metrics → Analyze Trend → Identify Cause → Evaluate Policy → Recommend), không phải bước nào cũng cần deep reasoning: Identify Language → Small Model; Extract Customer Name → Small Model / Deterministic; nhưng Analyze conflicting evidence and recommend action → Reasoning Model. Đây là cách kiểm soát cả chất lượng lẫn cost.

Không dùng LLM nếu deterministic logic tốt hơn

Nguyên tắc quan trọng hơn cả model selection. Revenue = Quantity × Price → không dùng LLM. Cần Revenue YTD → gọi Cube, không hỏi LLM tính từ raw transaction. Discount > 10% → Director Approval là business rule → deterministic workflow. LLM chỉ nên dùng ở nơi cần Language Understanding · Ambiguity Resolution · Complex Reasoning · Unstructured Knowledge · Recommendation · Generation.

flowchart TB
  Q["Can deterministic logic solve it?"]
  Q -->|Yes| RULE["Rule / Workflow"]
  Q -->|No| LLM["LLM"]

Model Routing

Thay vì một model cho tất cả, DataValue có thể có một Model Router:

flowchart TB
  REQ["REQUEST"] --> RTR["MODEL ROUTER"]
  RTR --> A["Simple / High Volume → Efficient Model"]
  RTR --> B["Complex Reasoning → Reasoning Model"]
  RTR --> C["Document / Vision → Multimodal Model"]
  RTR --> D["Sensitive / Controlled → Approved Runtime"]

Routing criteria: Task Type · Risk · Complexity · Latency SLA · Cost Budget · Data Classification — bước quan trọng từ LLM Integration sang Enterprise Model Management. Không nhất thiết phức tạp ngay: phiên bản đầu chỉ cần Agent A → Default Model A, Document Processing → Model C; sau này tiến tới dynamic routing. Nguyên tắc: Start simple, retain the architecture to evolve.

Model Runtime là gì?

Cần phân biệt Model (intelligence model) và Model Runtime (môi trường/capability giúp application: Invoke Model · Authenticate · Control Access · Handle Throughput · Manage Endpoint · Monitor Usage · Handle Version · Apply Governance). DataValue nên thiết kế một Model Runtime Layer, không gọi trực tiếp model từ mọi application: Application/Agent → Model Runtime → Foundation Model.

Managed Model Runtime

Bedrock/Foundry — model catalog đa provider + deployment/runtime. Điểm quan trọng không phải tên vendor mà là một control point cho Identity, Access, Deployment, Consumption, Monitoring, Governance.

Direct Model API

Hợp khi architecture đơn giản, cần nhanh, cần capability của provider. Vẫn giữ abstraction — không để 50 app có 50 bộ provider-specific code, mà Applications → AI/Model Service Layer → Provider APIs.

Private / Self-hosted

Cho dữ liệu rất nhạy cảm, private environment, specialized model, offline/edge. Architecture không đổi chỉ vì deployment model đổi — agent vẫn LangGraph → Model Interface, runtime phía dưới có thể khác.

Cloud hay Private không nên là quyết định ý thức hệ — đừng bắt đầu bằng “tất cả phải Cloud” hay “tất cả phải Self-host”. Quyết theo requirement (Business Criticality · Data Sensitivity · Performance · Cost · Scale · Operations Capability · Regulation), thậm chí hybrid: General AI → Managed Models, Sensitive Workload → Controlled Private Runtime.

Security & Context Governance đứng trước Model

Khi Agent gửi context vào LLM, context có thể chứa Customer Data · Financial Data · Contracts · Pricing · Internal Policies · Personal Data. Vì vậy câu hỏi không chỉ “model có thông minh không?” mà “dữ liệu nào được phép gửi?”:

flowchart LR
  R["Business Request"] --> ID["Identity"] --> AU["Authorization"] --> DC["Data Classification"] --> AC["Allowed Context"] --> MR["Model Runtime"]

Không phải All Enterprise Data → LLM. Và Context Governance quan trọng không kém Model Governance: AI response phụ thuộc Model + Prompt + Context, mà nhiều khi context sai nguy hiểm hơn model kém một chút (Excellent Model + Old Contract = Wrong Recommendation; Excellent Model + Wrong Revenue Metric = Wrong Analysis). Nên DataValue tập trung Trusted Context trước — Cube (business context), LlamaIndex/RAGFlow (knowledge context), OpenMetadata (governed data context) — rồi mới LLM reasoning.

Tool Calling & Structured Output là tiêu chí chọn model cho Agent

Một DataValue Agent không chỉ chat — nó dùng tools (Cube, Knowledge Retrieval, APIs, Search, Business Functions). Nên nếu model dùng cho agentic workload, structured tool/function calling là requirement quan trọng (không chọn model chỉ dựa text generation quality). Tương tự, Structured Output: business system cần { customer_id, risk_level, recommended_action, confidence } chứ không phải “Maybe customer A should probably…” — AI phải tạo output có cấu trúc để LangGraph/n8n xử lý (LLM → Structured Decision → Validation → n8n), không phải LLM Free Text → Direct Financial Transaction.

Model Selection phải kiểm chứng bằng dữ liệu của chính DataValue

Đây là nơi Langfuse rất quan trọng. Không chọn model chỉ dựa Public Benchmark / Leaderboard / Marketing Claim — benchmark chung không biết business terminology tiếng Việt, dữ liệu, SOP, metrics, agent workflows, business rules của bạn. DataValue nên tạo Evaluation Dataset riêng cho từng use case: 100 câu hỏi thực → candidate model → agent execution → Langfuse evaluation (Correctness · Business Relevance · Tool Selection · Reasoning Quality · Latency · Cost) → chọn. Đây là evidence-based model selection.

Langfuse biến model selection thành Engineering Process: Define Use Case → Create Evaluation Dataset → Define Success Criteria → Run Model → Trace → Evaluate → Measure Cost & Latency → Select; sau production: Production Traces → Find Edge Cases → Add to Dataset → Evaluate Again. Nhờ vậy Model Selection không phải quyết định một lần mà là Continuous Model Evaluation.

”Approved model” thay vì “đã chọn model”

Cách nói tốt hơn: “đây là model hiện được approved cho workload này” (vì Model Landscape → Changes → Evaluation → Approved Models). Ví dụ Model Registry: CUSTOMER AGENT → Approved Model X; FINANCE AGENT → Approved Model Y; DOCUMENT AGENT → Approved Model Z. Khi re-evaluate → đổi approved model, application không phải đổi business architecture.

Model Lifecycle cần được quản lý

Model có lifecycle: Available → Approved → Production → New Version → Re-evaluate → Migrate → Retire. Các managed platform cũng phải quản lý availability, versions, deprecation, migration (AWS Bedrock có tài liệu riêng cho model lifecycle & deprecation). DataValue cần chuẩn bị architecture cho điều này ngay từ đầu.

Không hard-code Model ID — dùng Capability Profile

Tránh Sales Agent: model = model_xyz khắp platform. Tốt hơn: Sales Agent → profile: BUSINESS_REASONING; Document Agent → profile: MULTIMODAL_DOCUMENT; Classifier → profile: FAST_LOW_COST. Model configuration layer resolve BUSINESS_REASONING → currently approved model. Business application phụ thuộc Capability Profile, không phụ thuộc Product Name. Các profile đề xuất: FAST · BALANCED · ADVANCED_REASONING · MULTIMODAL · PRIVATE · EMBEDDING · RERANKING — đổi approved model không phải redesign agent. Đây chính là model-neutral architecture ở mức implementation.

Không phải mọi “Model” đều là LLM

DataValue AI stack có: Generative LLM · Reasoning Model · Embedding Model · Reranking Model · Vision Model · Classification Model. Ví dụ RAG: Document → Embedding Model → Vector Index; query: Question → Embedding → Retrieve → Reranking Model → Context → LLM. Vì vậy gọi layer Model Runtime chính xác hơn LLM Layer. Lưu ý lifecycle khác nhau: đổi LLM (Model A → Model B) thường không cần rebuild Knowledge Index; nhưng đổi embedding model ảnh hưởng vector representation → có thể phải Re-embed Documents → Rebuild/Migrate Index. Model Management là một architecture concern thực sự, không chỉ chọn chatbot model.

Ranh giới với các layer khác

	Vai trò
LangGraph	How AI reasoning process is orchestrated (what step next, which tool, need approval, continue/stop)
Model Runtime	Where intelligence is executed (run model, handle request, return output)
Langfuse	Observe, Evaluate & Improve intelligence (trace, cost, latency, quality)
LlamaIndex/RAGFlow	What context to provide (RAG cung cấp Knowledge; Model cung cấp Intelligence)

Và một request có thể gọi model nhiều lần: Small Model (intent) → Cube → Reasoning Model (analysis) → Knowledge Retrieval → Reasoning Model (decision) → Small Model (formatting). Nên Model Routing & Model Runtime là platform capability.

Human-in-the-loop không bị thay bởi model mạnh hơn

Sai lầm nguy hiểm: “model đủ thông minh thì tự quyết”. Không. Risk classification độc lập với model intelligence: LOW RISK → Automatic; MEDIUM RISK → User Confirmation; HIGH RISK → Formal Approval. Dù model score cao đến đâu, Large Payment · Contract Commitment · Major Discount · Supplier Selection vẫn cần human approval — thuộc Business Governance, không phải Model Capability. Và nên dùng Decision Confidence (Data Quality + Retrieval Quality + Business Rule Validation + Evaluation History + Agent State + Risk Level + Human Approval), không chỉ Model Confidence (đừng hỏi model “bạn tự tin bao nhiêu %?” rồi coi đó như guarantee).

Approved Model Catalog & Governance

Khi trưởng thành, DataValue nên có Approved Model Catalog: Model Profile · Capabilities · Approved Use Cases · Data Classification Allowed · Runtime · Region · Latency Target · Cost Profile · Evaluation Score · Version · Status. Ví dụ: ADVANCED_REASONING — Approved — Finance Analysis, Management Agent; MULTIMODAL — Approved — Contract Intelligence, Document Processing. Không để developer tự chọn model tùy ý cho từng application. Model Governance không nên thành bureaucracy (không tạo committee cho mỗi API call) — mục tiêu là Approved Patterns/Models/Data Classes + Clear Evaluation + Clear Ownership; developer vẫn thử nghiệm, nhưng production đi qua Experiment → Evaluation → Approval → Production — balance Innovation & Control.

Từ Model Cost đến Intelligence Economics

Thay vì báo “tháng này dùng 500 triệu tokens” (business khó hiểu), nên báo theo use case: Customer Agent — Cost X, Users Y, Business Actions Z; Finance Agent — Cost A, Decisions Supported B. Và tốt hơn nữa, nối AI Cost → Business Outcome: Retention Agent — AI Cost 2M, Revenue Recovered 500M. Xa hơn là Intelligence Economics: (Model Cost + Platform Cost + Human Review Cost) = Total Intelligence Cost so với Revenue Increase + Cost Reduction + Risk Avoided + Time Saved. Cuối cùng enterprise không quan tâm model có bao nhiêu parameter, mà intelligence đó tạo ra bao nhiêu giá trị.

Architecture đề xuất cho DataValue

flowchart TB
  U["Business User"] --> AG["AI Agent"] --> LG["LangGraph · Reason · Orchestrate"]
  LG --> CUBE["Cube · Business Context"] & RAG["LlamaIndex/RAGFlow · Knowledge"] & TOOLS["Tools"]
  LG --> MS["MODEL SERVICE · Selection · Routing · Policy Control"]
  MS --> MG["Managed Runtime"] & DA["Direct API"] & PR["Private Runtime"]
  MG --> MOD["Model"]
  DA --> MOD
  PR --> MOD
  MOD --> DEC["Decision"] --> N8N["n8n · Automate · Act"] --> OUT["Business Action → Outcome"]
  LF["Langfuse · Observe · Evaluate · Improve"] -. cross-cutting .-> AG

Tôi đề xuất gọi layer này là AI Model & Runtime (hoặc Foundation Model & AI Runtime) thay vì chỉ LLM — vì sau này nó gồm nhiều hơn LLM (Language/Reasoning/Multimodal/Embedding/Reranking Models). Trong blog có thể nói “LLM” cho dễ hiểu; trong Enterprise Architecture, AI Model & Runtime là tên bền hơn.

Có nên chọn ngay một vendor chiến lược? — Default ≠ Exclusive

Khuyến nghị: chọn một default runtime để vận hành đơn giản, nhưng không biến default thành architectural lock-in. Không có default thì mỗi team một vendor → khó governance; hard lock một model mãi mãi → mất flexibility. Do đó: DEFAULT MODEL RUNTIME + APPROVED ALTERNATIVES + MODEL ABSTRACTION. Default does not mean exclusive: 80% workloads → Default Runtime; 15% → Specialized Model; 5% → Private/Special. Và đừng thiết kế Model Strategy bằng logo (Vendor A/B/C) mà bằng Business Workload → Model Profile → Runtime Requirement → Evaluation → Approved Model — chính là Capability-to-Technology Mapping như cách DataValue đã chọn Airbyte, ClickHouse, Cube, LangGraph, Langfuse. Technology là implementation; Capability mới là architecture.

Maturity path của Model Strategy

Không cần xây tất cả ngay: Level 1 — Single Default Model (AI Apps → Default Model, đủ để bắt đầu) · Level 2 — Model Profiles (Fast/Reasoning/Multimodal) · Level 3 — Evaluation-driven Selection (Langfuse Dataset → Experiment → Approved Model) · Level 4 — Model Routing (Request → Dynamic Routing) · Level 5 — Intelligence Optimization (tối ưu Quality/Cost/Latency/Risk/Business Outcome). Đây là roadmap thực tế hơn là xây ngay một “AI Model Gateway” quá phức tạp.

Điều DataValue thực sự cần bảo vệ không phải Model

Model sẽ thay đổi, platform sẽ thay đổi, provider sẽ thay đổi. Những tài sản quan trọng hơn là: Trusted Business Data · Business Semantics · Enterprise Knowledge · Domain Know-how · Agent Logic · Business Rules · Evaluation Datasets · Historical Outcomes — proprietary intelligence assets. Một organization khác có thể dùng cùng LLM, nhưng không có dữ liệu, semantic, knowledge, decision history, outcome của bạn. Đó mới là sự khác biệt. Vì vậy: LLM should be powerful — but replaceable — architecture khỏe cho phép Better Model Appears → Evaluate → Approve → Switch, thay vì → Rewrite Platform. Đó là khác biệt giữa AI Application và AI Platform.

Vai trò trong toàn bộ DataValue stack

Airbyte Ingest · ClickHouse Store & Process · dbt Transform & Model · Cube Define & Understand · Superset Explore & Analyze · LlamaIndex/RAGFlow Know · AI Model & Runtime Understand & Reason · LangGraph Reason & Orchestrate · n8n Automate & Act · OpenMetadata Discover/Govern/Trust · Langfuse Observe/Evaluate/Improve. Trong đó Data → Trusted Data → Trusted Meaning → Enterprise Knowledge → AI Intelligence → Agent Reasoning → Decision → Action, và Langfuse tạo vòng learning quay lại.

Sáu nguyên tắc kiến trúc

1. Use case first — Model second.
2. Một default runtime, không phải một model độc quyền.
3. Model-neutral ở application architecture.
4. Dùng đúng model cho đúng workload.
5. Lựa chọn bằng evaluation trên dữ liệu thực, không bằng cảm nhận.
6. Model phải replaceable; Business Intelligence Assets phải được giữ lại.

Bền hơn rất nhiều so với tuyên bố “DataValue sử dụng model X”.

Kết luận: từ Model Selection đến Intelligence Architecture

Ở cấp prototype ta chọn một LLM; cấp application ta tích hợp model; cấp platform ta quản lý nhiều model. Nhưng ở cấp Enterprise Architecture, điều DataValue thực sự cần xây là Intelligence Architecture — nơi Trusted Data + Trusted Semantics + Enterprise Knowledge + Appropriate Model + Controlled Agent + Business Workflow → Business Intelligence → Decision → Action → Outcome. Khi đó LLM không còn là trung tâm — Business Value mới là trung tâm.

DataValue không cần trả lời “LLM nào tốt nhất?” (câu hỏi không có đáp án cố định cho mọi workload/thời điểm/enterprise), mà trả lời: “với business problem này, intelligence capability nào phù hợp nhất, và model/runtime nào đáp ứng tốt nhất về quality, cost, latency, security, governance và business value?” — khác biệt giữa Model-Centric AI và Business-Centric AI Architecture.

Vì vậy: AI Model & Runtime — Intelligence Execution Layer của DataValue, với nguyên tắc: chọn model theo workload, đánh giá bằng dữ liệu thực, quản trị ở cấp platform, không khóa architecture vào model — Model-Neutral by Architecture · Evaluation-Driven by Engineering · Business-Driven by Design. Ghép vào toàn bộ: Data → Trusted Data → Trusted Meaning → Knowledge → Intelligence → Reasoning → Decision → Action → Outcome → Evaluation → Learning → Value.

Ghi chú

Biên soạn & diễn giải tiếng Việt bởi BSD Insight; tham chiếu hướng dẫn chọn model của các managed AI platform (Amazon Bedrock, Microsoft Foundry). Ví dụ khái quát hóa cho ngăn xếp DataValue, không phải dịch nguyên văn. Đặt tư vấn triển khai.