Xây dựng một phần mềm kiểm tra đạo văn như thế nào?

Bài viết này sẽ tóm tắt về các vấn đề kỹ thuật mà bạn sẽ phải đối mặt khi xây dựng một hệ thống kiểm tra đạo văn phục vụ nhiều người dùng. Đây là những chia sẻ của mình khi trải qua nhiều năm phát triển và duy trì một phần mềm kiểm tra đạo văn. Trong bài mình có thể xen kẽ nhiều từ tiếng Anh mà mình khó thể dịch sang tiếng Việt sao cho sát nghĩa, mong các bạn thông cảm và có thể bình luận để mình giải thích kỹ hơn nếu chưa hiểu nhé! Thank a lot!!!

Phần mềm kiểm tra đạo văn là gì?

Đầu tiên ta cần phải hiểu phần mềm kiểm tra đạo văn là gì trước đã. Chắc chắc rằng các bạn sinh viên năm cuối khi làm khóa luận sẽ biết về nó. Thường thì các thầy cô hoặc nhà trường sẽ yêu cầu hoặc khuyến khích bạn quét đạo văn trước khi nộp cho hội đồng bảo vệ. Nói một cách ngắn gọn thì phần mềm kiểm tra đạo văn có chức năng chính là đối chiếu nội dung trong một văn bản nào đó với nguồn dữ liệu (internet, sách, báo, giáo trình,...) để tìm ra những câu nội dung trong văn bản đó có sự tương đồng với nguồn. Output của phần mềm là điểm trùng lặp của toàn bộ văn bản kèm theo báo cáo kết quả chi tiết, bao gồm câu nào trùng với nguồn nào, nội dung nguồn là gì, giống bao nhiêu phần trăm.

Lưu ý rằng: Ta thường gọi phần mềm check đạo văn cho dễ hiểu, dễ gọi chứ thực ra gọi là phần mềm kiểm tra trùng lặp sẽ chuẩn hơn. Vì đạo văn có thể không trùng lặp và trùng lặp có thể không là đạo văn. Vì nó không liên quan đến kỹ thuật nên ta sẽ không nói chi tiết ở đây.

Xây dựng phần mềm đạo văn cần những gì?

Ta hãy bắt đầu từ mô tả yêu cầu: Input của phần mềm là 1 văn bản (thường là nhập TEXT, file DOC/DOCX hoặc file PDF) và Output là báo cáo kết quả trùng lặp. Để làm được việc này thì các bước xử lý cơ bản sẽ như sau:

1. Đọc nội dung của Input nếu nó là file, còn nếu nhập TEXT thì bỏ qua bước này

2. Đối chiếu nội dung với nguồn dữ liệu đối sánh: Thường sẽ chia nhỏ nội dung thành các đoạn nhỏ hơn (thường là theo câu hoặc theo các đoạn độ dài cố định). Sau khi kiểm tra và tính điểm của từng đoạn nhỏ, ta sẽ tổng hợp lại để tính điểm cho toàn bộ văn bản.

3. Tạo báo cáo kết quả trùng lặp: Thường là tạo báo cáo hoặc bôi trực tiếp trên file, kèm theo thông tin điểm và nguồn trùng lặp.

Có thể thấy rằng trong 3 bước trên, bước thứ 2 thiên về việc xử lý dữ liệu (Data Processing) hay xử lý ngôn ngữ tự nhiên (NLP), còn bước 1 và bước 3 thiên về khía cạnh Software Engineering nhiều hơn. Ở bước 1 ta sẽ lấy file người dùng tải lên và dùng các thư viện có sẵn như LibreOffice, OpenOffice, PDFBox,... để convert và lấy nội dung của tài liệu. Còn bước 3 thì cần nhiều kỹ thuật hơn, nhất là FrontEnd để làm sao hiển thị ra báo cáo chi tiết, trực quan nhất cho người dùng cuối. Về mặt Software Engineering thì trên đây đã có khá nhiều bài về BackEnd, FrontEnd, UI/UX,... rồi nên ta sẽ không nói chi tiết về nó ở đây và sẽ tập trung vào bước 2, là công việc phức tạp nhất và quyết định chất lượng của phần mềm.

Vì sao bước 2 lại quan trọng như vậy? Bởi vì chất lượng của phần mềm kiểm tra đạo văn phụ thuộc vào việc nó có phát hiện ra được nhiều nguồn trùng lặp hay không. Phần mềm càng quét ra nhiều đoạn trùng lặp thì độ tin cậy càng cao (đó là đối với giảng viên, còn với sinh viên thì nỗi đau càng lớn). Do vậy, phần tiếp theo ta sẽ dành riêng để phân tích những vấn đề ta phải đối mặt khi đối sánh dữ liệu.

Các vấn đề phải đối mặt khi đối sánh dữ liệu?

Sẽ có vài bạn sẽ đặt câu hỏi: sao không ném từng câu lên Google để nó tìm là xong, cùng lắm là giả lập trình duyệt dùng Selenium hay Puppeteer là được? Mình xin phép trả lời là được nhưng chỉ áp dụng cho cá nhân với tài liệu nhỏ và có nhiều thời gian. Vì một khóa luận thường có độ dài khoảng 50-150 trang với số câu trung bình khoảng 1.500 câu (tùy theo từng chuyên ngành), nghĩa là ta phải search Google 1.500 lần liên tục thì mới xong 1 tài liệu. Nếu 1 giây ta tìm được 1 câu thì tổng thời gian xử lý sẽ tầm 25 phút. Nghe có vẻ ổn nhưng thực tế là bạn sẽ bị Google chặn bằng captcha chỉ trong chưa đầy 1 phút, nếu bạn xui xẻo hơn là nó sẽ chặn hẳn IP của bạn. Giải pháp khi đó là tăng delay để gửi request lên Google từ từ hơn, kết hợp với giả lập trình duyệt hay thậm chí là mua các dịch vụ proxy để rotate IP liên tục. Như vậy là sau 1 hoặc vài tiếng ta sẽ có kết quả trả về, tốc độ như thế với nhiều người cũng đủ chấp nhận được. Tuy nhiên, nó chỉ phù hợp khi ta làm 1 ứng dụng desktop để sử dụng cá nhân và có nhiều thời gian để chờ đợi kết quả. Đối với một hệ thống kiểm tra đạo văn phục vụ nhiều người dùng thì vậy là quá chậm. Thường thì một hệ thống phải xử lý đồng thời nhiều tài liệu 1 lúc và người dùng mong muốn có kết quả nhanh nhất có thể (thường chỉ tính bằng phút). Do vậy việc sử dụng các công cụ tìm kiếm có sẵn là giải pháp không khả thi đối với một hệ thống check đạo văn nhiều người dùng.

Vì không sử dụng được công cụ tìm kiếm có sẵn nên các hệ thống kiểm tra đạo văn phải tự tay xây dựng một cái giống như vậy. Nghe có vẻ tham vọng nhưng ta bắt buộc phải làm vậy chứ mình chưa nghĩ được cách nào khác. Vậy để làm được việc đó thì ta cần phải đối mặt với các bài toán như sau:

1. Thu thập nguồn dữ liệu: Ta phải đi crawl (cào) dữ liệu từ các trang web trên internet về và lưu trữ nó lại. Việc crawl 1 trang web thì có nhiều thư viện hỗ trợ rồi, nhưng cái khó hơn ở đây là ta phải crawl những trang web nào. Bạn không đủ lớn mạnh như Google để khiến người khác chủ động vào submit sitemap mà bạn phải từ mò nó. Giải pháp mình đang dùng là thi thoảng chọn vài câu văn mà không tìm được trùng lặp rồi lên nhờ Google tìm giúp, rồi crawl cả website nếu chưa có.

2. Lưu trữ dữ liệu: Thu thập về là ta phải lưu lại ngay, nhưng vấn đề là ta phải lưu dữ liệu của toàn bộ internet về máy của mình, đơn vị tính là bằng Terabytes (1TB = 1024GB). Ví dụ riêng dữ liệu tiếng Việt khi thu thập hết sẽ ngốn ít nhất là 25TB (dữ liệu html thôi nhé, không tính video, ảnh, css,...), còn dữ liệu tiếng Anh thì cứ gấp 100 lần số trên cho dễ tính. Lúc này ta phải tìm cách tối ưu dung lượng (nén, check trùng,...) để tiết kiệm dung lượng nhiều nhất có thể.

3. Xử lý và tìm kiếm dữ liệu: Có một đống dữ liệu về là ta phải tìm cách sử dụng nó hiệu quả và tối ưu, từ việc lấy (load), phân tách nội dung (extract) và chuyển đổi (transform) vào cơ sở dữ liệu tìm kiếm. Với dữ liệu vừa và nhỏ thì ta có thể sử dụng các search engine có sẵn như Elastic Search hay Apache Solr, tuy nhiên với quy mô dữ liệu lớn thì ta phải tinh chỉnh hoặc tự dựng thuật toán nếu không muốn đốt tiền cho server. Ở mức độ cao hơn, bạn còn phải đối mặt thêm với các bài toán xử lý ngôn ngữ tự nhiên (NLP) hoặc thậm chí là AI như tính tương đồng, tách câu, phát hiện cấu trúc văn bản,...

4. Scaling: Đặc trưng của phần mềm check đạo văn là hoạt động theo mùa (ở đây là mùa khóa luận). Vào lúc cao điểm, việc có cả trăm tài liệu đồng thời cần phải xử lý là chuyện bình thường. Ta sẽ phải đối mặt với các vấn đề load balancing, flow control, failure handling,.. đến việc scale dữ liệu tìm kiếm với sharding và duplication.

Lời kết

Trên đây là môt bài viết ngắn của mình nói về các vấn đề mà ta sẽ gặp phải khi xây dựng một hệ thống kiểm tra đạo văn. Nhìn chung, việc thu thập và xử lý dữ liệu lớn là vấn đề phức tạp và quan trọng nhất của hệ thống. Phần mềm kiểm tra đạo văn mà team mình phát triển (tên là Kiểm Tra Tài Liệu) cũng mất nhiều năm để phát triển và đủ ổn định để phục vụ nhu cầu của người dùng tại Việt Nam. Tuy nhiên, với dữ liệu ngày càng lớn, người dùng càng nhiều, workload càng tăng thì các vấn đề về dữ liệu đã nói trên vẫn là bài toán chưa có hồi kết với độ khó ngày càng tăng. Hiện tại team mình đã ở giai đoạn phải tự xây thuật toán tìm kiếm riêng và sử dụng ngôn ngữ tối ưu như Rust để tăng hiệu năng và giảm chi phí máy chủ. Có một số trường đại học mạnh về IT cũng tự xây dựng riêng phần mềm check đạo văn nhưng chỉ dùng nội bộ trong trường có lẽ cũng do vấn đề dữ liệu và chi phí duy trì phát triển như bên mình gặp phải.

Do thời gian và độ dài bài viết có hạn, nên mình không đi chi tiết từng khía cạnh được. Nếu có vấn đề nào các bạn cần chi tiết hơn thì có thể bình luận để mình giải thích hoặc có thời gian viết 1 bài chi tiết hơn.

Xin trân trọng cảm ơn các bạn đã đọc bài.