Review đa instance và xác thực Output

Những điều bạn cần biết

Khi Claude tự review output của chính nó, nó có một bất lợi mang tính cấu trúc: nó vẫn giữ nguyên ngữ cảnh lý luận (reasoning context) từ lúc tạo ra output đó. Model nhớ tại sao nó đưa ra từng quyết định và vì vậy ít có khả năng đặt lại nghi vấn với những quyết định đó. Đây không phải là một lỗi — đó là một đặc tính vốn có của việc tự review trong cùng một phiên. Hiểu rõ hạn chế này và thiết kế xung quanh nó là trọng tâm của task statement này.

Hạn chế của việc tự review

Một model tự review output của chính nó trong cùng một phiên hội thoại vẫn giữ nguyên chuỗi lý luận ban đầu. Nó đã "biết" tại sao nó chọn từng cách tiếp cận, phân loại từng phát hiện ở một mức độ nghiêm trọng cụ thể, hay chọn các giá trị nhất định. Khi được yêu cầu review, nó có xu hướng xác nhận lại thay vì thách thức những quyết định đó.

Một instance độc lập — một lời gọi Claude riêng biệt không mang theo ngữ cảnh lý luận trước đó — tiếp cận output một cách hoàn toàn mới mẻ. Nó đánh giá code, các phát hiện, hoặc kết quả trích xuất chỉ dựa trên những gì nó thấy, không bị thiên vị bởi kiểu suy nghĩ "tôi chọn cái này vì...". Điều này khiến việc review độc lập hiệu quả hơn hẳn trong việc phát hiện những vấn đề tinh vi.

Đề thi kiểm tra điều này một cách trực tiếp. Khi được đưa ra các phương án để cải thiện chất lượng review, đáp án đúng là dùng một instance model riêng biệt, chứ không phải thêm chỉ dẫn "hãy review thật cẩn thận" vào cùng phiên đó, hay dựa vào extended thinking trong chính phiên đã tạo ra output.

typescriptCopy

// Anti-pattern: self-review in the same session
const generation = await client.messages.create({
  messages: [
    { role: "user", content: "Write a function to process orders" },
    { role: "assistant", content: generatedCode },
    { role: "user", content: "Now review your code for bugs" }
    // Model retains its reasoning — less likely to find its own mistakes
  ]
});
 
// Correct: independent review instance
const review = await client.messages.create({
  messages: [
    {
      role: "user",
      content: `Review this code for bugs, security issues, and edge cases:\n\n${generatedCode}`
    }
    // Fresh instance — no prior reasoning context
  ]
});

Kiến trúc review đa lượt (multi-pass)

Các review lớn (PR nhiều file, pipeline trích xuất phức tạp, audit code trên diện rộng) gặp phải hiện tượng pha loãng chú ý (attention dilution) khi được xử lý trong một lượt duy nhất. Các triệu chứng rất cụ thể và dễ nhận ra:

• Phản hồi chi tiết ở một số file, nhận xét sơ sài ở những file khác
• Bỏ sót những bug rõ ràng nằm ở giữa quá trình review
• Các phát hiện mâu thuẫn nhau — gắn cờ một mẫu code là có vấn đề ở file này nhưng lại chấp thuận đoạn code giống hệt ở nơi khác

Cách khắc phục là chia nhỏ quá trình review thành các lượt tập trung:

Lượt 1: Phân tích cục bộ theo từng file. Phân tích từng file riêng lẻ với một prompt review tập trung. Điều này đảm bảo độ sâu nhất quán trên tất cả các file. Mỗi lần gọi chỉ xem xét đúng một file, nên model dồn toàn bộ sự chú ý vào đó.

Lượt 2: Tích hợp liên file. Sau khi tất cả các phân tích theo từng file hoàn tất, chạy một lượt riêng biệt tiếp nhận toàn bộ các phát hiện theo từng file và kiểm tra các vấn đề liên file: luồng dữ liệu giữa các module, tính nhất quán trong cách dùng API qua các service, xung đột phụ thuộc, và các mâu thuẫn ngay trong chính các phát hiện theo từng file.

typescriptCopy

// Pass 1: Per-file analysis
const perFileFindings = await Promise.all(
  files.map(file =>
    client.messages.create({
      messages: [{
        role: "user",
        content: `Review this file for local issues (bugs, security, logic errors):\n\n${file.content}`
      }]
    })
  )
);
 
// Pass 2: Cross-file integration
const integrationReview = await client.messages.create({
  messages: [{
    role: "user",
    content: `Given these per-file findings, identify cross-file issues:\n` +
      `- Data flow inconsistencies between modules\n` +
      `- Contradictory patterns flagged in different files\n` +
      `- API contract violations across service boundaries\n\n` +
      `Findings:\n${JSON.stringify(perFileFindings)}`
  }]
});

Kiến trúc này giải quyết trực tiếp cả ba triệu chứng của pha loãng chú ý. Các lượt theo từng file đảm bảo độ sâu nhất quán. Lượt tích hợp bắt được các vấn đề liên file mà không một review đơn file nào có thể phát hiện ra. Và việc tách biệt các lượt này ngăn các phát hiện mâu thuẫn xuất hiện trong cùng một output.

Tại sao context window lớn hơn không giải quyết được vấn đề này

Đề thi đưa vào một phương án gây nhiễu cụ thể: "chuyển sang một model cấp cao hơn với context window lớn hơn." Nghe có vẻ hợp lý — nếu model không xử lý được 14 file cùng lúc, hãy cho nó thêm dung lượng. Nhưng vấn đề không nằm ở kích thước context. Nó nằm ở chất lượng sự chú ý. Một context window lớn hơn không ngăn được việc model dồn sự chú ý không đồng đều giữa các file. Chỉ có các lượt tập trung theo từng file mới đảm bảo được độ sâu nhất quán.

Định tuyến dựa trên độ tin cậy

Đối với những phát hiện chưa chắc chắn, model có thể tự báo cáo độ tin cậy đi kèm mỗi phát hiện. Điều này cho phép một chiến lược định tuyến:

• Phát hiện có độ tin cậy cao: Báo cáo trực tiếp cho developer
• Phát hiện có độ tin cậy thấp: Định tuyến sang cho con người review để xác thực
• Hiệu chỉnh ngưỡng: Dùng các tập dữ liệu xác thực đã gán nhãn để hiệu chỉnh điểm tin cậy nào tương quan với độ chính xác thực tế

jsonCopy

{
  "finding": "Potential race condition in order processing",
  "severity": "major",
  "confidence": 0.65,
  "reasoning": "The lock acquisition pattern appears correct but the unlock timing depends on an async callback whose ordering I cannot fully verify.",
  "route": "human_review"
}

Điểm tin cậy không phải là độ chính xác tự báo cáo — nó là đánh giá của model về mức độ chắc chắn của chính nó. Hãy hiệu chỉnh nó bằng cách chạy các ví dụ đã gán nhãn (những trường hợp bạn đã biết đáp án đúng) qua hệ thống và đo mối quan hệ giữa độ tin cậy được báo cáo và độ chính xác thực tế. Điều chỉnh ngưỡng định tuyến dựa trên dữ liệu hiệu chỉnh này.

Đề thi phân biệt giữa điểm tin cậy thô (chưa hiệu chỉnh, không đáng tin cho các quyết định tự động) và ngưỡng tin cậy đã hiệu chỉnh (đã được xác thực trên các tập đã gán nhãn, phù hợp để định tuyến). Dùng độ tin cậy chưa hiệu chỉnh cho các quyết định tự động là một anti-pattern.

Kết hợp tất cả lại

Một kiến trúc review dành cho production kết hợp cả ba khái niệm trên:

1. Tạo (generation): Instance đầu tiên tạo ra code, kết quả trích xuất, hoặc phân tích
2. Review theo từng file: Các instance độc lập review từng đơn vị output riêng lẻ
3. Review tích hợp: Một instance riêng biệt kiểm tra tính nhất quán liên đơn vị
4. Định tuyến theo độ tin cậy: Các phát hiện có độ tin cậy thấp được chuyển cho con người review
5. Vòng lặp hiệu chỉnh: Các tập dữ liệu xác thực đã gán nhãn liên tục hiệu chỉnh lại ngưỡng tin cậy

Kiến trúc này tốn kém hơn so với review một lượt duy nhất. Sự đánh đổi này xứng đáng khi chất lượng review ảnh hưởng trực tiếp đến độ tin cậy của production — pipeline CI/CD, trích xuất dữ liệu tài chính, phân tích tuân thủ, và bất kỳ hệ thống nào mà việc bỏ sót vấn đề sẽ gây hậu quả ở các khâu sau.

Bẫy thi

Tình huống luyện tập

Không tìm thấy câu hỏi luyện tập "q-4-6-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Task Statement 4.6 — Anthropic
• Prompt Engineering Overview — Anthropic
• Building with Claude API (Skilljar) — Anthropic