4.6 Multi-Instance and Multi-Pass Review

Những gì cần nắm

Khi Claude review chính output của mình, nó đã ở thế bất lợi ngay từ đầu: nó vẫn mang theo chuỗi lập luận đã dùng để tạo ra output đó. Model nhớ vì sao nó quyết định như vậy, nên ít có xu hướng đặt lại câu hỏi. Đó không phải bug. Đó đơn giản là cách self-review hoạt động bên trong một session. Việc của bạn là thiết kế để né nó.

Giới hạn của self-review

Một model review output của chính nó trong cùng một session hội thoại vẫn giữ nguyên chuỗi lập luận ban đầu. Nó đã “biết” vì sao chọn cách tiếp cận đó, vì sao xếp phát hiện này vào mức severity đó, vì sao chọn những giá trị kia. Khi bị yêu cầu review, nó có xu hướng xác nhận thay vì chất vấn các quyết định ấy.

Một instance độc lập — một lần gọi Claude riêng, không mang theo context lập luận trước đó — tiếp cận output với con mắt mới. Nó đánh giá code, phát hiện hay kết quả extraction dựa trên đúng thứ nó thấy, không bị thiên lệch bởi “tôi chọn cái này vì…”. Đó là lý do review độc lập bắt được vấn đề tinh vi tốt hơn hẳn.

Đề thi hỏi thẳng điểm này. Khi đưa ra các phương án cải thiện chất lượng review, đáp án đúng là dùng một model instance riêng, không phải thêm chỉ dẫn “please review carefully” vào cùng session hay trông cậy vào extended thinking trong chính session đã sinh ra output.

// 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 multi-pass review

Các đợt review lớn (PR nhiều file, pipeline extraction phức tạp, audit code diện rộng) bị attention dilution khi xử lý trong một lượt duy nhất. Triệu chứng rất cụ thể và dễ nhận ra:

Phản hồi chi tiết ở file này, nhận xét hời hợt ở file khác
Bỏ sót bug hiển nhiên ở khoảng giữa đợt review
Phát hiện mâu thuẫn nhau — flag một pattern là có vấn đề ở file này nhưng chấp nhận đúng đoạn code đó ở file khác

Cách sửa là tách đợt review thành nhiều lượt có tiêu điểm:

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. Cách này đảm bảo độ sâu đồng đều trên mọi file. Mỗi lần gọi chỉ soi 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 xong toàn bộ phân tích theo file, chạy một lượt riêng nhận vào tất cả phát hiện của từng file và kiểm tra các vấn đề liên file: luồng dữ liệu giữa các module, cách dùng API nhất quán giữa các service, xung đột dependency, và cả mâu thuẫn giữa chính các phát hiện theo file.

// 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 xử lý thẳng cả ba triệu chứng của attention dilution. Lượt theo từng file đảm bảo độ sâu đồng đều. Lượt tích hợp bắt được các vấn đề liên file mà không lượt review đơn file nào nhận ra. Và việc tách lượt ngăn những phát hiện mâu thuẫn xuất hiện trong cùng một output.

Vì sao context window lớn hơn không sửa được chuyện này

Đề thi có một đáp án nhiễu rất cụ thể: “chuyển sang model bậc cao hơn với context window lớn hơn”. Nghe rất hợp lý — model không kham nổi 14 file cùng lúc thì 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 chú ý. Context window to hơn không ngăn được việc model rải sự chú ý không đều qua các file. Chỉ có các lượt tập trung theo từng file mới đảm bảo độ sâu đồng đều.

Routing theo confidence

Với những phát hiện không chắc chắn, model có thể tự báo confidence kèm theo mỗi phát hiện. Từ đó dựng được một chiến lược routing:

Phát hiện confidence cao: Báo thẳng cho developer
Phát hiện confidence thấp: Đẩy sang human review để kiểm chứng
Calibrate ngưỡng: Dùng tập validation đã gán nhãn để xác định mức confidence nào tương quan với độ chính xác thật

{
  "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"
}

Confidence score không phải độ chính xác tự báo. Nó là cảm nhận của model về mức chắc chắn của chính nó. Hãy calibrate nó bằng cách cho các ví dụ đã gán nhãn (bạn đã biết đáp án) chạy qua hệ thống và đo xem confidence báo ra bám sát độ chính xác thật đến đâu. Rồi chỉnh ngưỡng routing theo dữ liệu đó.

Đề thi phân biệt giữa confidence score thô (chưa calibrate, không đáng tin cho quyết định tự động) và ngưỡng confidence đã calibrate (kiểm chứng trên tập gán nhãn, dùng cho routing được). Dùng confidence chưa calibrate cho quyết định tự động là anti-pattern.

Ghép mọi thứ lại

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

Generation: Instance đầu tiên sinh code, extraction hoặc phân tích
Review theo file: Các instance độc lập review từng đơn vị output riêng lẻ
Review tích hợp: Một instance riêng kiểm tra tính nhất quán giữa các đơn vị
Routing theo confidence: Phát hiện confidence thấp đi sang human review
Vòng calibrate: Tập validation đã gán nhãn liên tục calibrate ngưỡng confidence

Kiến trúc này đắt hơn review một lượt. Đánh đổi đó đáng giá khi chất lượng review ảnh hưởng trực tiếp tới độ tin cậy trên production — pipeline CI/CD, extraction tài chính, phân tích tuân thủ, và mọi hệ thống mà một vấn đề bị bỏ sót sẽ gây hậu quả phía sau.

Bẫy thi

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

Một pull request sửa 14 file nhận được kết quả review không đồng đều: phản hồi chi tiết ở vài file, nhận xét hời hợt ở những file khác, bỏ sót bug hiển nhiên, và các phát hiện mâu thuẫn nhau — cùng một pattern bị flag là có vấn đề ở file này nhưng được chấp nhận ở file khác. Nên tái cấu trúc quy trình review thế nào?

A. Chuyển sang model bậc cao hơn với context window lớn hơn nhiều để cả 14 file đều được chú ý đầy đủ trong một lượt review duy nhất
B. Tách thành các lượt phân tích cục bộ theo từng file để độ sâu đồng đều, rồi chạy một lượt tích hợp liên file riêng cho các vấn đề luồng dữ liệu
C. Chạy ba lượt review độc lập trên toàn bộ PR và chỉ flag những vấn đề mà ít nhất hai trong ba lượt cùng đồng ý
D. Bắt developer chia pull request lớn thành các lần submit nhỏ 3–4 file trước khi chạy review tự động

Đáp án & giải thích

Đúng: B

A — Context window lớn hơn không giải quyết được vấn đề chất lượng chú ý. Model chứa được nhiều chữ hơn nhưng vẫn rải sự chú ý không đều qua các file. Đây là vấn đề attention dilution, không phải vấn đề kích thước context.
B — Phân tích theo từng file đảm bảo mọi file đều được chú ý đồng đều và tập trung. Lượt tích hợp riêng bắt được các vấn đề liên file mà không lượt review đơn file nào nhận ra. Cách này xử lý thẳng cả ba triệu chứng: độ sâu không đồng đều, bug bị bỏ sót, và phát hiện mâu thuẫn.
C — Cách này bóp nghẹt khả năng phát hiện bug thật vì đòi hỏi đồng thuận cho những vấn đề chỉ thi thoảng mới bắt được. Nó đánh đổi độ nhạy lấy sự nhất quán giả.
D — Cách này đẩy gánh nặng sang developer và thay đổi quy trình của team mà không cải thiện chính hệ thống review. Hệ thống nên xử lý được PR lớn bằng kiến trúc tốt hơn.

Nguồn

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

Exam Simulator

Sáu câu trắc nghiệm theo format đề thi về Multi-Instance and Multi-Pass Review. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

Một pull request sửa 14 file nhận được kết quả review không đồng đều: phản hồi chi tiết ở vài file, nhận xét hời hợt ở những file khác, bỏ sót bug hiển nhiên, và các phát hiện mâu thuẫn nhau (cùng một pattern bị flag ở file này nhưng được chấp nhận ở file khác). Nên tái cấu trúc quy trình review thế nào?

A. Chuyển sang model bậc cao hơn với context window lớn hơn để xử lý cả 14 file trong một lượt
B. Các lượt phân tích cục bộ theo từng file để độ sâu đồng đều, rồi một lượt liên file riêng cho vấn đề luồng dữ liệu
C. Chạy ba lượt review độc lập trên toàn bộ PR và chỉ flag vấn đề xuất hiện ở ít nhất hai trong ba lượt
D. Bắt developer chia PR lớn thành các lần submit nhỏ 3–4 file trước khi chạy review tự động

Đáp án & giải thích

Đúng: B

A sai vì context window lớn hơn không giải quyết được vấn đề chất lượng chú ý. Model chứa được nhiều chữ hơn nhưng vẫn rải sự chú ý không đều qua các file.
B đúng vì phân tích theo từng file đảm bảo mọi file đều được chú ý đồng đều và tập trung. Lượt tích hợp bắt được vấn đề liên file và các mâu thuẫn.
C sai vì đòi hỏi đồng thuận 2/3 lượt sẽ bóp nghẹt khả năng phát hiện bug thật. Có những bug chỉ thi thoảng mới bắt được.
D sai vì cách này đẩy gánh nặng sang developer mà không cải thiện chính hệ thống review.

Câu 2

Vì sao self-review (bảo model review output của chính nó trong cùng session hội thoại) kém hiệu quả hơn review độc lập?

A. Model vẫn giữ context lập luận và ít chất vấn quyết định của chính nó
B. Self-review tốn nhiều token hơn review độc lập, làm giảm chất lượng output
C. Model quên output trước đó nên không so sánh chính xác được
D. Self-review chậm hơn vì model phải xử lý lại toàn bộ lịch sử hội thoại

Đáp án & giải thích

Đúng: A

A đúng vì model nhớ vì sao nó quyết định như vậy và có xu hướng xác nhận thay vì chất vấn các quyết định đó. Một instance độc lập đánh giá output với con mắt mới.
B sai vì lượng token không phải vấn đề. Thiên lệch do giữ lại context lập luận mới là vấn đề.
C sai vì model không quên — nó giữ nguyên toàn bộ context hội thoại, và đó chính là vấn đề thật.
D sai vì tốc độ không phải vấn đề. Chất lượng review thấp là do context lập luận được giữ lại.

Câu 3

Multi-pass code review của bạn chạy phân tích theo từng file trên 10 file. Lượt tích hợp liên file nên kiểm tra gì?

A. Tính nhất quán về ngữ pháp và chính tả trong comment giữa các file
B. Mỗi file có compile độc lập được hay không
C. Vấn đề luồng dữ liệu, mâu thuẫn, và vi phạm hợp đồng API
D. Tổng số dòng và các chỉ số độ phức tạp code trên toàn PR

Đáp án & giải thích

Đúng: C

A sai vì kiểm tra ngữ pháp không phải mục đích của lượt tích hợp liên file.
B sai vì kiểm tra compile là việc của build system, không phải của khâu tích hợp review.
C đúng vì lượt tích hợp bắt được các vấn đề mang tính hệ thống mà không lượt review đơn file nào nhận ra: vấn đề luồng dữ liệu, mâu thuẫn giữa các phát hiện theo file, và vi phạm hợp đồng API giữa các service.
D sai vì thu thập chỉ số là việc tách biệt với chất lượng review. Lượt tích hợp nhắm vào các vấn đề logic liên file.

Câu 4

Hệ thống review của bạn gắn confidence score cho mỗi phát hiện. Một phát hiện có confidence 0.92 nhưng khi kiểm chứng độc lập thì hóa ra sai. Điều này cho thấy gì?

A. Model bị lỗi và nên thay bằng model khác
B. Bên kiểm chứng độc lập đã sai; phát hiện confidence cao luôn đúng
C. Confidence trên 0.90 nên được chấp nhận tự động, không cần review
D. Confidence thô do model tự báo là chưa được calibrate

Đáp án & giải thích

Đúng: D

A sai vì confidence calibrate tệ là đặc tính đã biết, không phải lỗi hỏng.
B sai vì instance độc lập tiếp cận phát hiện với con mắt mới và có thể chính xác hơn mức confidence tự đánh giá.
C sai vì chính câu hỏi này cho thấy chấp nhận tự động các phát hiện confidence cao là rủi ro khi chưa calibrate.
D đúng vì confidence thô do model tự báo không tương quan đáng tin với độ chính xác. Calibrate bằng tập validation đã gán nhãn mới lộ ra quan hệ thật và cho phép đặt ngưỡng routing đáng tin.

Câu 5

Nên calibrate ngưỡng confidence để route phát hiện sang human review bằng cách nào?

A. Đặt ngưỡng ở 0.5 vì đó là điểm giữa giữa chắc chắn và không chắc chắn
B. Cho tập validation đã gán nhãn chạy qua hệ thống rồi đối chiếu confidence báo ra với độ chính xác thật
C. Bảo model tự calibrate bằng cách báo cáo thống kê độ chính xác của chính nó
D. Hạ dần ngưỡng cho tới khi không phát hiện nào phải sang human review, tối ưu cho hiệu suất

Đáp án & giải thích

Đúng: B

A sai vì một điểm giữa tùy tiện không có cơ sở thực nghiệm nào. Quan hệ giữa confidence score và độ chính xác khác nhau theo từng tác vụ.
B đúng vì tập validation đã gán nhãn cung cấp ground truth. Đo confidence so với độ chính xác thật cho thấy ngưỡng nào tạo ra routing đáng tin.
C sai vì việc model tự đánh giá độ chính xác của mình cũng dính đúng vấn đề calibration như confidence score.
D sai vì loại bỏ human review là gỡ mất lưới an toàn cho những phát hiện không chắc chắn, làm giảm chất lượng tổng thể.

Câu 6

Một kiến trúc review production kết hợp generation, review theo file, review tích hợp, routing theo confidence và calibration. Nó đắt hơn review một lượt. Khi nào chi phí này là xứng đáng?

A. Luôn luôn — không bao giờ được đánh đổi chất lượng lấy chi phí
B. Chỉ khi dùng batch API để bù chi phí multi-pass bằng mức tiết kiệm 50%
C. Chỉ với codebase có hơn 100 file
D. Khi chất lượng review ảnh hưởng trực tiếp tới độ tin cậy trên production phía sau

Đáp án & giải thích

Đúng: D

A sai vì đánh đổi chi phí – chất lượng là điều cần thiết. Không phải đợt review nào cũng cần kiến trúc multi-pass.
B sai vì batch API xử lý chuyện chi phí và thời điểm, không xử lý chất lượng review. Quyết định dùng multi-pass phụ thuộc yêu cầu chất lượng, không phụ thuộc lựa chọn API.
C sai vì kích thước codebase không phải yếu tố quyết định. Một PR 5 file trong hệ thống tài chính vẫn có thể đáng chạy multi-pass review.
D đúng vì chi phí multi-pass là xứng đáng khi vấn đề bị bỏ sót gây hậu quả thật phía sau — hệ thống production, dữ liệu tài chính, yêu cầu tuân thủ.