Tác giả: Samantha Stuart, Ivan Cui, Philippe Duplessis-Guindon, và Rahul Jani
Ngày phát hành: 05 MAR 2025
Chuyên mục: Amazon SageMaker, Best Practices, Expert (400), Generative AI, Learning Levels, Thought Leadership

Các ứng dụng trả lời câu hỏi bằng Generative AI đang thúc đẩy ranh giới năng suất của doanh nghiệp. Các trợ lý này có thể được cung cấp sức mạnh bởi nhiều kiến trúc backend khác nhau, bao gồm Retrieval Augmented Generation (RAG), quy trình làm việc agentic, các large language model (LLM) đã được fine-tune, hoặc sự kết hợp của các kỹ thuật này. Tuy nhiên, việc xây dựng và triển khai các trợ lý AI đáng tin cậy đòi hỏi một khuôn khổ đánh giá và ground truth mạnh mẽ.

Dữ liệu ground truth trong AI đề cập đến dữ liệu được biết là có tính xác thực, đại diện cho kết quả sử dụng mong đợi cho hệ thống đang được mô hình hóa. Bằng cách cung cấp một kết quả mong đợi để đo lường, dữ liệu ground truth mở khóa khả năng đánh giá chất lượng hệ thống một cách xác định (deterministically). Việc chạy đánh giá xác định các trợ lý generative AI dựa trên dữ liệu ground truth của trường hợp sử dụng cho phép tạo ra các benchmark tùy chỉnh. Các benchmark này rất cần thiết để theo dõi sự trôi dạt hiệu suất theo thời gian và để so sánh thống kê nhiều trợ lý trong việc hoàn thành cùng một tác vụ. Ngoài ra, chúng cho phép định lượng những thay đổi về hiệu suất như một hàm của các cải tiến đối với trợ lý cơ bản, tất cả đều trong một thiết lập được kiểm soát. Với các quy trình đánh giá xác định như các metric Factual Knowledge và QA Accuracy của FMEval, việc tạo ground truth và triển khai metric đánh giá được kết hợp chặt chẽ. Để đảm bảo chất lượng đo lường cao nhất cho ứng dụng trả lời câu hỏi của bạn dựa trên ground truth, việc triển khai metric đánh giá phải cung cấp thông tin cho việc quản lý ground truth.

Trong bài viết này, chúng tôi thảo luận về các best practice để áp dụng LLM nhằm tạo ground truth cho việc đánh giá các trợ lý trả lời câu hỏi bằng FMEval ở quy mô doanh nghiệp. FMEval là một bộ công cụ đánh giá toàn diện từ Amazon SageMaker Clarify, và cung cấp các triển khai tiêu chuẩn hóa của các metric để đánh giá chất lượng và trách nhiệm. Để tìm hiểu thêm về FMEval, hãy xem bài viết Đánh giá large language model về chất lượng và trách nhiệm của LLM. Ngoài ra, hãy xem Generative AI Security Scoping Matrix để được hướng dẫn về việc kiểm duyệt thông tin bí mật và thông tin nhận dạng cá nhân (PII) như một phần của giải pháp generative AI của bạn.

Bằng cách làm theo các hướng dẫn này, các nhóm dữ liệu có thể triển khai việc tạo ground truth có độ trung thực cao để đánh giá trường hợp sử dụng trả lời câu hỏi bằng FMEval. Để biết các best practice về quản lý ground truth cho các đánh giá trả lời câu hỏi bằng FMEval mà bạn có thể sử dụng để thiết kế các prompt template ground truth của FMEval, hãy xem Các best practice về quản lý ground truth và diễn giải metric để đánh giá khả năng trả lời câu hỏi của generative AI bằng FMEval.

Tạo ground truth để đánh giá khả năng trả lời câu hỏi bằng FMEval

Một lựa chọn để bắt đầu với việc tạo ground truth là quản lý thủ công một tập dữ liệu câu hỏi-trả lời nhỏ. Tập dữ liệu được quản lý thủ công này nên nhỏ (dựa trên băng thông), có tín hiệu cao và lý tưởng nhất là được chuẩn bị bởi các chuyên gia về chủ đề (SME) của trường hợp sử dụng. Việc tạo tập dữ liệu này buộc phải có một bài tập căn chỉnh dữ liệu sớm trong quá trình đánh giá, đặt ra các câu hỏi và cuộc trò chuyện quan trọng giữa các bên liên quan về trường hợp sử dụng về những câu hỏi nào là quan trọng để đo lường theo thời gian cho doanh nghiệp. Kết quả của bài tập này có ba mặt:

• Sự căn chỉnh của các bên liên quan về N câu hỏi quan trọng hàng đầu
• Nhận thức của các bên liên quan về quy trình đánh giá
• Một tập dữ liệu ground truth khởi đầu có độ trung thực cao cho lần đánh giá proof of concept đầu tiên như một hàm của nhận thức và đánh giá

Mặc dù một bài tập quản lý ground truth của SME là một khởi đầu mạnh mẽ, nhưng ở quy mô của một cơ sở kiến thức doanh nghiệp, việc tạo ground truth thuần túy bằng SME sẽ trở nên tốn kém về thời gian và tài nguyên. Để mở rộng quy mô tạo và quản lý ground truth, bạn có thể áp dụng phương pháp tiếp cận dựa trên rủi ro kết hợp với chiến lược dựa trên prompt sử dụng LLM. Điều quan trọng cần lưu ý là ground truth do LLM tạo ra không thay thế cho sự tham gia của SME trường hợp sử dụng. Ví dụ: nếu ground truth được tạo bởi LLM trước khi có sự tham gia của SME, SME vẫn sẽ cần thiết để xác định những câu hỏi nào là cơ bản đối với doanh nghiệp và sau đó căn chỉnh ground truth với giá trị kinh doanh như một phần của quy trình human-in-the-loop.

Để minh họa, chúng tôi cung cấp hướng dẫn từng bước sử dụng thư của Amazon gửi cổ đông năm 2023 làm dữ liệu nguồn.

Để phù hợp với các best practice về quản lý ground truth cho việc trả lời câu hỏi bằng FMEval, ground truth được quản lý dưới dạng bộ ba câu hỏi-trả lời-sự kiện (question-answer-fact triplets). Câu hỏi và câu trả lời được quản lý để phù hợp với phản hồi trợ lý trả lời câu hỏi lý tưởng về nội dung, độ dài và phong cách. Sự kiện (fact) là một biểu diễn tối thiểu của câu trả lời ground truth, bao gồm một hoặc nhiều thực thể chủ đề của câu hỏi.

Ví dụ, hãy xem xét cách đoạn tài liệu nguồn sau đây từ thư của Amazon gửi cổ đông năm 2023 có thể được chuyển đổi thành ground truth trả lời câu hỏi.

Dear Shareholders:

Last year at this time, I shared my enthusiasm and optimism for Amazon’s future. Today, I have even more. The reasons are many, but start with the progress we’ve made in our financial results and customer experiences, and extend to our continued innovation and the remarkable opportunities in front of us. In 2023, Amazon’s total revenue grew 12% year-over-year (“Y oY”) from $514B to $575B. By segment, North America revenue increased 12% Y oY from $316B to $353B, International revenue grew 11% Y oY from$118B to $131B, and AWS revenue increased 13% Y oY from $80B to $91B. Further, Amazon’s operating income and Free Cash Flow (“FCF”) dramatically improved. Operating income in 2023 improved 201% YoY from $12.2B (an operating margin of 2.4%) to $36.9B (an operating margin of 6.4%).

Để chuyển đổi đoạn trích tài liệu nguồn thành ground truth, chúng tôi cung cấp một LLM prompt template cơ bản. Trong template, chúng tôi hướng dẫn LLM thực hiện phương pháp tiếp cận dựa trên sự kiện để diễn giải đoạn trích bằng logic chain-of-thought. Đối với ví dụ của chúng tôi, chúng tôi làm việc với Claude LLM của Anthropic trên Amazon Bedrock. Template này tương thích với và có thể được sửa đổi cho các LLM khác, chẳng hạn như LLM được lưu trữ trên Amazon Sagemaker Jumpstart và tự lưu trữ trên cơ sở hạ tầng AWS. Để sửa đổi prompt để sử dụng bởi các LLM khác, có thể cần một cách tiếp cận khác để biểu thị các phần prompt so với các thẻ XML. Ví dụ: các mô hình Meta Llama áp dụng các thẻ như <s> [INST] và <<SYS>>. Để biết thêm thông tin, hãy xem tài liệu của Amazon Bedrock về thiết kế prompt LLM và tài liệu FMEval.

LLM được gán một persona để thiết lập quan điểm của nó để thực hiện tác vụ. Trong các hướng dẫn, LLM xác định các sự kiện là các thực thể từ đoạn tài liệu nguồn. Đối với mỗi sự kiện, một bộ ba câu hỏi-trả lời-sự kiện được tập hợp dựa trên sự kiện được phát hiện và ngữ cảnh xung quanh nó. Trong prompt, chúng tôi cung cấp các ví dụ chi tiết để kiểm soát nội dung của các câu hỏi ground truth. Các ví dụ tập trung vào các câu hỏi về kiến thức kinh doanh theo từng đoạn trong khi bỏ qua siêu dữ liệu không liên quan có thể được chứa trong một đoạn. Bạn có thể tùy chỉnh các ví dụ prompt để phù hợp với trường hợp sử dụng ground truth của mình.

Chúng tôi tiếp tục hướng dẫn LLM áp dụng các best practice về quản lý ground truth cho FMEval, chẳng hạn như tạo nhiều biến thể của các sự kiện để phù hợp với nhiều biểu thức đơn vị có thể có. Các yếu tố quản lý bổ sung tùy thuộc vào tác vụ đang thực hiện—chẳng hạn như ngôn ngữ thương hiệu và giọng điệu—có thể được đưa vào prompt tạo ground truth. Với template sau, chúng tôi đã xác minh rằng Claude Sonnet 3.5 của Anthropic có thể tạo các thuộc tính ground truth tùy chỉnh phù hợp với các tính năng của FMEval, chẳng hạn như dấu phân cách <OR> để biểu thị các câu trả lời thay thế được chấp nhận cho một sự kiện ground truth.

"""You are an expert in ground truth curation for generative AI application evaluation on AWS.

Follow the instructions provided in the <instructions> XML tag for generating question answer fact triplets from a source document excerpt.

<instructions>
- Let's work this out in a step-by-step way to be sure we have the right answer.
- Review the source document excerpt provided in <document> XML tags below
- For each meaningful domain fact in the <document>, extract an unambiguous question-answer-fact set in JSON format including a question and answer pair encapsulating the fact in the form of a short sentence, followed by a minimally expressed fact extracted from the answer.

<domain_knowledge_focus>
- Focus ONLY on substantive domain knowledge contained within the document content
- Ignore all metadata and structural elements including but not limited to:
- Document dates, versions, page numbers
- Section numbers or titles
- Table structure or row/column positions
- List positions or ordering
- Questions must reference specific domain entities rather than generic document elements
</domain_knowledge_focus>

<context_specification_requirements>
Document Source Identification
- Always reference the specific source document and its date/version
- Example: "According to the [Document Name + Date], what is [specific query]?"

Cross-Reference Prevention
- Each question must be answerable from the current document chunk only
- Do not create questions requiring information from multiple documents
- Example: "In this [Document Name], what are [specific requirements]?"

Department/LOB Specification
- Always specify the relevant department, line of business, or organizational unit
- Example: "What are the [Department Name]'s requirements for [specific process]?"

Document Section Targeting
- Reference specific sections when the information location is relevant
- Example: "In Section [X] of [Document Name], what are the steps for [specific process]?"

Role-Based Context
- Specify relevant roles, responsibilities, or authority levels
- Example: "Which [specific roles] are authorized to [specific action]?"

Version Control Elements
- Include relevant version or revision information
- Example: "What changes were implemented in the [Month Year] revision of [Document]?"

Policy/Procedure Numbers
- Include specific policy or procedure reference numbers
- Example: "Under Policy [Number], what are the requirements for [specific action]?"

Regulatory Framework References
- Specify relevant regulatory frameworks or compliance requirements
- Example: "What [Regulation] compliance requirements are specified for [specific process]?"

System/Platform Specification
- Name specific systems, platforms, or tools
- Example: "What steps are required in [System Name] to [specific action]?"

Document Type Classification
- Specify the type of document (SOP, Policy, Manual, etc.)
- Example: "In the [Document Type + Number], where is [specific information] stored?"

Temporal Validity
- Include effective dates or time periods
- Example: "What process is effective from [Date] according to [Document]?"

Geographic Jurisdiction
- Specify relevant geographic regions or jurisdictions
- Example: "What requirements apply to [Region] according to [Document]?"

Business Process Owner
- Identify relevant process owners or responsible parties
- Example: "According to [Document], who owns the process for [specific action]?"

Classification Level
- Include relevant security or confidentiality classifications
- Example: "What are the requirements for [Classification Level] data?"

Stakeholder Scope
- Specify relevant stakeholders or approval authorities
- Example: "Which [stakeholder level] must approve [specific action]?"
</context_specification_requirements>

<question_quality_criteria>
- Questions must be specific enough that a vector database can match them to the relevant document chunk
- Questions should include key identifying terms, names, and context
- Questions should target concrete, actionable information
- Answers should provide complete context without referring back to document elements
</question_quality_criteria>

<output_format>
The question-answer-fact set should each be a short string in JSON format with the keys: "question", "ground_truth_answer", "fact"
</output_format>

<best_practices>
- Questions, answers, and facts should not refer to the subject entity as "it" or "they", and instead refer to it directly by name
- Questions, answers, and facts should be individually unique to the document chunk, such that based on the question a new call to the retriever will address the correct document section when posing the ground truth question
- Facts should be represented in 3 or fewer words describing an entity in the <document>
- If there are units in the fact, the "fact" entry must provide multiple versions of the fact using <OR> as a delimiter. See <unit_variations> for examples.
<unit_variations>
- Dollar Unit Equivalencies: `1,234 million<OR>1.234 billion`
- Date Format Equivalencies: `2024-01-01<OR>January 1st 2024`
- Number Equivalencies: `1<OR>one`
</unit_variations>
</best_practices>

- Start your response immediately with the question-answer-fact set JSON, and separate each extracted JSON record with a newline.
</instructions>

<document>
{context_document}
</document>

Now, extract the question answer pairs and fact from the document excerpt according to your instructions, starting immediately with JSON and no preamble."""

Đầu ra generation được cung cấp dưới dạng các bản ghi JSONLines theo sự kiện ở định dạng sau, trong đó các phần tử trong ngoặc vuông đại diện cho các giá trị từ một dòng trong Bảng 1.

{

"question": "[Question]",

"ground_truth_answer": "[Ground Truth Answer]",

"fact": "[Fact]"

}

Dưới đây là một vài ví dụ về ground truth được tạo:

Mở rộng quy mô tạo ground truth bằng pipeline

Để tự động hóa việc tạo ground truth, chúng tôi cung cấp kiến trúc pipeline xử lý hàng loạt (batch pipeline) phi máy chủ, được thể hiện trong hình sau. Ở cấp độ cao, pipeline AWS Step Functions chấp nhận dữ liệu nguồn trong Amazon Simple Storage Service (Amazon S3), và điều phối các hàm AWS Lambda để nhập, chia chunk và tạo prompt trên Amazon Bedrock để tạo ground truth JSONLines theo sự kiện.

Hình ảnh mô tả pipeline Step Function bao gồm trạng thái map chunking và trạng thái map generation với nhánh rẽ cho quy trình human-in-the-loop

Có ba đầu vào người dùng cho step function:

• Tên tùy chỉnh cho tập dữ liệu ground truth
• Prefix Amazon S3 đầu vào cho dữ liệu nguồn
• Phần trăm mẫu để đánh giá (review).

Các cấu hình bổ sung được đặt bởi các biến môi trường Lambda, chẳng hạn như S3 source bucket và Amazon Bedrock Model ID để gọi khi generation.

{

"dataset_name": "YOUR_DATASET_NAME”,

"input_prefix": "YOUR INPUT_PREFIX",

"review_percentage": "REVIEW PERCENTAGE"

}

Sau khi payload ban đầu được chuyển, một hàm validation sẽ tập hợp cấu trúc payload sự kiện toàn cầu về mặt đầu vào hệ thống và đầu vào người dùng.

{

"system_input":

{

"run_id": "<AWS Step Function execution ID>",

"input_bucket": "<Input data Amazon S3 bucket>",

"output_bucket": "<Output data Amazon S3 bucket>",

"output_document_chunks_prefix": "<Amazon S3 bucket Prefix to store chunks>",

"chunk_size": "<Document chunk size>",

"chunk_overlap": "<Number of tokens that will overlap across consecutive chunks>"

},

"user_input":

{

"dataset_name": "<Dataset name>",

"input_prefix": "<Amazon S3 bucket prefix for ground truth generation data input data>",

"review_percentage": "<Percent of records to flag for human review>"

}

}

Sau khi validation, trạng thái distributed map đầu tiên lặp lại các file trong input bucket để bắt đầu các quy trình nhập và chia chunk tài liệu với khả năng mở rộng theo chiều ngang. Các chunk kết quả được lưu trữ trong một S3 bucket trung gian.

Distributed map thứ hai là lõi generation của pipeline. Mỗi chunk được tạo bởi map trước đó được đưa vào làm đầu vào cho prompt tạo ground truth trên Amazon Bedrock. Đối với mỗi chunk, một file JSONLines chứa các bộ ba câu hỏi-trả lời-sự kiện được validation và lưu trữ trong một S3 bucket tại output prefix.

Hình sau cho thấy chế độ xem cấu trúc dữ liệu và nguồn gốc từ các đoạn tài liệu đến chunk ground truth cuối cùng trên các trạng thái map chunking và generation. Việc đánh số giữa hai hình cho thấy cấu trúc dữ liệu hiện có tại mỗi điểm trong pipeline. Cuối cùng, các file JSONLines được tổng hợp trong một Amazon SageMaker Processing Job, bao gồm việc gán một mẫu ngẫu nhiên để đánh giá thủ công dựa trên đầu vào của người dùng.

Hình ảnh mô tả một tài liệu được chia thành các chunk, sau đó được chia nhỏ thành các bộ ba ground truth được lấy từ mỗi chunk

Bước cuối cùng của pipeline là bước tổng hợp sử dụng job SageMaker Processing. Bước tổng hợp bao gồm việc nối các bản ghi JSONLines được tạo bởi mọi lần thực thi con của map generation thành một file đầu ra ground truth duy nhất. Một tỷ lệ phần trăm được chọn ngẫu nhiên của các bản ghi trong file đầu ra được lấy mẫu và gắn cờ để đánh giá như một phần của quy trình human-in-the-loop.

Đánh giá ground truth cho đánh giá khả năng trả lời câu hỏi bằng FMEval

Trong phần này, chúng tôi thảo luận về hai thành phần chính của việc đánh giá chất lượng ground truth: human-in-the-loop và áp dụng LLM làm Judge. Đo lường chất lượng ground truth là một thành phần thiết yếu của vòng đời đánh giá.

Human-in-the-loop

Mức độ đánh giá ground truth thủ công cần thiết được xác định bởi rủi ro có ground truth không chính xác và những hàm ý tiêu cực của nó. Việc đánh giá ground truth bởi SME trường hợp sử dụng có thể xác minh xem logic kinh doanh quan trọng có được đại diện thích hợp bởi ground truth hay không. Quá trình đánh giá ground truth bởi con người được gọi là human-in-the-loop (HITL), và một ví dụ về quy trình HITL được thể hiện trong hình sau.

Các bước của HTIL là:

1. Phân loại rủi ro: thực hiện phân tích rủi ro sẽ thiết lập mức độ nghiêm trọng và khả năng xảy ra các sự kiện tiêu cực do ground truth không chính xác được sử dụng để đánh giá trường hợp sử dụng generative AI. Dựa trên kết quả phân tích, gán cho tập dữ liệu ground truth một mức độ rủi ro: Thấp, Trung bình, Cao hoặc Nghiêm trọng (Critical). Bảng dưới đây phác thảo mối quan hệ giữa mức độ nghiêm trọng của sự kiện, khả năng xảy ra và mức độ rủi ro. Xem Tìm hiểu cách đánh giá rủi ro của hệ thống AI để tìm hiểu sâu về việc thực hiện đánh giá rủi ro AI.
2. Đánh giá thủ công: Dựa trên mức độ rủi ro được gán, các chuyên gia đánh giá trường hợp sử dụng kiểm tra một lượng tương ứng của ground truth trường hợp sử dụng. Các tổ chức có thể đặt ngưỡng chấp nhận cho tỷ lệ phần trăm can thiệp HITL dựa trên khả năng chịu rủi ro của họ. Tương tự, nếu một tập dữ liệu ground truth được nâng cấp từ trường hợp sử dụng rủi ro thấp lên rủi ro trung bình, mức độ can thiệp HITL tăng lên sẽ là cần thiết.
3. Xác định phát hiện: Người đánh giá có thể xác định bất kỳ sự ảo giác nào liên quan đến dữ liệu nguồn, thách thức về tính xác thực thông tin theo chuyên môn của họ, hoặc các tiêu chí khác do tổ chức đặt ra. Trong bài viết này, chúng tôi tập trung vào phát hiện ảo giác và tính xác thực thông tin.
4. Hành động kết quả: Người đánh giá có thể thực hiện các hành động kinh doanh dựa trên đánh giá của họ, chẳng hạn như cập nhật và xóa bản ghi, hoặc viết lại các tài liệu nguồn áp dụng. Đưa SME LLMOps vào để áp dụng các best practice quản lý tập dữ liệu cũng có thể là một kết quả.

Hình ảnh bốn phần mô tả phân loại rủi ro, đánh giá của con người, xác định phát hiện và hành động kết quả

Áp dụng bảng rủi ro từ Tìm hiểu cách đánh giá rủi ro của hệ thống AI, mức độ nghiêm trọng và khả năng xảy ra rủi ro đối với một tập dữ liệu ground truth xác thực một chatbot sản xuất với tần suất sử dụng của khách hàng sẽ lớn hơn một tập dữ liệu đánh giá nội bộ được sử dụng bởi các nhà phát triển để phát triển một prototype.

Tiếp theo, chúng tôi sẽ hướng dẫn quy trình từng bước thực hiện đánh giá thủ công để phát hiện ảo giác và tính xác thực thông tin. Đánh giá thủ công được thực hiện bằng cách so sánh đầu vào chunk ground truth với prompt LLM với các bộ ba câu hỏi-trả lời-sự kiện được tạo ra. Chế độ xem này được thể hiện trong bảng sau.

Sau đó, người đánh giá thủ công xác định và thực hiện hành động dựa trên các phát hiện để sửa chữa hệ thống. Ảo giác LLM là hiện tượng LLM tạo ra thông tin nghe có vẻ hợp lý nhưng không chính xác về mặt thực tế hoặc vô nghĩa, được trình bày một cách tự tin như là sự thật. Các tổ chức có thể đưa ra các phẩm chất bổ sung để đánh giá và chấm điểm ground truth, phù hợp với mức độ rủi ro và yêu cầu trường hợp sử dụng.

Trong phát hiện ảo giác, người đánh giá tìm cách xác định văn bản đã được LLM tạo ra không chính xác. Một ví dụ về ảo giác và khắc phục được thể hiện trong bảng sau. Một người đánh giá sẽ nhận thấy trong dữ liệu nguồn rằng tổng doanh thu của Amazon tăng 12% so với năm trước, nhưng câu trả lời ground truth đã ảo giác ra con số 15%. Trong khắc phục, người đánh giá có thể thay đổi điều này trở lại thành 12%.

Trong đánh giá tính xác thực của SME, người đánh giá tìm cách xác thực xem ground truth có thực sự đúng sự thật hay không. Ví dụ, dữ liệu nguồn được sử dụng cho prompt tạo ground truth có thể đã lỗi thời hoặc không chính xác. Bảng sau cho thấy quan điểm của đánh giá HITL bởi một SME miền.

Các ứng dụng machine learning truyền thống cũng có thể cung cấp thông tin cho thiết kế quy trình HITL. Để biết các ví dụ về HITL cho machine learning truyền thống, hãy xem Đánh giá human-in-the-loop các giải thích mô hình với Amazon SageMaker Clarify và Amazon A2I.

LLM-as-a-judge

Khi mở rộng quy mô HITL, các LLM đánh giá có thể thực hiện phát hiện ảo giác và khắc phục. Ý tưởng này được gọi là self-reflective RAG, và có thể được sử dụng để giảm—nhưng không loại bỏ—mức độ nỗ lực của con người trong quy trình phát hiện ảo giác. Như một phương tiện để mở rộng quy mô đánh giá LLM-as-a-judge, Amazon Bedrock hiện cung cấp khả năng sử dụng LLM đánh giá và thực hiện kiểm tra lý luận tự động với Amazon Bedrock Guardrails để tự xác thực toán học hợp lý dựa trên các chính sách được xác định trước. Để biết thêm thông tin về việc triển khai, hãy xem Các khả năng đánh giá RAG và LLM-as-a-judge mới trong Amazon Bedrock và Ngăn chặn lỗi thực tế từ ảo giác LLM bằng kiểm tra Lý luận Tự động hợp lý về mặt toán học (bản xem trước).

Hình sau cho thấy một ví dụ về sơ đồ cấp cao của một mô hình self-reflective RAG. Một ứng dụng generative AI dựa trên RAG tạo ra các phản hồi được đưa đến một ứng dụng judge. Ứng dụng judge phản ánh xem các phản hồi có không đầy đủ, bị ảo giác hay không liên quan hay không. Dựa trên đánh giá, dữ liệu được định tuyến dọc theo quy trình khắc phục tương ứng.

Hình ảnh mô tả chuỗi generation (tạo) được theo sau bởi chuỗi judge (đánh giá), chuỗi này định tuyến các yêu cầu trở lại một cách thông minh nếu cần để re-ranking (xếp hạng lại)

Quy tắc vàng trong việc triển khai HITL hoặc LLM-as-a-judge như một phần của việc tạo ground truth là đảm bảo quy trình đánh giá của tổ chức phù hợp với mức độ rủi ro được chấp nhận cho tập dữ liệu ground truth.

Tóm tắt

Trong bài viết này, chúng tôi đã cung cấp hướng dẫn về việc tạo và đánh giá ground truth để đánh giá các ứng dụng trả lời câu hỏi bằng FMEval. Chúng tôi đã khám phá các best practice để áp dụng LLM nhằm mở rộng quy mô tạo ground truth trong khi vẫn duy trì chất lượng và độ chính xác. Kiến trúc pipeline xử lý hàng loạt phi máy chủ mà chúng tôi trình bày cung cấp một giải pháp có thể mở rộng để tự động hóa quy trình này trên các cơ sở kiến thức doanh nghiệp lớn. Chúng tôi cung cấp một prompt tạo ground truth mà bạn có thể sử dụng để bắt đầu đánh giá các trợ lý kiến thức bằng các metric đánh giá Factual Knowledge và QA Accuracy của FMEval.

Bằng cách làm theo các hướng dẫn này, các tổ chức có thể tuân theo các best practice AI có trách nhiệm để tạo các tập dữ liệu ground truth chất lượng cao cho việc đánh giá xác định các trợ lý trả lời câu hỏi. Các đánh giá cụ thể theo trường hợp sử dụng được hỗ trợ bởi ground truth được quản lý tốt đóng một vai trò quan trọng trong việc phát triển và triển khai các giải pháp AI đáp ứng các tiêu chuẩn cao nhất về chất lượng và trách nhiệm.

Cho dù bạn đang phát triển một công cụ nội bộ, một trợ lý ảo hướng tới khách hàng, hay khám phá tiềm năng của generative AI cho tổ chức của mình, chúng tôi khuyến khích bạn áp dụng các best practice này. Hãy bắt đầu triển khai quy trình tạo và đánh giá ground truth mạnh mẽ cho các đánh giá trả lời câu hỏi bằng generative AI của bạn ngay hôm nay với FMEval.

Về tác giả

Samantha Stuart là Data Scientist tại AWS Professional Services, và đã cung cấp dịch vụ cho khách hàng trong các dự án generative AI, MLOps và ETL. Samantha có bằng thạc sĩ nghiên cứu kỹ thuật từ Đại học Toronto, nơi cô là tác giả của một số ấn phẩm về AI lấy dữ liệu làm trung tâm cho thiết kế hệ thống phân phối thuốc. Ngoài công việc, cô thường được bắt gặp chơi nhạc, dành thời gian cho bạn bè và gia đình, ở phòng tập yoga, hoặc khám phá Toronto.

Philippe Duplessis-Guindon là chuyên gia tư vấn cloud tại AWS, nơi anh đã làm việc trong nhiều dự án generative AI. Anh đã chạm đến hầu hết các khía cạnh của các dự án này, từ cơ sở hạ tầng và DevOps đến phát triển phần mềm và AI/ML. Sau khi lấy bằng cử nhân kỹ thuật phần mềm và bằng thạc sĩ về thị giác máy tính và machine learning từ Polytechnique Montreal, Philippe gia nhập AWS để đưa chuyên môn của mình vào phục vụ khách hàng. Khi không làm việc, bạn có thể tìm thấy Philippe ở ngoài trời—leo núi hoặc chạy bộ.

Rahul Jani là Data Architect tại AWS Professional Service. Anh hợp tác chặt chẽ với các khách hàng doanh nghiệp xây dựng các nền tảng dữ liệu hiện đại, các ứng dụng generative AI và MLOps. Anh chuyên về thiết kế và triển khai các ứng dụng big data và phân tích trên nền tảng AWS. Ngoài công việc, anh coi trọng thời gian chất lượng bên gia đình và nắm bắt các cơ hội đi du lịch.

Ivan Cui là Data Science Lead tại AWS Professional Services, nơi anh giúp khách hàng xây dựng và triển khai các giải pháp sử dụng ML và generative AI trên AWS. Anh đã làm việc với khách hàng trong nhiều ngành công nghiệp khác nhau, bao gồm phần mềm, tài chính, dược phẩm, chăm sóc sức khỏe, IoT, và giải trí và truyền thông. Trong thời gian rảnh, anh thích đọc sách, dành thời gian cho gia đình và đi du lịch.