[Hướng dẫn 7/10] Prompt AI cho tóm tắt, bảng biểu và phân tích tài liệu

Hướng dẫn Prompt Engineering · Phần 7/10. Đây là phần ứng dụng: bạn cần nắm kiến thức cơ bản từ Phần 1–6. Mới theo dõi chuỗi bài? Hãy bắt đầu với Phần 1: Prompt engineering là gì và vì sao quan trọng.

Phần lớn công việc văn phòng là đọc: báo cáo, biên bản họp, hợp đồng, quy định. Prompt AI cho tóm tắt, bảng biểu và phân tích tài liệu là một trong những kỹ năng hữu ích nhất của chuỗi bài này, nhưng cũng là nơi một prompt cẩu thả gây hại âm thầm: bản tóm tắt bỏ mất con số quan trọng, hoặc một số liệu bị chép sai.

Dưới đây là các prompt dùng ngay cho tám việc, từ tóm tắt và action item đến kiểm tra số liệu và rà soát hợp đồng, mỗi prompt kèm kết quả mẫu và lý do nó hiệu quả.

Các prompt chạy được trên ChatGPT, Claude và Gemini, và dùng dấu phân cách (như <document>) cùng định dạng đầu ra tường minh; nếu bạn chưa quen, hãy đọc Cấu trúc prompt: năm thành phần của một prompt trước.

Prompt tóm tắt: kiểm soát người đọc, độ dài, định dạng và trọng tâm

Một bản tóm tắt chỉ hữu ích với một người đọc cụ thể. Câu "Tóm tắt giúp tôi" buộc mô hình phải đoán, nên bạn nhận về một bản tổng quan chung chung. Hãy nêu rõ bốn điều: người đọc, độ dài, định dạng và trọng tâm.

Đặt tài liệu lên trước, hướng dẫn đặt sau. Hướng dẫn prompting của Anthropic khuyến nghị đặt tài liệu dài phía trên câu hỏi. Đây là tài liệu mẫu được dùng xuyên suốt bài viết:

Báo cáo vận hành Q3 2026: Nền tảng hỗ trợ

Số ticket tăng lên 18,400, tăng 12% so với Q2 (16,430). Thời gian phản hồi đầu tiên trung vị cải thiện từ 3.1 giờ xuống 2.4 giờ sau khi chúng tôi thêm ca làm việc cuối tuần vào tháng 7. Mức độ hài lòng của khách hàng (CSAT) giữ ở 91%. Chi phí cloud là $42,800, vượt 9% so với ngân sách $39,300, chủ yếu do dung lượng lưu log tăng nhanh hơn kế hoạch. Hai sự cố làm vi phạm SLA uptime 99.9%: một lần failover cơ sở dữ liệu kéo dài 47 phút vào ngày 14 tháng 8 và một lần sự cố DNS kéo dài 22 phút vào ngày 3 tháng 9. Nhân sự giữ nguyên 14 agent; một agent cấp cao nghỉ việc vào tháng 9 và vị trí này đang tuyển. Quý tới chúng tôi dự kiến chuyển log cũ hơn 30 ngày sang cold storage, dự kiến tiết kiệm khoảng $3,000 mỗi tháng.

Mẫu prompt. Thay bốn giá trị trong dấu ngoặc nhọn:

<document>
{paste the document here}
</document>

Tóm tắt tài liệu trên.
- Người đọc: {ai sẽ đọc, và họ đã biết gì}
- Độ dài: {ví dụ 3 gạch đầu dòng, hoặc dưới 80 từ}
- Định dạng: {ví dụ gạch đầu dòng, một đoạn văn, một email ngắn}
- Trọng tâm: {người đọc này quan tâm điều gì; bỏ phần còn lại}

Chỉ dùng các sự việc được nêu trong tài liệu. Giữ nguyên mọi con số như trong văn bản.
Nếu thiếu điều mà người đọc này cần, hãy nói rõ trong một dòng cuối bắt đầu bằng "Thiếu:".

Điền cho trường hợp CFO (người đọc: "CFO, đọc trên điện thoại"; độ dài: "3 gạch đầu dòng, dưới 70 từ"; định dạng: "gạch đầu dòng, mỗi dòng mở đầu bằng một nhãn ngắn"; trọng tâm: "chi phí so với ngân sách, khoản tiết kiệm, rủi ro tài chính"):

- Vượt ngân sách: chi phí cloud Q3 là $42,800, cao hơn 9% so với ngân sách $39,300, chủ yếu do dung lượng lưu log tăng nhanh hơn kế hoạch.
- Kế hoạch tiết kiệm: chuyển log cũ hơn 30 ngày sang cold storage vào quý tới dự kiến tiết kiệm khoảng $3,000 mỗi tháng.
- Rủi ro: hai sự cố (47 và 22 phút) làm vi phạm SLA uptime 99.9%, và một vị trí hỗ trợ cấp cao đang tuyển.

Thiếu: báo cáo không nói việc vi phạm SLA có kéo theo hoàn tiền cho khách hàng hay không.

Mẹo: câu "Giữ nguyên mọi con số như trong văn bản" rất quan trọng. Thiếu câu này, mô hình thường làm tròn số ("khoảng 43K USD"), và đó là lỗi khi báo cáo được chuyển tiếp cho người khác.

Biến biên bản họp thành quyết định và action item

Biên bản họp trộn lẫn ba thứ: điều đã quyết định, ai làm gì trước khi nào, và điều còn bỏ ngỏ. Hãy yêu cầu tách thành các phần riêng theo một schema cố định, kèm một quy tắc cho chỗ trống: nếu không nêu người phụ trách hoặc ngày, ghi "chưa phân công" hoặc "chưa có hạn". Nếu không, mô hình sẽ lấp chỗ trống bằng những phỏng đoán nghe có vẻ hợp lý. Cột Nguồn giúp bạn xóa bất kỳ dòng nào mà biên bản không chứng minh được.

Thay {notes} bằng ghi chú thô của bạn hoặc một chuỗi email đã dán vào:

<notes>
{notes}
</notes>

Từ ghi chú trên, tạo ba phần.

## Quyết định
Danh sách gạch đầu dòng những điều đã thống nhất. Mỗi mục một dòng.

## Action item
Một bảng Markdown với các cột: Người phụ trách | Công việc | Hạn | Nguồn
- Người phụ trách và Hạn phải lấy từ ghi chú. Nếu không nêu, ghi "chưa phân công" hoặc "chưa có hạn". Tuyệt đối không đoán.
- Nguồn: một trích dẫn ngắn (tối đa 10 từ) từ ghi chú chứng minh cho dòng đó.

## Câu hỏi còn bỏ ngỏ
Mọi điều đã được nêu nhưng chưa giải quyết.

Ghi chú mẫu để thử:

Ops sync, 7/10. Minh, Sarah, Kenji, Lan
- cold storage cho log: mọi người đều ok, Kenji thiết lập lifecycle rule, mục tiêu trước cuối tháng 10
- ca cuối tuần hiệu quả, giữ đến hết Q4
- tuyển agent cấp cao: Sarah sẽ đăng JD trong tuần này. ngân sách? hỏi finance
- postmortem sự cố DNS vẫn chưa viết
- Lan: có nên đền bù SLA cho 3 khách hàng bị ảnh hưởng không? chưa có câu trả lời

## Quyết định
- Chuyển log cũ sang cold storage.
- Giữ ca hỗ trợ cuối tuần đến hết Q4.

## Action item
| Người phụ trách | Công việc | Hạn | Nguồn |
|---|---|---|---|
| Kenji | Thiết lập lifecycle rule cho log trên cold storage | trước cuối tháng 10 | "Kenji thiết lập lifecycle rule" |
| Sarah | Đăng mô tả công việc cho vị trí agent cấp cao | trong tuần này | "Sarah sẽ đăng JD trong tuần này" |
| chưa phân công | Viết postmortem sự cố DNS | chưa có hạn | "postmortem sự cố DNS vẫn chưa viết" |

## Câu hỏi còn bỏ ngỏ
- Ngân sách cho vị trí agent cấp cao là bao nhiêu? (hỏi finance)
- Có nên đền bù SLA cho 3 khách hàng bị ảnh hưởng không?

Lập dàn ý tài liệu dài mà không bỏ sót phần giữa

Với một bản quy định hay đặc tả 40 trang, tóm tắt sẽ làm mất quá nhiều; dàn ý thì giữ được cấu trúc. Các model hiện nay nhận được hàng trăm nghìn token, nhưng không khai thác mọi phần đều như nhau. Nghiên cứu Lost in the Middle (Liu và cộng sự, 2023) cho thấy hiệu quả thường cao nhất khi thông tin liên quan nằm ở đầu hoặc cuối đầu vào, và giảm ở phần giữa. Vì vậy, hãy bắt model đi qua tài liệu từng phần một và trích câu làm căn cứ cho mỗi ý, điều này cũng giữ cho nó bám sát văn bản.

<document>
{paste the long document here}
</document>

Lập dàn ý cho tài liệu trên.
1. Đi qua theo thứ tự, từng phần một. Không bỏ sót phần nào, kể cả những phần ngắn ở giữa.
2. Với mỗi phần: tiêu đề, rồi 2-4 ý chính.
3. Sau mỗi ý chính, thêm trích dẫn làm căn cứ trong dấu ngoặc vuông, tối đa 15 từ, chép chính xác.
4. Kết thúc bằng "Tham chiếu chéo": những chỗ một phần phụ thuộc vào, hoặc mâu thuẫn với, phần khác.

1. Điều kiện áp dụng
   - Nhân viên đã qua thử việc có thể làm việc từ xa tối đa 3 ngày mỗi tuần. ["after successful completion of probation, up to three days per week"]
2. Thiết bị và bảo mật
   - Chỉ laptop của công ty mới được truy cập dữ liệu khách hàng. ["personal devices must not be used to access customer data"]
... (rút gọn)

Tham chiếu chéo
- Mục 5 (Chi phí) hoàn lại tiền internet tại nhà, nhưng Mục 2 không nói router tại nhà có phải đáp ứng các quy tắc bảo mật hay không.

Tạo bảng: biến văn xuôi thành Markdown, CSV hoặc JSON

Model có thể biến một đoạn văn thành các hàng và cột dán thẳng vào Excel, Google Sheets hoặc slide. Chất lượng phụ thuộc vào điều mà phần lớn prompt bỏ quên: người đọc muốn làm gì với bảng. "Biến đoạn này thành bảng" cho ra một danh sách Chỉ số | Giá trị chung chung (nửa bên trái của sơ đồ dưới đây); người đọc vẫn phải tự so sánh. Hãy nêu mục tiêu và model sẽ chọn các cột trả lời đúng câu hỏi:

<report>
{paste the Q3 report}
</report>

Tôi sẽ trình bày báo cáo này cho ban quản lý trong 5 phút. Họ muốn thấy điều gì đã thay đổi so với quý trước và điều gì cần chú ý.

Tạo một bảng Markdown với các cột: Chỉ số | Q2 | Q3 | Thay đổi | Trạng thái
- Q2: chỉ dùng giá trị khi báo cáo có nêu; nếu không thì ghi "n/a".
- Thay đổi: chỉ tính từ các con số có trong báo cáo.
- Trạng thái: "Đúng tiến độ", "Cần theo dõi" hoặc "Cần hành động", kèm lý do tối đa 8 từ.
Sắp xếp các hàng sao cho "Cần hành động" đứng đầu.

| Chỉ số | Q2 | Q3 | Thay đổi | Trạng thái |
|---|---|---|---|---|
| Chi phí cloud so với ngân sách | n/a | $42,800 (ngân sách $39,300) | vượt ngân sách 9% | Cần hành động: dung lượng log tăng nhanh hơn kế hoạch |
| SLA uptime (99.9%) | n/a | 2 lần vi phạm (47 phút, 22 phút) | n/a | Cần hành động: hai sự cố vi phạm SLA |
| Số ticket | 16,430 | 18,400 | +12% | Cần theo dõi: nhu cầu tăng trong khi nhân sự không đổi |
| Phản hồi đầu tiên trung vị | 3.1 giờ | 2.4 giờ | -0.7 giờ | Đúng tiến độ: đã thêm ca cuối tuần từ tháng 7 |
... (rút gọn)

Với công cụ khác, chỉ cần đổi hướng dẫn về đầu ra:

Mẹo: khi code xử lý JSON này, hãy dùng chế độ JSON hoặc structured output của API. Để cố định định dạng bằng ví dụ, xem zero-shot, one-shot và few-shot prompting.

Kiểm tra mọi con số mà model chép lại

Model chép số đúng trong phần lớn trường hợp, chính vì thế lỗi mới lọt qua: người ta ngừng kiểm tra. Hãy chú ý lỗi chép sai (rơi mất một chữ số, đảo hàng) và lỗi suy ra (tính sai phần trăm hoặc tổng). Như bài LLM hoạt động như thế nào đã giải thích, model dự đoán văn bản; nó không tính toán như bảng tính. Chạy prompt này ngay trong cùng cuộc trò chuyện, sau khi có bảng:

Hãy kiểm tra bảng bạn vừa tạo với báo cáo.

Với mỗi con số trong bảng, xuất một hàng:
Ô | Giá trị trong bảng | Trích dẫn chính xác từ báo cáo | Khớp? (có / không / suy ra)

- "suy ra" = được tính toán, không có trong báo cáo. Hiển thị công thức của nó.
- Nếu chạy được code, hãy tính lại mọi con số suy ra bằng code.
Kết thúc bằng "Điều chỉnh:" cùng các ô phải sửa, hoặc "không có".

| Ô | Giá trị trong bảng | Trích dẫn chính xác từ báo cáo | Khớp? |
|---|---|---|---|
| Số ticket, Q3 | 18,400 | "Ticket volume rose to 18,400" | có |
| Chi phí cloud, Thay đổi | vượt ngân sách 9% | "9% over the $39,300 budget" | có |
| Phản hồi đầu tiên trung vị, Thay đổi | -0.7 giờ | (không có) | suy ra: 2.4 - 3.1 = -0.7 |
... (rút gọn)

Kiểm tra bằng code: (42800 - 39300) / 39300 = 0.0891, tức 8.9%, khớp với "9%".
Điều chỉnh: không có

Cảnh báo: Tự kiểm tra không phải là bằng chứng; chính model đã gây ra lỗi đang tự kiểm tra lỗi đó. Với bản trình bày cho hội đồng quản trị, hóa đơn hay hợp đồng, hãy tự xác minh các con số chính hoặc dùng bảng tính.

Học nhanh hơn: giải thích thuật ngữ theo ngữ cảnh và tự kiểm tra

Hai prompt biến chatbot thành bạn học: một prompt giải thích thuật ngữ ngay trong đoạn văn bạn gặp nó (thuật ngữ đổi nghĩa giữa các lĩnh vực), prompt kia ra câu hỏi kiểm tra dựa trên chính ghi chú của bạn.

Giải thích một thuật ngữ trong ngữ cảnh

Tôi đang đọc đoạn này:
"""
{paste the paragraph that contains the term}
"""

Giải thích "{term}" nghĩa là gì trong đoạn này.
- Một câu giải thích dễ hiểu, một ví dụ cụ thể trong lĩnh vực này, và một điểm hay bị nhầm với thuật ngữ tương tự.
Tôi là {your background, e.g. một kỹ sư hỗ trợ chưa có kinh nghiệm về thanh toán}.

Với một tài liệu API viết "Gửi lại request với cùng header Idempotency-Key; server trả về kết quả đã lưu của request đầu tiên trong 24 giờ, nên một khoản thanh toán không bao giờ bị tính hai lần", và thuật ngữ Idempotency-Key:

Nghĩa dễ hiểu: một ID duy nhất gắn vào request để server nhận ra các lần gửi lặp lại và chỉ xử lý một lần.

Ví dụ: ứng dụng của bạn gửi "charge $50" với key 7f3a..., kết nối bị ngắt, rồi nó gửi lại với cùng key đó. Server không tính tiền lần nữa; nó trả về kết quả đầu tiên.

Điểm hay nhầm: nó không phải khóa xác thực như API key. Nó định danh một thao tác, nên hãy dùng key mới cho mỗi khoản thanh toán mới.

Tự kiểm tra từ ghi chú của bạn

Giấu đáp án cho đến khi bạn đã thử trả lời: hãy yêu cầu từng câu hỏi một. Thay {notes} bằng tài liệu của bạn:

Đây là ghi chú học tập của tôi:
"""
{notes}
"""

Hãy kiểm tra tôi về các ghi chú này, mỗi lần một câu hỏi.
- Đặt câu hỏi trắc nghiệm với các lựa chọn A-D, chỉ dựa trên ghi chú của tôi.
- Làm cho các đáp án sai nghe hợp lý: những sai lầm thường gặp, không phải đùa.
- Chờ câu trả lời của tôi. Sau đó cho biết tôi đúng hay sai, giải thích trong 2 câu, và trích dòng ghi chú của tôi chứa đáp án.
- Sau 5 câu, liệt kê các chủ đề tôi làm sai để tôi ôn lại.
Bắt đầu với câu hỏi 1.

Câu hỏi 1 trên 5
Theo ghi chú của bạn, mục tiêu chính của incident management là gì?

A) Tìm nguyên nhân gốc của mọi sự cố
B) Khôi phục dịch vụ bình thường nhanh nhất có thể
C) Ngăn mọi sự cố trong tương lai
D) Ghi lại mọi yêu cầu của người dùng vào hệ thống ticket

Trả lời bằng A, B, C hoặc D.

Câu hỏi trắc nghiệm: nhận câu trả lời đáng tin

Model kém tin cậy với câu hỏi trắc nghiệm hơn vẻ ngoài của nó. Zheng và cộng sự (2023) thử nghiệm 20 LLM và phát hiện "selection bias" (thiên lệch lựa chọn): model ưu tiên một số chữ cái đáp án, chẳng hạn A, bất kể nội dung. Pezeshkpour và Hruschka (2023) đo được chênh lệch độ chính xác khoảng 13% đến 75% chỉ do đảo thứ tự các lựa chọn. Bốn thói quen giúp ích:

1. Suy luận trước khi trả lời. Các reasoning model tự làm việc này bên trong; với model chat thông thường, yêu cầu làm từng bước vẫn có lợi (Kojima và cộng sự, 2022).
2. Đánh giá mọi lựa chọn. Một nhận định cho từng lựa chọn sẽ làm lộ lỗi suy luận.
3. Xáo trộn và hỏi lại. Nếu nội dung được chọn thay đổi theo thứ tự, model đang đoán.
4. Cung cấp công thức và đưa phép tính ra khỏi "đầu" model. Đưa quy tắc, yêu cầu viết biểu thức trước, hoặc để model chạy code; bài báo PAL (Gao và cộng sự, 2022) cho thấy để trình thông dịch tính toán cho kết quả tốt hơn tính bằng văn bản thuần.

Trả lời câu hỏi trắc nghiệm này.

Câu hỏi: Một dịch vụ có SLA uptime hằng tháng là 99.9%. Trong tháng 30 ngày, thời gian ngừng hoạt động tối đa cho phép là bao nhiêu?
A) 4.32 phút
B) 43.2 phút
C) 1.44 phút
D) 7.2 giờ

Quy tắc hữu ích: thời gian ngừng hoạt động cho phép = tổng số phút trong kỳ x (1 - SLA).

1. Tính ra đáp án từng bước. Viết biểu thức trước khi tính.
2. Sau đó đánh giá từng lựa chọn trên một dòng riêng: đúng hay sai, và vì sao.
3. Dòng cuối: "Đáp án: <chữ cái>"

1. Số phút trong 30 ngày: 30 x 24 x 60 = 43,200.
   Thời gian ngừng hoạt động cho phép: 43,200 x (1 - 0.999) = 43,200 x 0.001 = 43.2 phút.

2. A) 4.32 phút: sai (mức cho phép của 99.99%).
   B) 43.2 phút: đúng.
   C) 1.44 phút: sai (là một ngày, không phải 30 ngày).
   D) 7.2 giờ: sai (mức cho phép của 99%).

Đáp án: B

Sau đó dán câu hỏi vào một cuộc trò chuyện mới với thứ tự lựa chọn đã đảo. Câu trả lời phải theo nội dung, không theo chữ cái.

Phân tích tài liệu cho hợp đồng và quy định

Cảnh báo: Đây không phải tư vấn pháp lý. Model có thể đọc sai điều khoản hoặc bịa ra luật. Trong vụ Mata v. Avianca (S.D.N.Y., tháng 6/2023), các luật sư bị phạt 5.000 USD vì đưa vào bản tranh tụng những phán quyết tòa án do ChatGPT bịa ra. Hãy dùng AI để chuẩn bị câu hỏi; để luật sư trả lời chúng.

Ba việc, theo thứ tự rủi ro tăng dần: hiểu một điều khoản, đánh dấu các điều khoản rủi ro, soạn bản nháp để luật sư xem lại.

Giải thích một điều khoản bằng ngôn ngữ dễ hiểu

Giải thích điều khoản hợp đồng này bằng ngôn ngữ dễ hiểu cho {your role, e.g. một IT manager ký hợp đồng với nhà cung cấp}.

Điều khoản:
"""
{paste the clause}
"""

Trả lời theo ba phần:
1. Điều khoản nói gì, trong 2 câu không dùng thuật ngữ pháp lý.
2. Ai phải làm gì, và trước khi nào.
3. Một tình huống thực tế cho thấy điều khoản có thể ảnh hưởng đến chúng tôi ra sao.
Không đưa ý kiến về việc điều khoản có hiệu lực thi hành hay không.

Với một điều khoản gia hạn SaaS điển hình (tự động gia hạn 12 tháng trừ khi có thông báo bằng văn bản ít nhất 90 ngày trước khi kỳ hạn kết thúc):

1. Hợp đồng tự gia hạn thêm 12 tháng vào cuối mỗi kỳ hạn, trừ khi một trong hai bên gửi thông báo bằng văn bản ít nhất 90 ngày trước ngày kết thúc.

2. Mỗi bên phải gửi thông báo không gia hạn bằng văn bản trước ngày kết thúc từ 90 ngày trở lên; nếu không, một kỳ hạn 12 tháng mới sẽ bắt đầu.

3. Tình huống: kỳ hạn của bạn kết thúc vào 31/12 và giữa tháng 10 bạn quyết định đổi nhà cung cấp. Hạn chót đã là 2/10, nên bạn phải trả thêm một năm đầy đủ.

Đánh dấu các điều khoản đáng xem lại

Bạn đang giúp tôi chuẩn bị câu hỏi cho luật sư của chúng tôi. Bạn không đưa ra tư vấn pháp lý.

<contract>
{paste the contract}
</contract>

Chúng tôi là {customer / vendor / employee}. Lập một bảng từ phía chúng tôi:
Điều khoản | Trích dẫn chính xác (tối đa 25 từ) | Vì sao có thể rủi ro với chúng tôi | Mức độ (Cao / Trung bình / Thấp) | Câu hỏi cần hỏi
- Chỉ lấy các điều khoản có trong văn bản, trích dẫn chính xác.
- Cao = có thể gây thiệt hại đáng kể về tiền, dữ liệu, hoặc khả năng chấm dứt hợp đồng của chúng tôi.
Sau đó liệt kê các biện pháp bảo vệ tiêu chuẩn có vẻ còn thiếu.

| Điều khoản | Trích dẫn chính xác | Vì sao có thể rủi ro với chúng tôi | Mức độ | Câu hỏi cần hỏi |
|---|---|---|---|---|
| 3.2 Thay đổi | "Vendor may modify these terms at any time by posting the updated terms on its website" | Điều khoản có thể thay đổi mà không cần chúng tôi đồng ý hay được thông báo | Cao | Có thể yêu cầu thông báo bằng văn bản và cho chúng tôi quyền chấm dứt hợp đồng không? |
| 9.1 Trách nhiệm | "liability shall not exceed the fees paid in the three (3) months preceding the claim" | Một vụ rò rỉ dữ liệu có thể gây thiệt hại lớn hơn nhiều so với phí 3 tháng | Cao | Mức trần có thể là phí 12 tháng, với vụ rò rỉ dữ liệu nằm ngoài mức trần không? |
| 12.1 Gia hạn | "automatically renew for successive twelve (12) month periods" | Thời hạn thông báo 90 ngày rất dễ bỏ lỡ | Trung bình | Có thể rút xuống thông báo trước 30 ngày, hoặc nhà cung cấp gửi nhắc nhở không? |

Có thể còn thiếu: trả lại hoặc xóa dữ liệu sau khi chấm dứt hợp đồng; cam kết về uptime.

Soạn bản nháp từ term sheet, rồi chuyển cho luật sư

Với các văn bản phổ biến như NDA, model soạn khá tốt từ các điều khoản đã thỏa thuận. Hãy bắt nó đánh dấu mọi giả định để luật sư đi thẳng vào điều quan trọng:

Soạn thảo thỏa thuận bảo mật thông tin (NDA) hai chiều từ các điều khoản đã thống nhất sau:
- Các bên: {company A} và {company B}
- Mục đích: {ví dụ đánh giá hợp tác phát triển phần mềm}
- Thời hạn: {ví dụ 2 năm}; nghĩa vụ bảo mật vẫn còn hiệu lực {ví dụ 3 năm} sau khi kết thúc
- Luật điều chỉnh: {jurisdiction}
- {các điểm đã thống nhất khác}

Dùng ngôn ngữ đơn giản và đánh số các điều khoản. Đánh dấu mọi giả định không có trong danh sách của tôi bằng [TO CONFIRM: lý do] và liệt kê tất cả ở cuối.
Một luật sư có chuyên môn sẽ xem lại bản nháp này trước khi sử dụng.

THỎA THUẬN BẢO MẬT THÔNG TIN HAI CHIỀU
1. Mục đích. ... (rút gọn)

Các mục cần xác nhận:
1. Việc tiết lộ bằng lời có phải được xác nhận bằng văn bản hay không.
2. Nhà thầu, không chỉ nhân viên, có được nhận thông tin hay không.
3. Tòa án hoặc địa điểm trọng tài giải quyết tranh chấp.

Lỗi thường gặp và danh sách kiểm tra an toàn

Phần lớn thất bại đến từ vài thói quen, mỗi thói quen có một cách sửa đơn giản:

Về quyền riêng tư, hãy kiểm tra văn bản của bạn đi đâu. Chẳng hạn, OpenAI tuyên bố mặc định không dùng dữ liệu của ChatGPT Business, Enterprise hay API để huấn luyện; tài khoản cá nhân phải tự tắt trong Data controls. Khi còn nghi ngờ, hãy dùng chỗ giữ chỗ như [CLIENT_A]. Trước khi chuyển tiếp bất kỳ bản tóm tắt AI nào, hãy chạy một lượt kiểm tra cuối:

Trước khi tôi chia sẻ bản tóm tắt của bạn, hãy đối chiếu nó với tài liệu:
1. Liệt kê mọi nhận định trong bản tóm tắt mà tài liệu không trực tiếp chứng minh, và giải thích vì sao.
2. Liệt kê mọi điểm quan trọng trong tài liệu mà bản tóm tắt bỏ sót.
3. Nếu có gì phải sửa, đưa cho tôi bản tóm tắt đã chỉnh. Nếu không, trả lời "Không cần thay đổi".

1. Nhận định không được chứng minh: không có.
2. Điểm bị bỏ sót: phản hồi đầu tiên cải thiện từ 3.1 xuống 2.4 giờ; CSAT giữ ở 91% (nằm ngoài trọng tâm đã yêu cầu).
3. Không cần thay đổi

FAQ

Tôi có thể dán tài liệu dài bao nhiêu vào ChatGPT hoặc Claude?

Các model hiện nay nhận được hàng trăm nghìn token, đủ cho một báo cáo hay hợp đồng dài; giới hạn khác nhau tùy model và gói dịch vụ. Hãy đặt tài liệu lên trước và yêu cầu đi qua từng phần kèm trích dẫn. Với cả một thư viện tài liệu, hãy dùng retrieval: xem Xây dựng chatbot cơ sở tri thức (RAG).

Tải hợp đồng lên chatbot AI có an toàn không?

Tùy tài khoản và quy định của công ty bạn. Các gói business và API của những nhà cung cấp lớn thường mặc định loại dữ liệu của bạn khỏi việc huấn luyện; tài khoản cá nhân có thể không. Hãy dùng công cụ đã được duyệt và xóa các chi tiết mà công việc không cần.

Vì sao AI tính sai số trong bảng?

Model sinh văn bản từng token một; nó không tính toán. Giá trị chép lại thường đúng; lỗi xuất hiện ở phần trăm, tổng và chênh lệch. Hãy yêu cầu công thức và tính lại bằng code hoặc bảng tính.

Nguồn và tài liệu đọc thêm

• Learn Prompting: Text Summarization
• Learn Prompting: Table Generation
• Learn Prompting: Multiple Choice Questions
• Learn Prompting: Study Buddy
• Learn Prompting: Legal Documents
• Anthropic: Prompting best practices (long context prompting)
• Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts
• Zheng et al. (2023), Large Language Models Are Not Robust Multiple Choice Selectors
• Pezeshkpour & Hruschka (2023), LLMs Sensitivity to the Order of Options in Multiple-Choice Questions
• Kojima et al. (2022), Large Language Models are Zero-Shot Reasoners
• Gao et al. (2022), PAL: Program-aided Language Models
• Mata v. Avianca, Inc., Opinion and Order on Sanctions (S.D.N.Y. 2023)
• OpenAI: How your data is used to improve model performance

Hướng dẫn Prompt Engineering: tất cả các phần

← Trước: Phần 6: Kết hợp kỹ thuật, priming và vòng lặp cải tiến · Tiếp: Phần 8: Prompt cho email, bài blog và marketing →

Hãy đọc Phần 1–6 theo thứ tự: mỗi phần xây trên phần trước. Phần 7–10 là phần ứng dụng và có thể đọc theo thứ tự bất kỳ khi bạn đã nắm kiến thức nền.

• Phần 1: Prompt engineering là gì và vì sao quan trọng
• Phần 2: LLM hoạt động thế nào: kiến thức nền về generative AI
• Phần 3: Cấu trúc prompt: năm thành phần của một prompt
• Phần 4: Instruction prompting và role prompting
• Phần 5: Zero-shot, one-shot và few-shot prompting
• Phần 6: Kết hợp kỹ thuật, priming và vòng lặp cải tiến
• Phần 7: Prompt cho tóm tắt, bảng biểu và phân tích tài liệu (bạn đang ở đây)
• Phần 8: Prompt cho email, bài blog và marketing
• Phần 9: Prompt cho trợ lý lập trình
• Phần 10: Xây dựng chatbot cơ sở tri thức (RAG)