Bài viết này sẽ mô tả giúp bạn chi tiết hơn về cách hoạt động của các phần mềm kiểm tra đạo văn như KiemTraTaiLieu, DoIT, Turnitin,…

Khái quát bài toán

Đầu tiên, để hiểu được các hệ thống hoạt động, hãy tổng quát lại bài toán mà chúng ta cần giải quyết như sau: Người dùng gửi lên hệ thống một văn bản (dưới dạng file, hay nội dung chữ), hệ thống tiếp nhận, xử lý tìm kiếm các đoạn văn trùng với nguồn dữ liệu internet hoặc nguồn dữ liệu riêng của hệ thống và trả lại kết quả cho người dùng.

Sau khi đọc bài toán, ta cũng có thể suy ra được những bước mà hệ thống cần phải giải quyết:
Bước 1: Tiền xử lý dữ liệu: tiếp nhận văn bản, tài liệu người dùng gửi lên và trích xuất nội dung từ đó
Bước 2: Kiểm tra, đối chiếu trùng lặp: Đối chiếu, so sánh từng đoạn nội dung với nguồn dữ liệu
Bước 3: Tổng hợp kết quả: Tổng hợp lại kết quả để hiển thị cho người dùng.

Tuy chỉ đơn giản là 3 bước, nhưng để xử lý từng bước một, là hàng loạt các bài toán nhỏ nhưng mà có võ để để xử lý, cụ thể

Bước 1: Tiền xử lý dữ liệu

Để kiểm tra trùng lặp của một nội dung, một tài liệu thì bắt buộc chúng ta phải có nội dung cần kiểm tra, tuy nhiên dữ liệu đầu vào của từng người dùng là khác nhau. Hiện nay hầu hết các hệ thống đều hỗ trợ cho phép người dùng tải lên toàn bộ tài liệu dưới dạng doc, docx, pdf. Do đó hệ thống đầu tiên phải trích xuất được nội dung từ tài liệu thành nội dung text (chỉ có chữ). Các thư viện hỗ trợ việc này khá là nhiều, do đó việc này nghe có vẻ tương đối dễ giải quyết. Tuy nhiên, vấn đề khó ở bước này là phải chuẩn bị dữ liệu để các bước sau có thể sử dụng được, cụ thể:

Để kiểm tra được trùng lặp, hệ thống phải đối chiếu từng đoạn nội dung với nguồn dữ liệu, đoạn nội dung ở đây sẽ tùy theo chiến lược xử lý của từng hệ thống, ví dụ Turnitin là chuỗi các từ liên tiếp nhau không quan tâm có cùng một câu hay không, còn DoIT với KiemTraTaiLieu sử dụng là câu văn. Do đó ở bước tiền xử lý này, từ một nội dung toàn bộ văn bản, ta phải tách làm sao cho chính xác nhất. Ví dụ, để tách câu, không thể dùng dấu chấm để tách được vì có trường hợp từ viết tắt có dấu chấm (ví dụ Dr., Mr., U.S,…) hoặc các tiêu đề hay liệt kê thì lại không. Sẽ có rất nhiều trường hợp nghách cần xử lý.

Để hiển thị được kết quả trực quan nhất, làm sao để người dùng có được trải nghiệm giống như đang xem văn bản gốc, biết được chính xác đoạn trùng lặp này ở đoạn nào, trang nào, có thể tương tác để xem chi tiết từng đoạn nội dung hoặc lọc kết quả. Để đáp ứng được việc này thì cần phải lưu trữ thật kéo các thông tin metadata trong quá trình trích xuất để bước tổng hợp kết quả có thể sử dụng.

Bước 2: Kiểm tra, đối chiếu trùng lặp

Sau khi đã có nội dung được trích xuất từ bước 1, ta phải so sánh từng đoạn văn với cơ sở dữ liệu tìm kiếm của hệ thống. Bài toán khó ở đây là dữ liệu internet khá là lớn, được tính bằng TB dữ liệu (Terabytes, 1 TB = 1024 GB) và một tài liệu luận văn thường trung bình khoảng 1500 câu văn. Vậy để hoàn thành việc kiểm tra trong 1 phút, với mỗi giây ta phải tìm kiếm được 25 câu văn trên hàng TB dữ liệu (hoặc chia ra thì trung bình là mỗi câu văn phải xử lý trong vòng 40 ms, một con số rất nhỏ). Để so sánh, hãy thử dùng File Explorer hay một trình quản lý file của bạn, rồi tìm kiếm một vài từ để tìm file chứa những từ đó, một ổ đĩa có 100GB lúc đó cũng phải mất vài giây (nếu là ổ cứng thể rắn SSD, còn nếu ổ cứng HDD thì cũng mất gấp 2-3 lần).

Công nghệ tìm kiếm tương đối full-text search là giải pháp phù hợp để xử lý vấn đề này. Đây là công nghệ tối ưu cho việc tìm kiếm giống như tìm kiếm trên Google và Facebook, các kết quả trả về không cần chính xác tuyệt đối mà chỉ cần một vài từ trùng hay có nghĩa tương đồng là được. Các cái tên lớn của công nghệ này bao gồm Elastic Search, Solr,… Tuy nhiên, khi KiemTraTaiLieu chạy thực nghiệm, thì công nghệ này chưa đủ đáp ứng nhu cầu, hiệu năng không đáp ứng được nhu cầu kiểm tra những câu văn dài và tần suất liên tục, cũng như chi phí quá lớn. Do đó, KiemTraTaiLieu phải tự thiết kế lại dựa trên những kỹ thuật của công nghệ có sẵn, và khả năng cao các hệ thống KiemTraTaiLieu cũng sẽ phải đối đầu bài toán tương tự.

Một hướng xử lý khác là sử dụng công cụ tìm kiếm Google, tức là đem từng câu lên Google kiểm tra và lấy kết quả từ đó. Cách này sẽ không phải tốn hạ tầng để lưu trữ lượng dữ liệu lớn, cũng như không mất nhiều công lập trình. Tuy nhiên, thực tế là Google không cung cấp API để có thể truy cập (miễn phí lẫn trả phí), và Google sẽ sử dụng captcha để phát hiện truy cập không phải là từ con người, hệ thống sẽ bị chặn bằng captcha chỉ sau vài chục câu tìm kiếm. Do đó, hướng xử lý này không thể áp dụng vào thực tế được.

Do phải xử lý lượng lớn dữ liệu như thế, các hệ thống thường có những giới hạn với người dùng (ví dụ Turnitin chỉ bán cho các đơn vị, không bán cá nhân và có giới hạn cho tài khoản sinh viên; DoIT thì hạn chế số lượt).

Bước 3: Tổng hợp kết quả

Kết quả hiển thị cần được thể hiện trực quan nhất, người dùng có thể tương tác được với giao diện kiểm tra hoặc xuất báo cáo kết quả. Kỹ thuật này mỗi hệ thống xử lý theo những hướng khác nhau và thiên về UI/UX nhiều hơn, do đó chúng ta sẽ không đi sâu vào vấn đề này.

Kết: Bài viết này khái quát một cách cơ bản nhất cách thức hoạt động của một hệ thống kiểm tra đạo văn nói chung. Nhìn chung, xây dựng lên hệ thống cần phải xử lý nhiều vấn đề lớn nhỏ khác nhau, nhưng vấn đề lớn trong hệ thống này là xử lý một lượng dữ liệu lớn trong một thời gian ngắn. Bên cạnh đó, vấn đề thu thập dữ liệu cũng là một bài toán khá phức tạp không kém.

Related Posts