‹ Tất cả Domain 2 Làm quiz

Domain 2 · 13% đề thi · Claude Models & Prompting

Model, prompt và context

Ba thứ này là một bài toán chung. Model quyết định chi phí và tốc độ. Cấu trúc prompt quyết định cache có hoạt động không. Cách sắp xếp context quyết định model có chú ý đến thứ bạn gửi hay không.

Chọn model: Opus, Sonnet hay Haiku

Quy tắc chọn

  1. Bắt đầu với Sonnet, theo nguồn ôn tập.
  2. Chỉ lên Opus khi eval cho thấy có lỗi suy luận.
  3. Chỉ xuống Haiku khi eval cho thấy độ chính xác vẫn đủ.

Mỗi lần đổi model đều cần bằng chứng, nên phải có bộ eval trước. Với mỗi model, đo 3 thứ: độ chính xác trên một bộ input cố định, độ trễ ở đúng percentile trong SLA, và chi phí mỗi request ở lưu lượng dự kiến.

Đã đối chiếu tài liệu chính thức

Docs hiện tại ghi đa số workload bắt đầu từ Opus 5.5, với hai hướng: bắt đầu từ model mạnh rồi tối ưu dần, hoặc bắt đầu từ Haiku rồi chỉ nâng khi cần. Nguồn ôn tập lấy Sonnet làm mặc định. Hai bên giống nhau ở điểm quan trọng nhất: quyết định bằng eval trên dữ liệu thật. Xem docs

Định tuyến theo độ khó

Dùng Haiku để phân loại và xử lý ca đơn giản, rồi chuyển ca khó lên Sonnet hoặc Opus. Đây là cách phổ biến để giảm chi phí cho hệ thống có lưu lượng lớn.

Việc khối lượng lớn nhưng không gấp thì dùng Message Batches API: giảm 50% chi phí, xử lý trong vòng 24 giờ. Xem thêm ở Domain 4.

Bẫy đề thi

Streaming giúp người dùng thấy nhanh hơn. Batch giúp giảm chi phí. Cả hai đều không làm model suy luận giỏi hơn. Chọn model trước rồi mới làm eval để biện minh là sai thứ tự.

Quy trình chọn model

  1. Xác định yêu cầu: mức chất lượng, độ trễ chấp nhận được, lưu lượng dự kiến.
  2. Chọn model ứng viên dựa trên yêu cầu và năng lực đã biết.
  3. Chạy một mẫu đại diện trên model đó, dùng prompt và dữ liệu thật.
  4. Chọn model nhẹ nhất luôn đạt mức chất lượng trên mẫu.
  5. Kiểm tra lại khi có phiên bản model mới.

Bẫy đề thi

Bước 1 và 2 phải xong trước khi chạy thử. Chọn model nhẹ nhất, duyệt rollout và kiểm tra lại đều là việc diễn ra sau khi đã có kết quả chạy thử.

Đã đối chiếu tài liệu chính thức

Docs nêu thêm: trên một số model, điều chỉnh tham số effort thường là cách tốt hơn đổi model để cân bằng độ thông minh với độ trễ và chi phí. Xem docs

Viết prompt

Đã đối chiếu tài liệu chính thức

Docs hiện coi CoT viết tay là phương án dự phòng khi thinking đang tắt. Trên các model mới có thinking, nên dùng thinking thay vì tự viết từng bước. Ý chính cho đề thi vẫn vậy: bài toán nhiều bước cần model suy luận trước khi trả lời, và phải đổi bằng thêm token, thời gian. Xem docs

Ví dụ từ chối (correct rejection)

Đây là ví dụ cho thấy khi nào model phải từ chối hoặc trả về rỗng. Nếu model tự bịa khi thiếu dữ liệu, hãy thêm loại ví dụ này. Thêm ví dụ trả lời đúng không giải quyết được lỗi đó.

Chỉ dẫn mâu thuẫn

Nếu prompt vừa bảo không được suy đoán ngoài nguồn, vừa bảo cứ tự tin điền vào chỗ trống, hãy xóa hoặc viết lại một trong hai câu. Thêm quy tắc ưu tiên chung chung hay đổi temperature đều không giải quyết được mâu thuẫn.

Thứ tự trong system prompt

  1. Vai trò của model.
  2. Tiêu chí kiểm tra được.
  3. Ranh giới: những gì không bao giờ được làm.
  4. Định dạng đầu ra, đặt ở cuối cùng.

Tiêu chí kiểm tra được

Không kiểm tra được: “Cố gắng hữu ích nhưng đừng tư vấn cổ phiếu.”

Kiểm tra được: “Từ chối mọi yêu cầu khuyến nghị mua hoặc bán một mã cổ phiếu cụ thể.”

Prompt caching

Cache lưu lại phần đầu của prompt đã xử lý. Nếu lần gọi sau có phần đầu y hệt, API đọc từ cache nên rẻ và nhanh hơn. Hình dung như sách có đánh dấu trang: một chữ ở trang đầu thay đổi thì phải đọc lại từ đó trở đi.

Quy tắc sắp xếp: phần ổn định trước, phần thay đổi sau.

Tài liệu lớn được hỏi nhiều lần: cache hay RAG?

Cache hợp khi các câu hỏi đến gần nhau trong thời hạn cache và cần toàn bộ tài liệu. Nếu câu hỏi rải rác qua nhiều ngày, cache sẽ hết hạn giữa các lần, và mỗi lần gửi cả tài liệu vẫn tốn nhiều. Khi đó RAG lấy đúng đoạn cần thiết thường hợp hơn.

3 lỗi làm hỏng cache

  1. Đặt timestamp ở đầu system prompt. Lỗi này hay gặp nhất.
  2. Đổi thứ tự định nghĩa tool giữa các lần gọi.
  3. Xáo trộn tài liệu tham chiếu, kể cả khi retrieval trả về cùng các đoạn nhưng khác thứ tự.

Bẫy đề thi

Chỉ cần đổi một ký tự, cache hỏng từ điểm đó trở đi. Chuyển timestamp ra giữa prefix vẫn làm mất cache của toàn bộ phần sau nó. Phải chuyển xuống sau breakpoint.

Đã đối chiếu tài liệu chính thức

  • Ngưỡng tối thiểu tùy từng model, từ 512 đến 4.096 token. Nguồn ôn tập ghi Sonnet và Haiku là 1.024, Opus là 2.048, nhưng cách chia theo tier này không khớp bảng hiện tại. Hãy nhớ nguyên lý và tra bảng khi làm thật.
  • Dưới ngưỡng thì API không báo lỗi, chỉ không cache. Dấu hiệu là cache_creation_input_tokens và cache_read_input_tokens đều bằng 0. Đếm token trước khi gửi bằng endpoint count_tokens. Docs ghi kết quả là ước tính, có thể lệch nhỏ.
  • Thứ tự của cache là tools, system, messages. Nguồn ôn tập có câu xếp system trước tool, thứ tự đó không khớp với API.
  • Giá so với input thường: ghi cache gấp 1,25 lần (5 phút) hoặc 2 lần (1 giờ). Đọc cache bằng 0,1 lần trên đa số model, một số model mới còn thấp hơn.
  • Cache tồn tại 5 phút theo mặc định và được làm mới mỗi lần dùng. Khi các lần gọi cách nhau lâu hơn, có thể chọn TTL 1 giờ. Xem docs

Sắp xếp context

Model không chú ý đều trên toàn bộ context. Phần đầu và phần cuối được chú ý nhiều nhất, thông tin ở giữa dễ bị bỏ sót. Hiện tượng này gọi là “lost in the middle”. Nhiều lỗi trông như hallucination thực ra chỉ là đặt dữ liệu sai chỗ.

Bẫy đề thi

Thêm câu “hãy chú ý phần giữa” không sửa được lỗi này. Hãy đưa dữ liệu quan trọng ra hai đầu hoặc cắt bớt phần thừa. Context window lớn hơn cũng không giải quyết được.

Các cách giữ context gọn

Lưu ý khi tóm tắt lịch sử (progressive summarization): các giá trị cụ thể như mã đơn hàng hay ngày tháng dễ bị mờ đi, dẫn đến câu trả lời sai mà rất tự tin.

Bẫy về độ trễ: đừng tạo subagent để lấy dữ liệu mà coordinator đã có sẵn trong context. Việc đó chỉ thêm một vòng xử lý.

Đã đối chiếu tài liệu chính thức

Docs khuyên đặt tài liệu dài ở đầu prompt, phía trên câu hỏi, chỉ dẫn và ví dụ. Đặt câu hỏi ở cuối có thể tăng chất lượng câu trả lời đến 30% trong các bài test, nhất là khi có nhiều tài liệu. Xem docs

Quản lý token theo vòng đời request

Mỗi cách tiết kiệm token tác động ở một giai đoạn. Đề có thể yêu cầu xếp từng cách vào đúng giai đoạn.

Nhiều tool cũng là rủi ro bảo mật

Catalog 100 tool làm giảm độ chính xác khi chọn tool và tốn thêm token. Mỗi tool thừa còn là một điểm có thể bị lợi dụng. Agent chỉ phân loại ticket mà có tool hoàn tiền và xóa dữ liệu thì có thể bị dẫn dụ làm việc vượt quyền.

3 câu hỏi trước khi cấp tool

  1. Việc hiện tại có cần tool này không?
  2. Vai trò của agent có đủ lý do để gây ra thay đổi mà tool này tạo ra không?
  3. Có kiểm tra chắc chắn bằng code trước các hành động không thể hoàn tác không?

Chẩn đoán nhanh

Lỗi API: có nên thử lại?

Đã đối chiếu tài liệu chính thức

Header ID của request tên là request-id, nguồn ôn tập ghi nhầm là anthropic-request-id. ID này dùng để truy vết và gửi cho bộ phận hỗ trợ, không phải cơ chế chống gửi trùng. Xem docs

Docs hiện chỉ còn alias cho các model trước thế hệ 4.6. Từ 4.6 trở đi, mỗi model ID là một bản cố định. Nguồn ôn tập lấy ví dụ -latest, nhưng trang Model IDs không có dạng này. Xem docs

Nhớ nhanh

Quiz Domain 2

3 bài · 30 câu