Đang in số

Cầm cốc cà phê

Đang chạy mực qua máy in — từng lớp màu một, kiên nhẫn nhé!

AI Agent hỗ trợ QA sinh test case cho RAG Chatbot · AI·20K Demo Day Zine

№ 49

AI Agent hỗ trợ QA sinh test case cho RAG Chatbot

Sản phẩm là web app ứng dụng AI giúp QA chuyển PRD Markdown thành bộ testcase có thể chỉnh sửa và thực thi cho các tính năng sử dụng LLM. Hệ thống hỗ trợ làm rõ yêu cầu, kiểm thử các tình huống chức năng, biên, an toàn và ảo giác, đồng thời tạo báo cáo pass/fail có lý do để developer dễ dàng tái hiện và sửa lỗi.

Bài toán Các sản phẩm sử dụng LLM hoặc RAG tạo ra đầu ra mở, khó dự đoán hoàn toàn và không thể kiểm thử hiệu quả chỉ bằng các assertion truyền thống. Khi tiếp nhận một PRD dài, QA thường phải tự xác định tính năng nào thực sự sử dụng LLM, suy luận những yêu cầu còn thiếu, viết testcase và đánh giá kết quả bằng mắt. Quy trình này tốn thời gian, phụ thuộc nhiều vào kinh nghiệm cá nhân và dễ bỏ sót các tình huống quan trọng như edge case, hallucination, prompt injection, nội dung độc hại hoặc rò rỉ dữ liệu nhạy cảm. Một khó khăn khác là khả năng truy vết. Nếu kết quả chỉ được đánh giá chủ quan, developer khó biết testcase đã dùng phiên bản PRD, context, endpoint và tiêu chí nào, từ đó khó tái hiện và sửa lỗi. Sản phẩm hướng đến hai nhóm người dùng:

QA Engineer quản lý dự án, phân tích PRD, hoàn thiện yêu cầu, tạo và chạy testcase.
Developer xem lại đặc tả, testcase và báo cáo ở chế độ chỉ đọc để điều tra lỗi. Mục tiêu của sản phẩm không phải thay thế QA hoặc tự động quyết định phát hành, mà cung cấp một quy trình kiểm thử LLM có cấu trúc, nhất quán và giải thích được.

Giải pháp kỹ thuật Sản phẩm là một web app sử dụng AI để chuyển PRD Markdown thành bộ testcase có thể chỉnh sửa, thực thi và đánh giá. Luồng nghiệp vụ chính là: PRD → phân loại tính năng LLM → làm rõ yêu cầu → Feature Test Specification → sinh testcase → chạy và đánh giá → báo cáo Phân tích PRD và xác định phạm vi kiểm thử QA tạo project, khai báo domain của chatbot, tạo các context dùng chung và tải lên một PRD Markdown. Hệ thống dùng LLM để tách PRD thành các feature và đề xuất một trong ba phân loại:

llm_direct: tính năng sử dụng trực tiếp LLM;
non_llm: tính năng không sử dụng trực tiếp LLM;
needs_qa_confirmation: chưa đủ căn cứ để phân loại. AI chỉ đưa ra đề xuất; QA luôn có quyền sửa và xác nhận. Trong MVP, chỉ các feature được xác nhận là llm_direct mới tiếp tục sang quy trình tạo testcase. Mỗi feature LLM được cấu hình riêng:
một hoặc nhiều context;
đường dẫn endpoint tương đối trên domain của project;
request schema và response schema;
các trường câu trả lời cần trích xuất bằng JSONPath. Làm rõ và chuẩn hóa yêu cầu Sau khi feature được xác nhận, hệ thống đánh giá mức độ đầy đủ của thông tin và gắn nhãn sufficient hoặc insufficient. Với feature thiếu thông tin, QA có thể mở phiên chat làm rõ yêu cầu. AI đặt câu hỏi và tạo một đề xuất feature hoàn chỉnh, gồm:
mô tả tính năng;
yêu cầu chức năng;
yêu cầu phi chức năng;
yêu cầu an toàn và bảo mật;
rubric đánh giá;
các context liên quan. Đề xuất không được tự động áp dụng. QA có thể xác nhận, từ chối hoặc yêu cầu chỉnh sửa. Sau đó, hệ thống tạo Feature Test Specification để QA tiếp tục rà soát và phê duyệt. Nếu QA chủ động tiếp tục với feature chưa đủ thông tin, specification và testcase được gắn nhãn low_quality để thể hiện rủi ro, thay vì chặn toàn bộ quy trình. Sinh và quản lý testcase Từ specification đã được phê duyệt, AI sinh testcase thuộc bốn nhóm:

Phụ lục — Demo & Slides

Video demo

Mở trong tab mới ↗

Bản demo trực tiếp

Mở trong tab mới ↗

Slide trình bày

Mở trong tab mới ↗

Phụ lục — Demo & Slides

Video demo

Bản demo trực tiếp

Slide trình bày

passed: đáp ứng các tiêu chí;
failed: phản hồi hợp lệ về kỹ thuật nhưng không đạt yêu cầu;
error: lỗi hệ thống, provider, timeout hoặc evaluation. Cách phân biệt này giúp tránh trường hợp lỗi kỹ thuật bị hiểu nhầm thành lỗi chất lượng sản phẩm. Kiến trúc hệ thống Giải pháp sử dụng kiến trúc modular monolith để giảm độ phức tạp trong giai đoạn MVP:
Next.js/React xây dựng giao diện cho QA và developer;
FastAPI cung cấp REST API, xác thực JWT, phân quyền, validation và điều phối nghiệp vụ;
PostgreSQL là nguồn dữ liệu chính, lưu phiên bản và snapshot;
Redis + RQ xử lý các tác vụ nền;
DeepEval thực hiện metric evaluation và hỗ trợ Red Teaming;
SSE cập nhật trạng thái phân tích, sinh testcase và chạy test theo thời gian thực;
Docker Compose triển khai các thành phần trên một cloud VM. Các tác vụ dài như phân tích PRD, sinh testcase, thực thi và evaluation chạy qua worker nền để tránh giữ HTTP request quá lâu. Chat làm rõ yêu cầu được xử lý đồng bộ vì cần phản hồi tuần tự và trực tiếp với QA. Hệ thống tách phần tích hợp LLM thành các adapter độc lập provider/model. Nhờ đó có thể thay đổi mô hình, nhà cung cấp hoặc sử dụng fake adapter khi kiểm thử mà không phải sửa business logic. Truy vết và bảo mật PRD, feature, context, endpoint configuration, specification và testcase đều được quản lý theo version. Mỗi lần chạy sẽ đóng băng snapshot của toàn bộ dữ liệu liên quan, giúp developer tái hiện đúng điều kiện kiểm thử ngay cả khi tài liệu hoặc cấu hình đã được chỉnh sửa sau đó. Target Bearer token chỉ tồn tại tạm thời trong bộ nhớ frontend và payload thực thi, không được lưu trong database, report, snapshot hoặc log. Runner gọi endpoint bên ngoài trong môi trường cô lập và áp dụng các biện pháp chống SSRF như:
chỉ cho phép HTTPS public;
chặn địa chỉ private, loopback và metadata;
không theo redirect;
kiểm tra DNS rebinding;
giới hạn tài nguyên, thời gian và kích thước response;
không cho runner truy cập PostgreSQL, Redis, Docker socket hoặc filesystem của host.

chỉ nhận một PRD Markdown đang hoạt động trên mỗi project;
chỉ kiểm thử feature sử dụng trực tiếp LLM;
chỉ hỗ trợ chatbot một lượt, một request và một response JSON;
chỉ gọi POST endpoint trên HTTPS public domain;
tối đa 10 context mỗi project và 20 testcase mỗi suite;
chưa hỗ trợ PDF, DOCX, OCR, vector retrieval, chatbot đa lượt hoặc tool calling;
một suite chạy tại một thời điểm để kiểm soát tài nguyên và chi phí. Các lựa chọn Next.js, FastAPI, PostgreSQL, Redis/RQ và Docker Compose đều là công nghệ phổ biến, có hệ sinh thái tốt và phù hợp với năng lực triển khai MVP. Kiến trúc modular monolith cũng thực tế hơn microservice vì nhóm có thể phát triển nhanh, dùng chung domain model và debug trong một codebase. Tính khả thi có thể được chứng minh qua một bộ chuẩn gồm 20–30 testcase có nhãn mong đợi. Nhóm có thể đo:
hệ thống có phát hiện đủ bốn nhóm testcase hay không;
kết quả evaluation có khớp với nhãn chuẩn hay không;
báo cáo có đủ dữ liệu để developer tái hiện hay không;
QA có hoàn thành trọn vẹn luồng từ PRD đến report hay không. Tuy nhiên, dự án vẫn có một số rủi ro kỹ thuật:
Kết quả phân tích, sinh testcase và đánh giá phụ thuộc vào chất lượng LLM.
Việc dùng chính LLM để đánh giá đầu ra LLM có thể tạo ra sai lệch hoặc kết quả không ổn định.
Runner cô lập và chính sách chống SSRF là phần tương đối phức tạp đối với một MVP ngắn hạn.
Chat đồng bộ có thể gặp timeout từ provider.
Versioning và snapshot tạo ra mô hình dữ liệu nhiều quan hệ, cần migration và integration test kỹ.
Chi phí có thể tăng nếu chạy nhiều testcase hoặc dùng metric dựa trên LLM. Các rủi ro này được giảm nhẹ bằng QA review bắt buộc, rule kiểm tra xác định trước metric AI, threshold có cấu hình, adapter độc lập provider, fake/mock LLM khi test, không tự động retry các tác vụ có thể gọi lại chatbot và giới hạn số testcase. Vì vậy, hero flow F1–F5 là khả thi cho demo nếu nhóm ưu tiên luồng lõi và kiểm thử contract. Các khả năng như CI/CD, dashboard xu hướng hoặc nền tảng kiểm thử quy mô lớn không nên đưa vào tiêu chí bắt buộc của MVP.

Cung cấp service token và API để CI/CD kích hoạt suite.
Trả về run_id để pipeline theo dõi kết quả.
Sử dụng pass/fail/error làm quality gate trước khi release.
Xây dựng dashboard thể hiện xu hướng chất lượng theo feature, suite và thời gian.
So sánh hai lần chạy để xác định testcase hoặc metric nào bị regression. Mở rộng khả năng kiểm thử Sản phẩm có thể tiếp tục hỗ trợ:
chatbot đa lượt và lưu trạng thái hội thoại;
tool calling và agent workflow;
nhiều PRD hoặc nhiều phiên bản đang hoạt động trong một project;
tài liệu PDF, DOCX và OCR;
upload tài liệu RAG;
embedding, vector retrieval và kiểm thử chất lượng truy xuất;
sinh testcase cho các feature không trực tiếp sử dụng LLM;
nhiều suite chạy đồng thời với quota và cơ chế điều phối công bằng;
xuất testcase thành pytest hoặc định dạng dùng được trong các framework QA hiện có. Nâng cao evaluation Evaluation có thể phát triển theo hướng:
kết hợp nhiều judge model để giảm thiên lệch;
hiệu chỉnh metric bằng tập dữ liệu do con người gắn nhãn;
phát hiện độ không ổn định bằng cách chạy lặp lại cùng testcase;
đánh giá chi phí, token usage và độ trễ;
quản lý bộ regression benchmark theo từng domain;
tự đề xuất threshold dựa trên lịch sử;
mở rộng red teaming theo ngành và chính sách riêng của doanh nghiệp. Phát triển thành sản phẩm thực tế Về dài hạn, hệ thống có thể tách phần thực thi thành một local runner hoặc CLI đặt gần codebase và hạ tầng của khách hàng. Cách tiếp cận này giúp dữ liệu, token và endpoint nội bộ không phải rời khỏi môi trường doanh nghiệp, trong khi website trung tâm vẫn quản lý project, testcase, dashboard và report. Khi số lượng người dùng tăng, kiến trúc có thể được nâng cấp từ modular monolith sang các dịch vụ độc lập cho generation, execution và evaluation; Redis/RQ có thể được thay bằng hệ thống queue hỗ trợ routing, retry và dead-letter queue tốt hơn. Đồng thời, sản phẩm cần bổ sung quản lý tổ chức, RBAC chi tiết, audit log, mã hóa secret, quota, billing, observability và cơ chế tuân thủ dữ liệu. Tóm lại, sản phẩm có tiềm năng trở thành một nền tảng kiểm thử và quản trị chất lượng cho ứng dụng LLM: biến yêu cầu chưa cấu trúc thành testcase có căn cứ, kết hợp kiểm tra xác định với đánh giá ngữ nghĩa, đồng thời giữ con người ở vị trí phê duyệt cuối cùng.

Đang in số ★

AI Agent hỗ trợ QA sinh test case cho RAG Chatbot

Phụ lục — Demo & Slides

Phụ lục — Demo & Slides

Phụ lục — Demo & Slides

Đang in số