6 chiến lược để prompt hiệu quả mà OpenAI đưa ra có gì hot? (Phần 2)

Cho model thêm thời gian để "nghĩ"

Hướng dẫn model tự tìm ra giải pháp trước khi vội vàng đưa ra kết luận

• Ý tưởng cốt lõi: Buộc mô hình phải thực hiện một quy trình suy luận từng bước một cách nội bộ trước khi đưa ra câu trả lời hoặc kết luận cuối cùng. Tránh việc mô hình "nhảy bổ" vào kết luận mà không cân nhắc kỹ lưỡng.
• Vấn đề giải quyết:
  • Lỗi suy luận vội vàng: LLMs thường mắc lỗi khi cố gắng trả lời ngay lập tức các câu hỏi phức tạp hoặc các bài toán đòi hỏi nhiều bước suy luận. Giống như con người, chúng cần "thời gian" để tính toán.
  • Ảnh hưởng bởi thông tin sai lệch: Nếu prompt chứa thông tin gợi ý sai (như lời giải sai của học sinh trong ví dụ), việc yêu cầu LLM giải quyết vấn đề một cách độc lập trước giúp nó không bị "lệch hướng" bởi thông tin sai đó.
• Cách thức hoạt động:
  • Thay đổi chỉ dẫn trong SYSTEM prompt. Thay vì hỏi trực tiếp (ví dụ: "Lời giải này đúng hay sai?"), hãy yêu cầu mô hình thực hiện các bước cụ thể:
    1. "Đầu tiên, hãy tự giải bài toán này." (First work out your own solution to the problem.)
    2. "Sau đó, so sánh lời giải của bạn với lời giải của học sinh." (Then compare your solution to the student's solution...)
    3. "Cuối cùng, đánh giá xem lời giải của học sinh có đúng không." (...and evaluate if the student's solution is correct or not.)
  • Nhấn mạnh việc không đưa ra kết luận cuối cùng cho đến khi đã tự hoàn thành các bước suy luận.
• Lợi ích:
  • Tăng độ chính xác: Giảm thiểu lỗi suy luận, đặc biệt với các tác vụ tính toán, logic, hoặc đánh giá phức tạp.
  • Giảm thiên vị (Bias): Tránh việc mô hình bị ảnh hưởng tiêu cực bởi các thông tin không chính xác có trong ngữ cảnh prompt.
  • Minh bạch hơn (nội bộ): Quá trình suy luận rõ ràng hơn (dù có thể không hiển thị cho người dùng cuối), giúp dễ hiểu tại sao mô hình đưa ra kết luận đó.
• Trường hợp sử dụng:
  • Đánh giá bài làm (toán, lập trình, viết luận...).
  • Kiểm tra tính đúng đắn của thông tin, quy trình.
  • Giải quyết vấn đề phức tạp cần các bước trung gian.
  • Bất kỳ tình huống nào mà câu trả lời "trực giác" hoặc nhanh chóng có thể không đáng tin cậy.
• Đây là một cách áp dụng hoặc "ép buộc" mô hình thực hiện Chain-of-Thought một cách có cấu trúc, thay vì chỉ hy vọng nó tự làm điều đó.

Sử dụng "Độc thoại Nội tâm" hoặc Chuỗi Truy vấn để Ẩn Quá trình Suy luận

• Ý tưởng cốt lõi: Tách biệt phần suy luận chi tiết, các bước tính toán nội bộ của mô hình khỏi phần kết quả cuối cùng hiển thị cho người dùng. Cho phép mô hình "suy nghĩ" kỹ lưỡng nhưng chỉ trình bày phần thông tin cần thiết và phù hợp.
• Vấn đề giải quyết:
  • Trong nhiều ứng dụng, việc hiển thị toàn bộ quá trình suy luận của LLM là không phù hợp hoặc phản tác dụng (ví dụ: lộ đáp án trong ứng dụng dạy học, làm người dùng bối rối với các bước trung gian phức tạp, tiết lộ logic nghiệp vụ).
• Cách thức hoạt động: Có hai cách tiếp cận chính:
  • Độc thoại Nội tâm (Inner Monologue):
    • Hướng dẫn mô hình đặt toàn bộ phần suy luận, tính toán, phân tích chi tiết vào bên trong một cấu trúc định dạng cụ thể (ví dụ: đặt trong cặp dấu """ """, thẻ <thinking>, <internal_steps>).
    • Phần câu trả lời cuối cùng dành cho người dùng sẽ được đặt bên ngoài cấu trúc đó.
    • Ứng dụng (backend) sẽ phân tích cú pháp (parse) phản hồi có cấu trúc này và chỉ hiển thị phần dành cho người dùng.
    • Ví dụ: Yêu cầu mô hình thực hiện Bước 1, 2, 3 (tự giải, so sánh, xác định gợi ý) bên trong """ """, và Bước 4 (cung cấp gợi ý) bên ngoài.
  • Chuỗi Truy vấn (Sequence of Queries):
    • Chia nhiệm vụ thành nhiều lệnh gọi LLM riêng biệt.
    • Lệnh gọi 1: Yêu cầu mô hình tự giải bài toán (Output này ẩn với người dùng).
    • Lệnh gọi 2: Yêu cầu mô hình so sánh lời giải của nó (từ lệnh gọi 1) với lời giải của học sinh và phân tích lỗi (Output này ẩn với người dùng).
    • Lệnh gọi 3: Yêu cầu mô hình đóng vai trò gia sư, dựa trên phân tích lỗi (từ lệnh gọi 2), đưa ra một gợi ý phù hợp mà không lộ đáp án (Output này hiển thị cho người dùng).
• Lợi ích:
  • Kiểm soát đầu ra: Cho phép suy luận chi tiết mà không làm lộ thông tin không cần thiết hoặc không phù hợp.
  • Trải nghiệm người dùng tốt hơn: Cung cấp phản hồi ngắn gọn, đúng trọng tâm.
  • Hỗ trợ các vai trò/tương tác cụ thể: Ví dụ điển hình là vai trò gia sư chỉ đưa gợi ý.
  • Giảm thiên vị (với chuỗi truy vấn): Cách ly hoàn toàn bước mô hình tự giải quyết vấn đề khỏi lời giải (có thể sai) của học sinh.
• Trường hợp sử dụng:
  • Ứng dụng dạy học, trợ giúp làm bài tập.
  • Các hệ thống cần che giấu sự phức tạp của quá trình xử lý nội bộ.
  • Khi cần định dạng đầu ra theo một vai trò (persona) hoặc phong cách cụ thể.
  • Các quy trình cần tạo ra cả phân tích nội bộ và phản hồi cho khách hàng.
• Xây dựng dựa trên Chiến thuật 1. Nó sử dụng quá trình suy luận chi tiết nhưng thêm một lớp kiểm soát hiển thị đầu ra. Cách tiếp cận Chuỗi Truy vấn liên quan chặt chẽ đến Prompt Chaining.

Hỏi Mô hình xem nó có Bỏ lỡ Gì không

• Ý tưởng cốt lõi: Thực hiện các truy vấn lặp đi lặp lại để yêu cầu mô hình xem xét lại kết quả trước đó và kiểm tra xem có thiếu sót hoặc bỏ lỡ thông tin liên quan nào không, đặc biệt khi xử lý lượng lớn dữ liệu đầu vào.
• Vấn đề giải quyết:
  • LLMs có xu hướng "dừng lại quá sớm" hoặc không bao quát hết tất cả các điểm liên quan khi xử lý các tài liệu dài hoặc thực hiện các tác vụ yêu cầu tìm kiếm/trích xuất toàn diện. Giống như "sự chú ý" của chúng bị giới hạn hoặc giảm dần.
• Cách thức hoạt động:
  • Sau khi mô hình đưa ra phản hồi ban đầu (ví dụ: danh sách các trích đoạn), hãy gửi một prompt tiếp theo.
  • Prompt này yêu cầu mô hình tìm kiếm thêm các mục liên quan, đồng thời nhấn mạnh việc không lặp lại các mục đã có và có thể nhắc lại các tiêu chí về mức độ liên quan hoặc định dạng.
  • Ví dụ: Sau khi LLM trả về một danh sách JSON các trích đoạn, hỏi tiếp: "Còn trích đoạn nào liên quan nữa không? Lưu ý không lặp lại các trích đoạn đã có..." (Are there more relevant excerpts? Take care not to repeat excerpts...).
• Lợi ích:
  • Cải thiện độ đầy đủ (Recall): Đảm bảo thu thập được nhiều thông tin liên quan hơn.
  • Khắc phục giới hạn: Giúp vượt qua giới hạn về khả năng xử lý hoặc sự chú ý của mô hình đối với các đầu vào dài.
  • Đơn giản: Dễ thực hiện bằng một hoặc nhiều lệnh gọi tiếp theo.
• Trường hợp sử dụng:
  • Một trường hợp mà mình đã sử dụng là trích xuất Entity và Relationship trong GraphRAG system
  • Trích xuất toàn bộ thông tin/dữ liệu liên quan từ tài liệu dài.
  • Lên ý tưởng (brainstorming) hoặc tạo danh sách yêu cầu tính toàn diện.
  • Tổng quan tài liệu (literature review) cần bao quát rộng.
  • Bất kỳ tác vụ nào mà việc bỏ sót thông tin quan trọng là một thất bại đáng kể.
• Đây là một dạng tinh chỉnh lặp đi lặp lại (iterative refinement) hoặc prompting tự sửa lỗi (self-correction prompting). Nó thừa nhận sự không hoàn hảo của một lượt xử lý duy nhất và sử dụng tương tác để cải thiện kết quả.

Sử dụng thêm các external tools

• Ý tưởng cốt lõi: Nhận thức rằng LLM có những hạn chế cố hữu. Thay vì cố gắng ép LLM làm những việc nó không giỏi, hãy tận dụng các công cụ bên ngoài chuyên biệt cho các tác vụ đó (như truy xuất thông tin, tính toán, chạy mã, gọi API) và tích hợp kết quả từ các công cụ này vào quy trình làm việc của LLM. Mục tiêu là kết hợp điểm mạnh của cả LLM và các công cụ chuyên dụng. "Giao đúng việc cho đúng công cụ."

• Lợi ích:

  • Mở rộng đáng kể phạm vi khả năng của ứng dụng dựa trên LLM.
  • Cải thiện độ chính xác và độ tin cậy cho các tác vụ cụ thể (ví dụ: tính toán, lấy dữ liệu thực tế).
  • Cho phép LLM tương tác với dữ liệu thời gian thực hoặc thực hiện hành động trên các hệ thống khác.

Sử dụng tìm kiếm dựa trên Embeddings để truy xuất kiến thức hiệu quả

• Cơ chế hoạt động: Đây chính là nền tảng kỹ thuật của Retrieval Augmented Generation (RAG).
  1. Chuẩn bị dữ liệu (Offline): Một kho kiến thức (text corpus) được chia thành các đoạn nhỏ (chunks).
  2. Tạo Embedding: Mỗi chunk được chuyển đổi thành một vector số học (embedding) bằng một mô hình embedding. Vector này biểu diễn ngữ nghĩa của chunk đó. Các vector gần nhau trong không gian biểu diễn các chunk có nội dung liên quan.
  3. Lưu trữ: Các cặp (vector, nội dung chunk) được lưu trữ trong một cơ sở dữ liệu có khả năng tìm kiếm vector hiệu quả (Vector Database).
  4. Truy xuất (Online): Khi có truy vấn từ người dùng, truy vấn đó cũng được chuyển thành vector embedding (bằng cùng mô hình embedding).
  5. Tìm kiếm Vector: Sử dụng thuật toán tìm kiếm vector nhanh để tìm các vector chunk trong cơ sở dữ liệu gần nhất (liên quan nhất về ngữ nghĩa) với vector truy vấn.
  6. Tăng cường Prompt: Lấy nội dung của các chunk tương ứng và đưa vào prompt cùng với câu hỏi gốc của người dùng làm ngữ cảnh bổ sung cho LLM.
• Lợi ích: Cho phép LLM truy cập và sử dụng thông tin từ các nguồn bên ngoài một cách động (dynamic) tại thời điểm chạy, giúp tạo ra các phản hồi cập nhật, đầy đủ thông tin và giảm thiểu việc bịa đặt thông tin sai lệch (hallucination).
• Ví dụ: Trả lời câu hỏi về một bộ phim cụ thể bằng cách truy xuất thông tin về diễn viên, đạo diễn từ cơ sở dữ liệu phim ảnh.

Sử dụng mã thực thi để tính toán chính xác hơn hoặc gọi API ngoài

• Cơ chế hoạt động:
  1. Hướng dẫn LLM rằng nó có thể viết và yêu cầu thực thi mã (ví dụ: Python) bằng cách đặt mã vào trong một định dạng đánh dấu cụ thể (ví dụ: cặp ba dấu backtick ).
  2. Khi LLM cần thực hiện tính toán hoặc gọi một API mà nó biết cách sử dụng (thông qua tài liệu hoặc ví dụ được cung cấp), nó sẽ tạo ra đoạn mã tương ứng trong đầu ra của nó.
  3. Ứng dụng nền (backend) sẽ nhận diện, trích xuất đoạn mã này.
  4. Quan trọng: Thực thi đoạn mã trong một môi trường an toàn, được kiểm soát chặt chẽ (sandboxed environment) để ngăn chặn các hành vi nguy hiểm tiềm ẩn.
  5. Kết quả trả về từ môi trường thực thi mã (ví dụ: kết quả phép tính, dữ liệu từ API) có thể được đưa lại làm đầu vào cho LLM trong lượt tương tác tiếp theo nếu cần thiết.
• Lợi ích: Cung cấp khả năng tính toán chính xác mà LLM thường thiếu; Mở ra khả năng tương tác với bất kỳ API nào thông qua các thư viện mã nguồn (ví dụ: gọi API web bằng thư viện requests trong Python).
• Ví dụ: Tìm nghiệm của đa thức phức tạp, gọi một hàm message.write tùy chỉnh như trong ví dụ.
• Cảnh báo: Bảo mật là rất quan trọng. Việc thực thi mã do LLM tạo ra có rủi ro. Luôn cần một môi trường sandbox đáng tin cậy.

Cung cấp cho mô hình quyền truy cập vào các hàm cụ thể (Function Calling)

• Cơ chế hoạt động (Cụ thể cho OpenAI Chat Completions API):
  1. Khi gửi yêu cầu đến API, ứng dụng cung cấp một danh sách các "hàm" (functions) mà LLM được phép yêu cầu thực thi. Mỗi hàm được mô tả rõ ràng về tên, chức năng, và cấu trúc (schema) của các tham số đầu vào cần thiết.
  2. Dựa trên truy vấn của người dùng và mô tả các hàm có sẵn, LLM sẽ quyết định xem có cần gọi một hàm nào không. Nếu có, nó sẽ tạo ra một đối tượng JSON chứa tên hàm cần gọi và các đối số (arguments) tương ứng với schema đã định nghĩa.
  3. API sẽ trả về đối tượng JSON này cho ứng dụng của bạn (thay vì trả lời trực tiếp bằng văn bản).
  4. Ứng dụng của bạn nhận JSON, phân tích cú pháp, và thực thi lời gọi hàm/API thực tế với các đối số được cung cấp.
  5. Sau khi hàm thực thi xong và trả về kết quả, ứng dụng của bạn sẽ gửi một yêu cầu mới đến LLM, bao gồm cả kết quả trả về từ hàm đó.
  6. LLM nhận kết quả hàm, tổng hợp thông tin và tạo ra phản hồi cuối cùng bằng ngôn ngữ tự nhiên cho người dùng.
• Lợi ích: Là cách thức được OpenAI khuyến nghị để LLM tương tác với các hàm/API bên ngoài. Nó có cấu trúc rõ ràng, đáng tin cậy hơn và thường an toàn hơn so với việc cho phép LLM tạo và yêu cầu thực thi mã tùy ý.
• Ví dụ: Lấy thông tin thời tiết, tra cứu thông tin sản phẩm, đặt lịch hẹn qua API.
• Đây cũng là một cơ chế mà mình nghĩ các bạn nên thử để biết thêm về Function Calling.

Kiểm tra các thay đổi một cách hệ thống

• Ý tưởng cốt lõi: Để cải thiện hiệu suất của hệ thống LLM một cách đáng tin cậy, cần phải đo lường được hiệu quả của các thay đổi. Thay vì chỉ dựa vào việc xem xét vài ví dụ đơn lẻ (có thể mang tính may rủi), hãy định nghĩa và sử dụng các bộ kiểm thử (test suites) toàn diện, còn gọi là "evals" (evaluations), để đánh giá tác động thực sự của một thay đổi (ví dụ: sửa đổi prompt, dùng model mới).
• Vấn đề giải quyết:
  • Đánh giá chủ quan/không đáng tin cậy: Một thay đổi có thể tỏ ra tốt hơn trên vài ví dụ nhưng lại làm giảm hiệu suất tổng thể trên một tập dữ liệu đại diện hơn.
  • Khó xác định cải tiến thực sự: Không có cơ sở dữ liệu khách quan để khẳng định một thay đổi là tích cực hay tiêu cực đối với hiệu suất chung.
• Cách thức hoạt động:
  • Xây dựng một bộ kiểm thử ("eval") đáp ứng các tiêu chí:
    • Đại diện (Representative): Phản ánh cách sử dụng thực tế hoặc ít nhất là đủ đa dạng.
    • Đủ lớn (Statistical Power): Có đủ số lượng ca thử nghiệm để kết quả mang ý nghĩa thống kê, giúp phân biệt cải tiến thực sự với sự may mắn ngẫu nhiên.
    • Dễ tự động hóa/lặp lại (Easy to automate/repeat): Để có thể thực hiện đánh giá thường xuyên và nhất quán.
  • Thực hiện đánh giá trên bộ kiểm thử này trước và sau khi áp dụng thay đổi để so sánh hiệu suất một cách khách quan.
• Lợi ích:
  • Cho phép tối ưu hóa dựa trên dữ liệu.
  • Cung cấp bằng chứng khách quan về hiệu quả của các thay đổi.
  • Giúp phát hiện các vấn đề hồi quy (regressions) khi thay đổi làm giảm hiệu suất.
  • Tăng sự tự tin khi triển khai các cải tiến.
• Trường hợp sử dụng: Là một phần thiết yếu của quy trình phát triển và cải tiến bất kỳ ứng dụng LLM nào, đặc biệt là khi đưa vào vận hành thực tế; dùng để so sánh hiệu quả giữa các prompt khác nhau, các mô hình khác nhau, hoặc các cấu hình hệ thống khác nhau (ví dụ: RAG).

Chiến thuật: Đánh giá đầu ra của mô hình dựa trên câu trả lời chuẩn (Evaluate model outputs with reference to gold-standard answers)

• Ý tưởng cốt lõi: Sử dụng chính một mô hình LLM (đóng vai trò là "người đánh giá") để so sánh câu trả lời do hệ thống tạo ra (candidate answer) với một câu trả lời được biết là đúng hoặc chuẩn mực (gold-standard answer). Việc đánh giá này tập trung vào các khía cạnh cụ thể như mức độ bao phủ thông tin hoặc tính nhất quán.

• Vấn đề giải quyết: Tự động hóa việc đánh giá các khía cạnh chất lượng của đầu ra LLM mà việc so sánh chuỗi ký tự đơn giản không thể thực hiện được, đặc biệt khi có nhiều cách diễn đạt đúng cho cùng một câu trả lời.

• Cách thức hoạt động: Kỹ thuật này đòi hỏi việc thiết kế các prompt rất cụ thể cho mô hình LLM đánh giá. Hai biến thể được mô tả:

  • Biến thể 1: Kiểm tra Sự thật (Fact Checking)

    • Đầu vào cho LLM đánh giá: Câu trả lời ứng viên + Danh sách các sự thật cụ thể (known facts) mà câu trả lời nên chứa.
    • Prompt cho LLM đánh giá: Hướng dẫn chi tiết các bước:
      1. Nêu lại từng sự thật cần kiểm tra.
      2. Tìm và trích dẫn phần trong câu trả lời ứng viên gần nhất với sự thật đó.
      3. Phân tích xem người đọc không biết về chủ đề có thể suy ra trực tiếp sự thật từ phần trích dẫn đó không (giải thích lý do).
      4. Ghi "yes" hoặc "no" dựa trên kết quả phân tích ở bước 3.
      5. Cuối cùng, đếm tổng số "yes" và trả về dưới dạng JSON {"count": <số lượng>}.
    • Mục đích: Đo lường một cách định lượng xem câu trả lời ứng viên đã bao phủ được bao nhiêu phần trăm các thông tin thực tế quan trọng cần có.

  • Biến thể 2: Phân tích Mức độ Trùng lặp / Mâu thuẫn

    • Đầu vào cho LLM đánh giá: Câu hỏi + Câu trả lời ứng viên + Câu trả lời chuẩn/chuyên gia.
    • Prompt cho LLM đánh giá: Hướng dẫn chi tiết các bước suy luận:
      1. Phân tích từng bước mối quan hệ về mặt thông tin giữa câu trả lời ứng viên và câu trả lời chuẩn (là hoàn toàn khác biệt - disjoint, giống hệt - equal, là tập con - subset, là tập cha - superset, hay chỉ giao nhau một phần - overlapping).
      2. Phân tích từng bước xem câu trả lời ứng viên có mâu thuẫn với bất kỳ khía cạnh nào của câu trả lời chuẩn không.
      3. Trả về kết quả dưới dạng đối tượng JSON có cấu trúc: {"type_of_overlap": "...", "contradiction": true/false}.
    • Mục đích: Cung cấp một đánh giá sâu sắc hơn về mối quan hệ ngữ nghĩa và tính nhất quán giữa câu trả lời được tạo ra và câu trả lời chuẩn, không chỉ dừng lại ở việc kiểm tra sự thật đơn lẻ mà còn phát hiện mâu thuẫn.

• Lợi ích:

  • Tự động hóa các khía cạnh đánh giá mà thông thường đòi hỏi sự xem xét của con người.
  • Cung cấp các phép đo có cấu trúc, nhất quán và khách quan hơn.
  • Có thể đánh giá các sắc thái tinh tế như mức độ bao phủ thông tin, sự trùng lặp hoặc mâu thuẫn logic.

• Trường hợp sử dụng: Đánh giá hệ thống Hỏi-Đáp, kiểm tra tính chính xác và đầy đủ của các bản tóm tắt do AI tạo ra, so sánh chất lượng đầu ra giữa các phiên bản mô hình/prompt khác nhau dựa trên một bộ dữ liệu tham chiếu chuẩn.

• Cân nhắc quan trọng: Hiệu quả của việc đánh giá dựa trên mô hình phụ thuộc rất nhiều vào năng lực của chính mô hình LLM được dùng làm "người đánh giá" và chất lượng của prompt hướng dẫn đánh giá. Cần thử nghiệm để xem phương pháp này hoạt động tốt đến đâu cho trường hợp sử dụng cụ thể của bạn. Đánh giá bởi con người vẫn rất quan trọng đối với các tác vụ phức tạp hoặc mang tính chủ quan cao.

References

• https://platform.openai.com/docs/guides/prompt-engineering/six-strategies-for-getting-better-results