Ứng dụng tự hoàn thiện: vòng lặp cải tiến khép kín

1. Tại sao App cần vòng lặp cải tiến khép kín

Bất kỳ LLM‑App nào cũng vận hành trong một thế giới thay đổi liên tục. Bạn có người dùng và kịch bản mới, OpenAI ra mắt các model và cơ chế bảo vệ mới, bạn tự cập nhật MCP‑server, Agents SDK, UI‑widget… Và ngay cả khi toàn bộ mã đều được viết hoàn hảo (vâng, tôi biết bạn gần như làm được như vậy), chỉ một lần đổi model hoặc prompt có thể âm thầm làm hỏng một nửa các ca sử dụng.

Không có vòng lặp cải tiến, đời sẽ như sau. Người dùng viết cho hỗ trợ: “GiftGenius bắt đầu gợi ý quà đắt hơn ngân sách” hoặc “ngồi nghĩ 15 giây”. Bạn mở log, chỉnh gì đó trong system‑prompt, chuyển model, triển khai. Một tuần sau mọi thứ lặp lại, chỉ là ở chỗ khác. Kết quả — chữa cháy triền miên và một đống thay đổi “ma thuật” mà không ai giải thích nổi.

Với vòng lặp thì khác hẳn. Bạn có:

• bộ tín hiệu rõ ràng cho kỹ thuật, tiền bạc, sản phẩm và chất lượng;
• nghi thức định kỳ: xem chúng và chọn giả thuyết;
• các thay đổi có kiểm soát trong code/config;
• kiểm tra tự động: golden cases + LLM evals + thí nghiệm.

Nhờ đó App biến từ “prompt cố định” thành một hệ thống sống động, có thể:

• chỉ ra chỗ nào đang đau và vì sao;
• gợi ý chính xác điều gì có thể cải thiện;
• bảo vệ khỏi suy giảm âm thầm sau một thay đổi “vô hại” của prompt.

Thêm một điểm cộng: vòng lặp này rất khớp với những gì bạn đã làm trong các mô‑đun trước. Log và SLO từ M17 cho tín hiệu kỹ thuật, công cụ chi phí (cost instrumentation) và AARRR từ M19 — tín hiệu kinh tế và sản phẩm, golden cases và LLM evals từ M20.1–2 — tín hiệu chất lượng. Việc còn lại chỉ là kết nối chúng thành một vòng lặp vận hành dễ hiểu.

2. Bản đồ tín hiệu cho cải tiến

Để App có thể tự gợi ý nên cải thiện ở đâu, cần hiểu rõ bạn có những tín hiệu nào và chúng đến từ đâu. Thuận tiện nhất là nghĩ theo bốn nhóm.

Tín hiệu kỹ thuật đến từ observability‑stack của bạn: log tool_invocation, metric latency và error‑rate, health check MCP/ACP, lỗi OAuth. Chúng trả lời câu hỏi “dịch vụ có đang sống và ổn định tới mức nào”.

Tín hiệu kinh tế sinh ra trong cost instrumentation và billing: cost_per_tool_call, cost_per_task, cost_per_user, các đột biến chi phí ngoài dự kiến theo công cụ hoặc kịch bản cụ thể. Chúng nói rằng: “chúng ta đang đốt token và tiền nhiều hơn mong đợi” hoặc ngược lại, “còn dư địa, có thể nâng chất lượng”.

Tín hiệu sản phẩm hình thành từ các sự kiện như app_opened, workflow_started, workflow_completed, checkout_*. Đó là activation‑rate, chuyển đổi giữa các bước trong phễu, retention theo cohort. Chúng cho thấy hành vi thực tế của con người đang diễn ra như thế nào.

Tín hiệu chất lượng và hành vi bao gồm kết quả LLM evals trên golden cases (điểm correctness/helpfulness/style/safety), các review thủ công chọn mẫu cuộc hội thoại, thumbs up/down, khiếu nại và đánh giá trong Store. Đây là thứ gần nhất với cảm nhận “App trở nên thông minh/ngu hơn”.

Thuận tiện gom vào một bảng:

Điểm then chốt: tất cả những tín hiệu này được ghi log gắn với kịch bản cụ thể và phiên bản App. Tức là trong sự kiện ít nhất có scenario, appVersion và experimentId. Khi đó, thấy helpfulness trên golden cases giảm từ 8.5 xuống 6.2, bạn có thể nói không chỉ “tệ hơn”, mà là “tệ hơn trong kịch bản "gift_selection" sau bản phát hành "1.3.0", ở biến thể thí nghiệm "B"”.

Trong code, bạn thậm chí có thể tạo một cấu trúc đơn giản để mô tả tín hiệu:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // giá trị "trước"
};

Những đối tượng như vậy tiện cấp dữ liệu cho cả dashboard lẫn trợ lý cải tiến tương lai của bạn.

3. Vòng lặp phản hồi chuẩn: 4 bước

Giờ hãy ráp một vòng lặp cải tiến chuẩn mà bạn có thể dựa vào mỗi lần. Nó rất thực dụng: bốn bước.

flowchart TD
  A[Tín hiệu: có vấn đề
hoặc có cơ hội tăng trưởng] --> B[Giả thuyết:
đổi gì và đổi như thế nào]
  B --> C[Thay đổi có kiểm soát
trong code/config]
  C --> D[Kiểm tra:
offline + online]
  D --> A

Bước 1. Phát hiện vấn đề hoặc cơ hội

Ở bước này bạn trả lời câu hỏi “nhìn vào đâu”. Ví dụ:

• LLM eval trên golden cases có ngân sách cho thấy helpfulness giảm.
• p95 latency của công cụ "suggest_gifts" tăng từ 1.2s lên 3.8s.
• cost_per_task cho kịch bản "gift_selection" tăng 40% sau khi chuyển sang model reasoning.
• Tỉ lệ chuyển đổi workflow_completed → checkout_success giảm 5 điểm phần trăm sau khi thay đổi UX wizard.
• Trong Store xuất hiện 10 khiếu nại trong một tuần: “quà đắt hơn hạn mức đã chỉ định”.

Điểm tinh tế: đôi khi tín hiệu không nói “xấu”, mà là “có thể tốt hơn”. Ví dụ, bạn thấy cost_per_task thấp đáng kể so với ngưỡng cho phép, còn quality‑score đã 9/10. Vậy có thể thử model đắt hơn hoặc kịch bản “thông minh” hơn — biết đâu chuyển đổi tăng.

Bước 2. Đặt giả thuyết

Giả thuyết không phải là “chúng ta sẽ viết lại prompt”, mà là “chúng ta nghĩ thay đổi cụ thể X trong thành phần Y sẽ cải thiện metric Z, bởi vì…”. Thiếu “bởi vì” thì đó không phải giả thuyết, mà chỉ là mong muốn.

Ví dụ:

• “Nếu đặt quy tắc tuân thủ ngân sách nghiêm ngặt trong system‑prompt và yêu cầu luôn giải thích ngân sách được dùng ra sao, helpfulness trong các case có ngân sách sẽ tăng tối thiểu 2 điểm”.
• “Nếu thay model đắt bằng "gpt-mini" ở bước rerank, cost_per_task sẽ giảm 30%, và tỉ lệ chuyển đổi không giảm quá 1 điểm phần trăm”.
• “Nếu đơn giản hóa wizard (gộp hai bước thành một) và viết lại CTA, activation‑rate sẽ tăng 5 điểm phần trăm”.

Trong code, mô tả giả thuyết theo cách tường minh rất tiện, tối thiểu như một object:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Thay đổi gì và vì sao"
  targetMetric: string;  // e.g. "quality.helpfulness" hoặc "conversion.checkout"
  successCriteria: string;
};

Vâng, điều này gần như một ticket trong Jira, nhưng ít ra là ở dạng có kiểu.

Bước 3. Thực hiện thay đổi có kiểm soát

Ở đây có hai từ quan trọng: có kiểm soát và tách bạch.

Có kiểm soát nghĩa là thay đổi được thực hiện như PR/commit, gắn với giả thuyết, có changelog và nếu có thể, có feature flag hoặc phiên bản. Bạn không chỉ “chỉnh prompt ở prod”, mà có thể nói chính xác bản phát hành nào mang thay đổi đó.

Tách bạch nghĩa là bạn cố không trộn ba giả thuyết khác nhau trong cùng một bản phát hành. Nếu đồng thời:

• đổi model,
• viết lại nửa system‑prompt,
• và thêm một bước mới trong UX,

thì ngay cả khi metric được cải thiện, cũng khó hiểu điều gì thực sự hiệu quả. Thành thật hơn là tiến từng phần nhỏ.

Từ góc kỹ thuật, thay đổi có thể ở bất cứ đâu:

• system‑prompt của agent (lib/prompt/systemPrompt.ts);
• mô tả MCP‑tools (description, inputSchema, annotations);
• cấu hình agent (giới hạn các bước reasoning, chọn model cho tool cụ thể);
• mã của widget (CTA, thứ tự bước, thông điệp lỗi).

Bước 4. Kiểm tra xem có tốt hơn không

Kiểm tra gồm offline và online.

Kiểm tra offline — chạy golden cases qua phiên bản App mới mà không có người dùng thật. Ở đây bạn đã có:

• LLM evals (mô‑đun 20.1);
• logic ngưỡng/baseline (mô‑đun 20.2).

Bạn xem quality‑score trên các kịch bản mục tiêu thay đổi ra sao: tăng, giảm hay giữ nguyên. Đồng thời kiểm tra các safety case: mọi chỉnh sửa prompt trước hết cần vượt qua bộ safety.

Kiểm tra online — thí nghiệm trên traffic thật. Ở phiên bản đơn giản nhất, bạn bật phiên bản mới cho N% người dùng và so sánh:

• tỉ lệ chuyển đổi tới hành động mục tiêu (checkout, chạy lại kịch bản);
• cost_per_task;
• khiếu nại/phản hồi.

Sau đó vòng lặp hoặc được đóng (giả thuyết được xác nhận/bác bỏ và được ghi nhận), hoặc sinh ra giả thuyết mới.

4. “Trợ lý cải tiến” nội bộ như một agent riêng

Giờ đến phần hấp dẫn: hãy trao cho model LLM thêm một vai — không chỉ trả lời người dùng, mà còn giúp bạn cải thiện App. Đây là agent nội bộ, tách biệt với GiftGenius dành cho người dùng.

Nó là gì

Trợ lý này sống trong môi trường nội bộ của bạn (cùng repo, ở Dev Mode, trong một ChatGPT App riêng). Nó:

• đọc log và các mẫu hội thoại;
• xem metric;
• phân tích system‑prompt và mô tả tools;
• giúp hình thành vấn đề và đề xuất thay đổi.

Về bản chất, bạn có một “product/analyst ảo”, người:

• không mệt khi đọc hội thoại;
• nhanh chóng tìm mẫu lặp;
• biết viết bản nháp prompt và changelog.

Đầu vào nó nhận

Nên chuẩn hóa đầu vào để agent làm việc dễ hơn. Ví dụ, kiểu:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // từ phần trước
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Bạn có thể tạo đối tượng như vậy bằng cách trích từ log 10–20 hội thoại thất bại trong kịch bản "gift_selection" và đính kèm system‑prompt hiện tại cùng mô tả công cụ.

Đầu ra mong đợi

Cũng nên cố định cấu trúc câu trả lời mong đợi:

export type ImprovementSuggestion = {
  patterns: string[];     // các vấn đề lặp lại
  promptPatches: string[]; // đề xuất đoạn cho system-prompt
  toolsPatches: string[];  // ý tưởng cho mô tả tools
  uxCopyIdeas: string[];   // phương án nội dung UX
  changelog: string[];     // danh sách ngắn "cần thay đổi"
};

Meta‑prompt cho agent như vậy sẽ xấp xỉ:

• “phân tích các ví dụ và tín hiệu”;
• “mô tả 2–3 mẫu vấn đề”;
• “đề xuất 1–2 thay đổi cho prompt, mô tả tools và nội dung UX”;
• “trả về mọi thứ dưới dạng JSON có cấu trúc nghiêm ngặt”.

Sau đó bạn sẽ tự tay lấy các đoạn này, bàn trong team, đưa vào code và chạy qua các eval và thí nghiệm. Nguyên tắc quan trọng: trợ lý này không tự ý thay đổi gì trong production. Nó tạo ý tưởng và văn bản, không phải commit.

5. Các loại thay đổi: có thể “tune” những gì

Khi có trợ lý như vậy và một vòng lặp rõ ràng, rất dễ quy hết về “hãy ném tôi bản system‑prompt mới”. Thực tế phạm vi cải tiến rộng hơn nhiều.

Prompt và hướng dẫn

System‑prompt đặt vai trò, giọng điệu, ưu tiên và quy tắc cứng (ví dụ: ngân sách, safety, thứ tự bước). Có thể:

• đơn giản hóa, loại bỏ hướng dẫn mâu thuẫn hoặc trùng lặp;
• tăng cường, thêm các quy tắc còn thiếu (như ví dụ về ngân sách);
• thích ứng theo các kịch bản khác nhau (prompt con riêng cho "gift_selection", "post_purchase_help" v.v.).

Mô tả tools giúp model hiểu khi nào gọi công cụ cụ thể và nó làm gì. Ở đây cải tiến thường là:

• rõ ràng hơn kiểu “Use this when… / Do not use when…”;
• chỉnh ngữ nghĩa (giảm chồng chéo với tools khác);
• thêm thông tin về hệ quả (destructiveHint, isConsequential).

Quy tắc safety — phần của prompt/mô tả chịu trách nhiệm hành vi trong miền phức tạp. Tốt nhất chỉ đụng tới sau các safety eval tốt.

Kiến trúc hành vi (behavior)

Đôi khi không thể giải quyết bằng prompt: cần thay đổi thứ tự hành động.

Ví dụ:

• thêm bước bắt buộc làm rõ tham số trước khi gọi tool đắt tiền;
• đưa một phần tính toán sang một bước riêng, rẻ hơn (ví dụ: lọc sơ bộ ở backend);
• giới hạn số lần gọi tool liên tiếp trong một kịch bản.

Những thay đổi này thường được mô tả trong cấu hình agent hoặc lớp MCP, không chỉ trong prompt.

UX và copywriting

Đúng vậy, văn bản trên nút và thông báo lỗi — cũng là một phần của chất lượng. GiftGenius mà viết:

“Lỗi 500. Hãy liên hệ quản trị viên”,

sẽ tạo ấn tượng rất khác so với:

“Không thể nhận phản hồi từ cửa hàng. Những ý tưởng đã chọn của bạn không bị mất, hãy thử thanh toán muộn hơn một chút”.

Các màn hình trung gian, gợi ý, cấu trúc wizard — tất cả đều ảnh hưởng tới activation‑rate và chuyển đổi mà bạn đang đo.

Kinh tế

Ở đây chúng ta chơi trò “chất lượng ↔ chi phí” quen thuộc:

• chọn model (đắt với reasoning, nhanh/rẻ);
• độ sâu reasoning/các bước agent (cho phép bao nhiêu vòng lặp);
• giới hạn hội thoại (ví dụ, không quá N lần tính lại gợi ý quà trong một phiên);
• chế độ fallback “rẻ” khi hết budget về token/giới hạn.

Tín hiệu từ đây đổ vào cost_per_task, cost_per_user, biên lợi nhuận và kết hợp với quality‑score.

6. Guardrails: những gì không được giao phó cho LLM

Khi hệ thống có “trợ lý cải tiến” và vòng lặp tiện lợi, rất dễ muốn bấm nút “Tối ưu tự động” rồi đi uống cà phê. Hãy thống nhất ngay xem nút đó bị cấm ở đâu.

Thay đổi quyền (OAuth scopes, MCP tools, quyền truy cập dữ liệu) — luôn là vùng human‑in‑the‑loop. Không model nào được tự quyết định rằng từ giờ App có thể đọc đơn hàng, đụng đến thanh toán hoặc gửi email cho người dùng. Điều tương tự áp dụng cho luồng thương mại: mọi thay đổi quanh ACP/Stripe, giới hạn, loại thanh toán và hoàn tiền đều phải qua review và test của con người.

Hồ sơ safety của App (trong miền nào được phép tư vấn, ở đâu buộc phải từ chối) — cũng không nên giao LLM. Model có thể giúp diễn đạt văn bản quy tắc, nhưng quyết định tin cậy App ở chủ đề nào là ở bạn.

Chính sách dữ liệu và logging (log gì, lưu bao lâu, phản hồi yêu cầu xóa dữ liệu ra sao) — cũng vậy. LLM có thể gợi ý cấu trúc Privacy Policy, nhưng không được thay đổi retention trong code nếu không có bạn.

Gì có thể bán tự động? Cách diễn đạt và wording của prompt, mô tả tools và nội dung UX, độ ưu tiên công cụ (trong phạm vi hợp lý), các câu hỏi làm rõ bổ sung. Tất cả có thể giao cho trợ lý như nguồn ý tưởng, nhưng quyết định cuối và kiểm tra thuộc về con người và các script eval.

7. Ví dụ end‑to‑end về vòng lặp cải tiến (GiftGenius)

Quay lại nhân vật chính của chúng ta.

Vấn đề

Người dùng chỉ định ngân sách, nhưng GiftGenius thường gợi ý quà đắt hơn hạn mức đó. Trong log thấy nhiều phần tiếp theo của hội thoại như “không, đắt quá” và “hãy rẻ hơn”.

Tín hiệu

Đầu tiên bạn thấy chất lượng: LLM eval trên golden cases kiểu “chọn quà tới 50$” cho helpfulness khoảng 6/10. Trọng tài thường viết trong reason rằng “quà vượt quá ngân sách” hoặc “không giải thích ngân sách được tính thế nào”.

Song song là tín hiệu sản phẩm và kinh tế:

• tỉ lệ chuyển đổi sang checkout_success với các kịch bản có hạn mức thấp hơn so với không có hạn mức;
• một phần người dùng bỏ dở kịch bản sau khi thấy lựa chọn quá đắt;
• cost_per_task cho các kịch bản đó cao hơn vì App tính lại nhiều lần theo yêu cầu “hãy rẻ hơn”.

Phân tích bằng trợ lý cải tiến

Bạn gom 20 hội thoại có người dùng phàn nàn về giá và tạo ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals cho thấy helpfulness và chuyển đổi giảm;
• examples là các hội thoại;
• system‑prompt hiện tại và mô tả tools.

Bạn cho agent cải tiến nội bộ xử lý. Đáp lại, nó đưa ra, ví dụ:

• Mẫu lặp:
  • ngân sách diễn đạt kiểu “khoảng đến 50$” bị hiểu quá lỏng;
  • system‑prompt không có yêu cầu rõ “không bao giờ gợi ý quà vượt hạn mức”;
  • câu trả lời không giải thích cho người dùng ngân sách được áp dụng thế nào.
• Đề xuất:
  • thêm hướng dẫn tuân thủ hạn mức nghiêm ngặt vào system‑prompt;
  • yêu cầu model luôn nói rõ rằng “mọi phương án ≤ X”;
  • thêm câu hỏi làm rõ nếu ngân sách nghe mơ hồ (“khoảng”, “xấp xỉ”).

Giả thuyết và thay đổi

Bạn đặt giả thuyết:

“Nếu chúng ta cố định rõ việc tuân thủ hạn mức nghiêm ngặt và yêu cầu giải thích cách dùng ngân sách, helpfulness cho các case có ngân sách sẽ tăng tối thiểu lên 8/10, còn tỉ lệ chuyển đổi mua hàng — tăng 3 điểm phần trăm”.

Bạn thêm vào system‑prompt đoạn sau:

export const budgetRule = `
Nếu người dùng chỉ định ngân sách (ví dụ: "tối đa 50$" hoặc "khoảng 30€"),
hãy coi số tiền này là GIỚI HẠN TRÊN NGHIÊM NGẶT.

Không bao giờ đề xuất phương án đắt hơn hạn mức này.
Trong mỗi câu trả lời, nói rõ rằng mọi phương án đều nằm trong ngân sách
và bằng cách nào (ví dụ: "tất cả quà tặng không đắt hơn 45$").
`.trim();

Và bạn đưa budgetRule vào system‑prompt chung của GiftGenius.

Kiểm chứng offline

Chạy bộ golden cases “quà với ngân sách” qua phiên bản mới:

• LLM eval helpfulness tăng từ 6.0 lên 8.5;
• correctness cũng tăng: ngân sách được tuân thủ;
• safety không xấu đi (ít nhất là vậy).

Nếu ngược lại — helpfulness không tăng hoặc safety giảm — thay đổi không được chấp nhận và giả thuyết cần xem lại.

Thử nghiệm online

Tiếp theo, chạy thí nghiệm:

• 10% người dùng nhận phiên bản prompt mới (biến thể B);
• 90% còn lại — bản cũ (biến thể A).

Sau một tuần, bạn xem:

• tỉ lệ chuyển đổi workflow_completed → checkout_success với B là 13% thay vì 10% ở A;
• cost_per_task hầu như không đổi;
• tỷ lệ hội thoại phàn nàn “quá đắt” giảm.

Thí nghiệm được coi là thành công.

Cố định

Sau đó bạn:

• triển khai prompt mới cho 100% traffic;
• thêm golden case mới “ngân sách mềm tới 50$” vào bộ regression;
• ghi kết quả trong changelog và có thể trong tech notes: để sáu tháng sau vẫn hiểu vì sao prompt có câu chữ nghiêm ngặt về ngân sách.

Vòng lặp kết thúc. Lần lặp tiếp theo có thể liên quan tới gợi ý cho người có sở thích rất hiếm hoặc tối ưu chi phí lựa chọn.

8. Lộ trình mini cho App tự hoàn thiện

Để không trông như “thêm 100500 việc”, hữu ích là thấy mức tối thiểu cần có để App đã được coi là tự hoàn thiện, và những gì có thể bổ sung sau.

Phiên bản 1.0: vòng lặp cải tiến tối thiểu

Ở bước đầu, ba thứ là đủ.

Thứ nhất, log có cấu trúc và SLO cơ bản. Bạn đã biết log tool_invocation, workflow_completed, checkout_* kèm requestId, userId, scenario, appVersion, costEstimateUsd. Trên đó xây SLO: latency, error‑rate, thành công checkout.

Thứ hai, 10–20 golden cases và script LLM eval. Một bộ nhỏ nhưng chọn lọc tốt cho các kịch bản chính + safety cases. Một script CLI chạy chúng qua App và trọng tài và đưa ra điểm số JSON.

Thứ ba, một nghi thức đơn giản mỗi 2 tuần. Ngồi xuống (một mình hoặc cả team), mở:

• 2–3 dashboard về SLO, chi phí, metric sản phẩm;
• báo cáo LLM eval cho golden cases;

và chọn 1–2 giả thuyết cho vòng lặp tiếp theo. Diễn đạt, ghi nhận, làm một bản phát hành nhỏ, kiểm tra.

Phiên bản 2.0: vòng lặp cải tiến “thông minh”

Ở cấp độ kế tiếp sẽ có:

Trợ lý cải tiến nội bộ. Đây là một agent (hoặc ChatGPT App) mô tả riêng, nhận ImprovementInput và trả về ImprovementSuggestion. Nó giúp bạn không tốn hàng giờ dò thủ công hội thoại.

Báo cáo tự động. Dựa trên log và eval có thể tạo:

• cụm các case có vấn đề (ví dụ, mọi trường hợp người dùng viết lại ngân sách);
• bản nháp thay đổi prompt và mô tả tools “ready‑to‑use”;
• changelog ngắn.

CI hooks. Mọi thay đổi prompt, cấu hình agent, mô tả công cụ sẽ tự động kích hoạt:

• bộ golden functional;
• bộ safety.

Nếu safety cases trượt hoặc chất lượng các kịch bản chính không đạt ngưỡng — build đỏ, không có phát hành.

9. Thực hành

Bài tập 1. Vòng lặp phản hồi mini cho App của bạn

Chọn một kịch bản chủ chốt của ứng dụng bạn. Với GiftGenius, ta đã chọn “chọn và mua quà”, bạn có thể lấy kịch bản tương tự hoặc của riêng mình.

Mô tả tự do (hoặc tạo một improvement-plan.md nhỏ):

Bạn sẽ theo dõi những tín hiệu nào. Mỗi nhóm một mục:

• kỹ thuật: ví dụ, p95 latency của công cụ làm việc chính;
• kinh tế: cost_per_task cho kịch bản này;
• sản phẩm: chuyển đổi workflow_started → workflow_completed hoặc tới hành động mục tiêu;
• chất lượng: quality_score trung bình trên vài golden cases cho kịch bản này.

Tiếp theo, cố định ngưỡng nào bạn coi là suy giảm. Không phải “khi nào đó xem”, mà là rất cụ thể:

• p95 > 5 giây — tệ;
• cost_per_task tăng hơn 30% mà không tăng doanh thu — cảnh báo;
• quality_score giảm dưới 7 — cần điều tra.

Và hãy diễn đạt giả thuyết đầu tiên. Ví dụ:

“Tôi nghi ngờ rằng chúng ta đang hỏi quá nhiều câu làm rõ. Nếu rút gọn wizard đi một bước và làm câu hỏi chung hơn một chút, activation‑rate sẽ tăng còn helpfulness gần như không giảm. Tôi sẽ kiểm tra qua một thay đổi UX nhỏ và thí nghiệm A/B.”

Đây không còn là “cải thiện UX” chung chung, mà là một bước cụ thể trong vòng lặp.

Bài tập 2. Meta‑prompt cho trợ lý cải tiến

Hãy phác thảo văn bản prompt cho agent cải tiến nội bộ của App bạn. Có thể bắt đầu đơn giản:

• Mô tả nó là ai: “Bạn là analyst chất lượng của App N, người mà…”
• Liệt kê đầu vào nó nhận: hội thoại, tín hiệu, system‑prompt, descriptions.
• Đặt nhiệm vụ:
  • tìm 2–3 mẫu vấn đề;
  • đề xuất 1–2 thay đổi trong prompt, tools, nội dung UX;
  • soạn changelog ngắn.
• Mô tả định dạng trả lời: JSON có cấu trúc với các trường patterns, suggestions, changelog.

Ngay cả khi bạn chưa gọi agent này từ code, một prompt như vậy đã giúp bạn cấu trúc tốt hơn suy nghĩ về cách cải thiện App.

10. Lỗi thường gặp khi xây vòng lặp cải tiến

Lỗi số 1: tối ưu chỉ cho một metric.
Rất dễ bị cám dỗ tập trung vào một thứ. Có thể chỉ chạy theo cost, vui mừng vì hóa đơn OpenAI giảm — mà không nhận ra quality‑score, chuyển đổi và retention tụt dần. Hoặc ngược lại, vặn chất lượng lên 10/10 bằng model reasoning và quên rằng mỗi kịch bản giờ tốn cả đô. Vòng lặp cải tiến phải nhìn vào gói metric: chất lượng ↔ tiền ↔ hành vi người dùng.

Lỗi số 2: thay đổi prompt “ma thuật” không đo lường.
Câu “tôi đã viết lại system‑prompt, giờ chắc sẽ tốt hơn” mà không có golden cases và eval — là cách tự tạo bất ngờ sau vài tuần. Mọi thay đổi prompt — nhất là ở production — phải đi qua pipeline rõ ràng: bộ case, LLM eval trước/sau, và nếu cần — thí nghiệm online. Nếu không, bạn không cải thiện App mà chỉ ném chất lượng theo hướng ngẫu nhiên.

Lỗi số 3: auto‑deploy thay đổi từ LLM trợ lý.
Ngay cả khi trợ lý cải tiến viết các đoạn prompt cực kỳ hay và mô tả công cụ đầy thuyết phục, đó không phải lý do để push thẳng vào prod không review. Model không thấy hết ràng buộc kinh doanh, rủi ro safety, bối cảnh metric của bạn. Vai trò của nó — cố vấn, không phải DevOps có quyền phát hành.

Lỗi số 4: thay đổi không gắn với giả thuyết và tín hiệu.
Đôi khi team chỉnh “theo cảm giác” và không ghi lại tín hiệu nào dẫn tới thay đổi và họ đang kiểm tra giả thuyết gì. Hậu quả là sau một tháng không ai nhớ tại sao có đoạn lạ trong prompt và nó để làm gì. Một PR về chất lượng tốt tối thiểu phải trả lời ba câu hỏi: “đau ở đâu?”, “chúng ta thay đổi gì?”, “theo metric nào để biết tốt hơn?”.

Lỗi số 5: quên safety khi cải tiến.
Trong cuộc đua hữu ích rất dễ nới lỏng ràng buộc safety, bỏ “từ chối” dư trong prompt hoặc quên chạy safety cases. Mọi thay đổi system‑prompt, mô tả tools và agent behavior trước hết phải chạy qua bộ safety eval. Nếu bất kỳ case nào trước đây đỗ mà giờ trượt — đó là tín hiệu dừng, dù các metric khác có đẹp đến đâu.

Lỗi số 6: muốn “tối ưu tất cả cùng lúc”.
Viết lại nửa prompt, đổi model, thêm một MCP‑tool và wizard mới — tất cả trong một bản phát hành — nghe có vẻ hiệu quả, nhưng phá hủy khả năng hiểu thay đổi nào tạo hiệu ứng. Vòng lặp cải tiến chỉ hiệu quả khi lặp dần và tập trung: một‑hai giả thuyết, một gói thay đổi nhỏ, kế hoạch rollback rõ ràng.

Lỗi số 7: biến vòng lặp cải tiến thành “ngày tổng vệ sinh” hiếm hoi.
Nếu mỗi nửa năm bạn làm một “ngày chất lượng” hoành tráng, còn các tháng khác sống không eval và không phân tích metric, App sẽ “trôi theo dòng” phần lớn thời gian. Hữu ích hơn là nghi thức nhỏ nhưng đều đặn: mỗi tuần/hai tuần xem tín hiệu, cập nhật giả thuyết và đi những bước nhỏ. Chính như vậy ChatGPT App của bạn mới thôi tĩnh tại và bắt đầu thực sự tự hoàn thiện.