Tác giả: Học Trò và Claude Sonnet 5.0 AI (Tháng 8 năm 2026).
Học Trò xin chân thành cảm ơn nhà báo Phạm Phú Minh (https://phamxuandai.blogspot.com/), Nhật Báo Người Việt tại Little Saigon, và các thiện nguyện viên phụ trách việc số hóa Tạp Chí Bách Khoa (1957-1975), để hậu thế có thể được xem lại những áng văn chương, nghệ thuật của Việt Nam Cộng Hòa trước ngày mất nước. Cũng xin thành thực cám ơn Nhóm Thực Hiện việc số hóa Tạp Chí Văn Học các bộ Cũ và Mới: Diệu Chi, Hồ Như, Trần Mộng Tú, Hoàng Hưng, Huy Văn, Nguyễn Vũ, Ngự Thuyết, Phạm Phú Minh, Phùng Nguyễn, Tràm Cà Mau, Trịnh Y Thư,và Trúc Chi.
Xem các thí dụ:
Nội Dung 426 số báo của Tạp chí Bách Khoa (1957-1975): https://hoctroviet.blogspot.com/2026/08/noi-dung-426-so-bao-cua-tap-chi-bach.html
Nội Dung các số báo của Tạp chí Văn Học / Văn Học Nghệ Thuật ở Hải Ngoại (1978 - 2008): https://hoctroviet.blogspot.com/2026/08/noi-dung-cac-so-bao-cua-tap-chi-van-hoc.html
Bài viết này không phải là một bài phân tích văn học hay âm nhạc. Đây là một ghi chép về phương pháp — về cách một công cụ AI như Claude đã giúp hoàn thành một công việc trích xuất dữ liệu quy mô lớn mà nếu làm bằng tay, gần như chắc chắn sẽ không bao giờ được làm xong. Bài viết này cũng là để minh họa cho bài viết "Đi Xa Hơn Cái Gợi Ý Tự Động (Past the Autocomplete)" https://hoctroviet.blogspot.com/2026/08/i-xa-hon-cai-goi-y-tu-ong-past.html, trong đó tôi chỉ ra rằng người viết prompts với AI giỏi không cần phải biết lập trình để tạo những sản phẩm.
Đề bài: 412 số báo (đơn và kép - hai số nhập một), một bảng mục lục duy nhất
Tạp chí Bách Khoa — một trong những tạp chí trí thức quan trọng nhất của miền Nam Việt Nam, xuất bản liên tục từ năm 1957 đến 1975 — để lại một kho lưu trữ gồm 412 file PDF, đánh số từ số 1 đến số 426 (chỉ thiếu số 86). Mỗi file là bản scan của một số báo, dày trung bình 80–100 trang, một số số đặc biệt (như số 169, kỷ niệm 7 năm) dày tới 240 trang.
Mục tiêu đặt ra rất đơn giản để nói nhưng cực kỳ tốn công để làm: đọc trang mục lục ("Trong số này") của cả 412 số báo, rồi gõ lại từng dòng — số báo, ngày tháng, tên tác giả, tựa bài, số trang — thành một bảng dữ liệu phẳng (flat table), để sau này có thể gộp lại thành một cơ sở dữ liệu tra cứu cho toàn bộ 18 năm nội dung của tạp chí. Tính đến thời điểm bài này được viết, công việc đã trích xuất được khoảng 6.486 dòng bài viết từ toàn bộ 412 số.
Vì sao đây không phải là việc "làm thì lâu hơn" mà là việc "không ai làm nổi"
Cần phải nói rõ ràng ngay từ đầu: đây không phải là trường hợp AI giúp làm nhanh hơn một việc mà con người vẫn có thể làm được nếu có đủ thời gian. Đây là trường hợp khác hẳn về bản chất.
Người có động lực và kiến thức nền để làm việc này là một cá nhân làm ngoài giờ, không lương, không có đội ngũ hỗ trợ — nói cách khác, một người tình nguyện. Với 412 file PDF, mỗi file cần: (1) tìm ra trang nào trong file chứa mục lục thật (không phải trang bìa, không phải trang quảng cáo), (2) đọc và gõ lại chính xác từng dòng chữ Việt có dấu từ một bản scan cũ, nhiều khi mờ, nhiều khi tên tác giả in theo lối viết hoa có gạch nối kiểu cũ ("THÁI-VĂN-KIỂM", "TRẦN-VĂN KHÊ"), (3) gõ vào một bảng theo đúng định dạng thống nhất.
Giả sử mỗi số báo — nếu làm cẩn thận, tính luôn thời gian tìm trang, đọc, gõ, kiểm tra lỗi chính tả có dấu — mất trung bình 15–20 phút. Nhân với 412 số, đó là từ 100 đến 140 giờ làm việc liên tục, không tính thời gian nghỉ, không tính thời gian sửa lỗi khi gõ nhầm dấu (một lỗi rất dễ xảy ra và rất khó tự phát hiện khi gõ tiếng Việt có dấu hàng giờ liền). Đối với một người làm việc này ngoài giờ rảnh, con số đó không phải là "sẽ mất nhiều thời gian" — mà thực tế là "sẽ không bao giờ được hoàn thành". Nó sẽ nằm trong danh sách những dự án "để sau", và "sau" đó, kinh nghiệm cho thấy, thường không bao giờ tới.
Đây chính là điểm quan trọng nhất của bài viết này: giá trị mà AI mang lại ở đây không được đo bằng "AI giúp tiết kiệm bao nhiêu giờ", mà nên được đo bằng khoảng cách giữa con số không (không làm gì cả, dự án nằm im vĩnh viễn) và một kết quả cụ thể tồn tại được (6.486 dòng dữ liệu đã trích xuất, có thể tra cứu). Không có công cụ này, phần lớn khả năng là công việc sẽ mãi mãi ở trạng thái "có ý định làm" chứ không bao giờ có sản phẩm thật.
Cái khó đầu tiên: trang mục lục nằm ở đâu cũng được, không hề cố định
Một trong những trở ngại tưởng nhỏ nhưng lại tốn công nhất khi làm việc này bằng tay là: trang mục lục của Bách Khoa không nằm ở một vị trí cố định trong file PDF.
Với báo chí hiện đại, ta quen với việc mục lục luôn ở trang 2 hoặc trang 3. Nhưng với Bách Khoa, qua khảo sát thực tế hàng trăm số báo, quy luật hoá ra phức tạp hơn nhiều:
- Với những số báo về sau (khoảng từ số #191 trở đi), mục lục phần lớn nằm ở trang 3.
- Với những số báo đầu (ví dụ cả loạt số ra năm 1959, số #63 đến #82), trang 3 luôn luôn chỉ là một trang quảng cáo cố định (thuốc lá, hãng Shell, ngân hàng) — không hề có mục lục ở đó. Mục lục thật lại nằm sâu hơn, có khi ở trang 7, có khi ở đâu đó trong khoảng trang 11 đến trang 20, tùy theo số báo đó có bao nhiêu trang quảng cáo chen vào trước.
- Có số còn "lệch chuẩn" theo cách rất khó đoán:
BachKhoa-088.pdfcó mục lục nằm ở trang 10, ngay phía trước ngưỡng dưới của khung tìm kiếm 11–17 — chỉ được phát hiện vì trang 11 của số đó đã hiện ra dòng chữ "Trong những số tới" (vốn luôn luôn xuất hiện ngay sau trang mục lục), khiến việc lùi lại kiểm tra một trang trước đó trở thành hợp lý. - Bìa trang 1 của một số file, ví dụ
BachKhoa-001.pdf, còn bị cắt xén vật lý ở góc phải và cạnh dưới khi scan — dòng ghi năm xuất bản ("15 THÁNG GIÊNG... 1957") bị cắt mất một phần, dòng mục lục cuối cùng trên bìa cũng bị cắt giữa chừng. Nếu tin tưởng hoàn toàn vào trang bìa, dữ liệu sẽ bị thiếu mà không ai biết.
Nếu làm bằng tay, một người sẽ phải mở từng file, lật qua lật lại nhiều trang để "dò tìm" xem mục lục nằm ở đâu cho từng số — bản thân việc dò tìm này, nhân với 412 lần, đã là một khối lượng công việc đáng kể, chưa kể đến việc đọc và gõ lại nội dung.
Với AI, việc này được giải quyết bằng một quy trình tìm kiếm có giới hạn (bounded search) được đúc kết dần qua kinh nghiệm thực tế xử lý nhiều batch đầu tiên: kiểm tra trang 3 trước; nếu không có, kiểm tra trang 7; nếu vẫn không có, kiểm tra trang 13 riêng lẻ trước (vì dữ liệu thực tế cho thấy phần lớn trường hợp còn lại rơi đúng vào trang 13); nếu vẫn chưa thấy, mới quét toàn bộ dải trang 11–17 bằng một "contact sheet" (nhiều trang thu nhỏ trong một lần nhìn); và nếu không thấy đâu cả trong toàn bộ phạm vi đó thì dừng lại, đánh dấu file đó là "chưa tìm thấy mục lục" và chuyển sang file kế tiếp, thay vì cố lục soát toàn bộ cuốn báo — vốn sẽ ngốn quá nhiều công sức so với lợi ích thu về cho một số ít trường hợp ngoại lệ.
Điều đáng nói là quy trình 3 bước "3 → 7 → 11–17" này không phải được nghĩ ra ngay từ đầu một cách hoàn hảo — nó được tinh chỉnh dần, dựa trên bằng chứng thu thập được sau mỗi đợt xử lý (ví dụ: phát hiện ra rằng bắt đầu từ khoảng số #191, mục lục chủ yếu nằm ở trang 3, nên bước kiểm tra trang 3 trước mới được đưa lên đầu). Đây chính là kiểu học hỏi lặp đi lặp lại (iterative refinement) mà một quy trình làm việc với AI cho phép — mỗi lần xử lý xong một loạt file, quy tắc tìm kiếm lại được cập nhật cho lần sau, thay vì phải giữ nguyên một quy tắc cứng nhắc từ đầu đến cuối.
Cái khó thứ hai: chuyển ảnh scan thành ảnh máy đọc được
Bước đầu tiên trong việc đọc một trang PDF là biến trang đó — vốn chỉ là một trang trong một file PDF lớn — thành một file ảnh (PNG) riêng lẻ, đủ độ phân giải để đọc được chữ. Đây là bước tưởng chừng đơn giản nhưng, nếu làm thủ công, lại là một công đoạn cực kỳ máy móc và tốn thời gian: mở từng file PDF, xác định đúng số trang cần trích, xuất trang đó ra ảnh riêng, đặt tên file, lưu vào đúng thư mục — lặp lại việc này hàng trăm, có khi hàng nghìn lần (vì nhiều số phải thử 2, 3 trang trước khi tìm đúng trang mục lục).
Với AI, bước này được tự động hoá hoàn toàn: Claude tự "rasterize" (chuyển từ định dạng vector/PDF sang ảnh bitmap) đúng trang cần thiết ở độ phân giải cao (thường là 400 DPI — đủ để đọc được cả những dấu thanh tiếng Việt nhỏ và mờ), theo đúng thứ tự tìm kiếm đã mô tả ở trên, mà không cần người dùng phải tự tay thao tác qua bất kỳ phần mềm đọc/xuất PDF nào. Đối với 412 file, việc rasterize là một thao tác diễn ra hoàn toàn ở "hậu trường" của quy trình, người dùng không cần can thiệp.
Cái khó thứ ba: đọc chữ Việt có dấu từ bản scan cũ
Đây có lẽ là bước mà nhiều người sẽ nghi ngờ nhất về khả năng của máy: liệu một công cụ AI có đọc chính xác được chữ Quốc ngữ có đầy đủ dấu thanh (sắc, huyền, hỏi, ngã, nặng) từ một bản scan báo in từ những năm 1957–1975 hay không?
Kết quả thực tế cho thấy chất lượng nhận dạng chữ (OCR) của công cụ này ở mức rất cao. Không chỉ đọc đúng chữ cái La-tinh, công cụ còn nhận diện chính xác các dấu thanh tiếng Việt — vốn là điểm yếu truyền thống của phần lớn công cụ OCR thông thường (vốn được huấn luyện chủ yếu cho tiếng Anh hoặc các ngôn ngữ không dấu). Ví dụ, những tên tác giả với lối viết hoa có gạch nối đặc trưng của báo chí thời kỳ đó — "HOÀNG-MINH-TUYNH", "NGUYỄN-PHÚC-SA", "BÙI-KHÁNH-ĐẢN" — đều được đọc và gõ lại chính xác, giữ đúng cả gạch nối lẫn dấu thanh.
Điều quan trọng không kém là công cụ này biết tự nghi ngờ chính mình. Khi gặp một chữ mà dấu thanh không rõ ràng ở độ phân giải hiện có — ví dụ trường hợp tên "THÁI-VĂN-KIỂM" ở số báo 90, nơi dấu thanh đọc ra như một dấu huyền trơn dù thực tế phải là một cách viết khác, được nhận ra là tên thật của sử gia Thái Văn Kiểm — công cụ vẫn ghi lại theo cách đọc đã được xác thực rộng rãi, nhưng đánh dấu bằng ký hiệu † để báo cho người đọc biết đây là một điểm cần lưu ý, không phải là một khẳng định chắc chắn tuyệt đối. Cách làm này — thà đánh dấu "không chắc" còn hơn là bịa ra một câu trả lời trông có vẻ chắc chắn — chính là điều giúp bảng dữ liệu cuối cùng đáng tin cậy: người dùng biết chính xác chỗ nào cần xem lại bằng mắt thật, thay vì phải nghi ngờ toàn bộ bảng.
Cái khó thứ tư: từ bản ghi thô đến bảng dữ liệu có cấu trúc — không cần viết một dòng code nào
Đây là điểm mà nhiều người làm công việc trích xuất dữ liệu truyền thống sẽ ngạc nhiên nhất. Thông thường, khi nói đến việc "trích xuất dữ liệu từ hàng trăm file rồi đưa vào bảng", người ta sẽ nghĩ ngay đến việc phải viết mã (code) — một kịch bản Python để phân tích cú pháp (parse) văn bản, một kịch bản khác để chuyển đổi định dạng, một kịch bản thứ ba để tổng hợp (aggregate) mọi thứ lại.
Trong dự án này, tác giả (người dùng) không hề phải viết một dòng code Python nào. Vai trò của tác giả chỉ là đưa ra quyết định về mặt nội dung — chẳng hạn: một dòng trong bảng nên gồm những cột gì (Số báo, Ngày tháng, Tác giả, Tựa bài, Trang, Nguồn PDF); trường hợp nào nên bị loại khỏi bảng (ví dụ: các mục mang tính hành chính của toà soạn như "Lá thư tòa soạn", "Thay lời phi-lộ", nơi "tác giả" ghi là chính tờ báo chứ không phải một người viết thật, thì không tính là nội dung đóng góp và bị loại ra — trong khi một độc giả ký tên thật hoặc ký "MỘT BẠN ĐỌC" gửi thư vẫn được giữ lại, vì đó là nội dung đóng góp thật sự); cột nào cần thêm vào khi phát hiện một nhu cầu mới (ví dụ cột "Chủ đề đặc biệt" được bổ sung sau khi nhận ra một số Xuân hay số kỷ niệm có chủ đề riêng không có chỗ nào để ghi).
Sau khi những quyết định về nội dung đó được nêu ra, chính AI là bên viết các đoạn kịch bản cần thiết (ví dụ một công cụ nhỏ tên build_cumulative.py để gộp toàn bộ các file mục lục riêng lẻ theo từng số báo thành một bảng tổng hợp duy nhất, và một công cụ chuyển đổi Markdown sang HTML để có thể xem bảng đó đẹp mắt trên trình duyệt) — tác giả chỉ cần mô tả bằng lời điều mình muốn, còn việc hiện thực hoá bằng mã máy hoàn toàn do AI đảm nhận. Nói cách khác, rào cản kỹ thuật (phải biết lập trình) mà trước đây từng ngăn cản rất nhiều người không có nền tảng lập trình khỏi việc tự làm những dự án dữ liệu quy mô lớn, gần như đã biến mất.
Quy trình lưu trữ cũng được thiết kế để không bao giờ mất công đã làm: mỗi file PDF, sau khi xử lý xong, được ghi ngay thành một file Markdown riêng (BachKhoa_TOC_Issue<số>.md), rồi bảng tổng hợp được dựng lại ngay lập tức từ toàn bộ các file riêng lẻ đó. Nhờ vậy, công việc có thể dừng giữa chừng bất cứ lúc nào — sau một file, sau vài file — mà không sợ mất dữ liệu đã trích xuất, và có thể tiếp tục lại vào một phiên làm việc khác mà không phải làm lại từ đầu. Với một dự án tình nguyện, làm rải rác qua nhiều ngày nhiều tuần, tính chất "không sợ mất việc đã làm" này quan trọng không kém gì tốc độ xử lý.
Cái khó thứ năm: tự nhận ra một quy luật ẩn và áp dụng nó cho toàn bộ 412 số
Có lẽ ví dụ rõ ràng nhất cho thấy công cụ này không chỉ "làm theo lệnh" mà còn biết "suy luận và áp dụng" là cách xử lý đường dẫn tới bản scan gốc trên mạng.
Toàn bộ 412 số báo Bách Khoa đã được số hoá và đăng công khai trên kho lưu trữ issuu của Người Việt Thư Viện. Nhưng trang chủ của kho lưu trữ đó lại nằm sau một lớp kiểm tra chống robot (Cloudflare bot-challenge), nên không thể tự động dò quét toàn bộ danh sách đường dẫn từ trang đó. Điều duy nhất có sẵn là: khi xem thử vài đường dẫn mẫu (ví dụ của số #1, số #30, số #392), một quy luật đặt tên hiện ra rõ ràng — mỗi đường dẫn có dạng:
https://issuu.com/nvthuvien/docs/bachkhoa-NNN?mode=window&viewMode=doublePagtrong đó NNN chính là số báo, viết dạng ba chữ số có số 0 đứng trước nếu cần (ví dụ số 1 viết là bachkhoa-001).
Chỉ với ba ví dụ quan sát được, quy luật này đã được nhận diện và áp dụng ngay cho toàn bộ 412 file: lấy tên file nguồn (BachKhoa-NNN.pdf), bỏ đuôi .pdf, chuyển thành chữ thường, rồi ghép vào đúng khuôn mẫu đường dẫn ở trên — biến cột "Nguồn PDF" của mỗi dòng trong bảng thành một đường dẫn có thể bấm vào để xem trực tiếp trang gốc của số báo đó trên issuu. Với các số báo gộp đôi (ví dụ số 25-26 gộp chung một file), quy luật cũng được áp dụng tương tự (bachkhoa-025-026), dù trường hợp này chưa được xác nhận trực tiếp và được đánh dấu cần kiểm tra lại nếu đường dẫn không mở được.
Việc "nhìn ba ví dụ, suy ra một khuôn mẫu áp dụng cho hàng trăm trường hợp còn lại" chính xác là kiểu công việc mà một con người vốn cũng làm được — nhưng làm thủ công nghĩa là phải tự tay chỉnh sửa hoặc tính toán 412 đường dẫn khác nhau, dò từng cái một xem có đúng khuôn mẫu không. Ở đây, việc đó diễn ra như một hệ quả tự nhiên của việc mô tả quy luật một lần cho AI, rồi để công cụ áp dụng đồng loạt cho toàn bộ dữ liệu.
Kết quả cụ thể
Tính đến khi bài viết này được soạn, dự án đã hoàn tất toàn bộ 412/412 file PDF, chia thành 65 đợt (batch) xử lý, cho ra 6.486 dòng dữ liệu bài viết — mỗi dòng gồm số báo, ngày tháng phát hành, tên tác giả, tựa bài, số trang, và đường dẫn tới bản scan gốc. Số báo cuối cùng của tạp chí (số 426) được ghi nhận là phát hành khoảng ngày 15 tháng 4 năm 1975 — giữa đúng những ngày cuối cùng trước khi miền Nam Việt Nam sụp đổ, một chi tiết mà bảng dữ liệu này tình cờ giữ lại được như một dấu mốc lịch sử.
Toàn bộ khối lượng này được xử lý qua nhiều phiên làm việc rải rác, mỗi phiên chỉ xử lý một đợt nhỏ (ban đầu 20 file một đợt, sau đó rút xuống 5 file, rồi tăng dần lên 10 file một đợt khi kinh nghiệm cho thấy có thể xử lý nhanh hơn dự tính) — đúng với nhịp độ làm việc thực tế của một người tình nguyện làm việc này ngoài giờ rảnh, không phải một dự án có đội ngũ toàn thời gian đứng sau.
Kết luận: không phải là "nhanh hơn", mà là "có thể làm được"
Điều đáng nhấn mạnh lại một lần nữa ở phần kết: giá trị thực sự của AI trong dự án này không nằm ở việc nó giúp một công việc vốn có thể làm được diễn ra nhanh hơn vài lần. Giá trị nằm ở chỗ nó đã biến một công việc vốn nằm ngoài khả năng thực tế của một cá nhân — vì đòi hỏi hàng trăm giờ đọc chữ có dấu từ bản scan cũ, hàng trăm lần dò tìm trang mục lục ở những vị trí không cố định, và (nếu làm theo cách truyền thống) một khối lượng lập trình không nhỏ để xử lý và tổng hợp dữ liệu — thành một công việc có thể hoàn thành trong vài chục phiên làm việc ngắn, rải rác qua nhiều tuần, không cần biết lập trình, không cần một đội ngũ hỗ trợ.
Nói cách khác: phép so sánh đúng ở đây không phải là "10 giờ so với 2 giờ", mà là "không bao giờ có so với đang tồn tại". Một bảng 6.486 dòng dữ liệu, phủ kín 18 năm nội dung của một tạp chí trí thức quan trọng của miền Nam Việt Nam, giờ đây đã tồn tại và có thể tra cứu được — điều mà, nếu không có công cụ này, gần như chắc chắn sẽ mãi mãi chỉ là một ý định tốt, nằm im trong một thư mục PDF không ai có đủ thời gian mở ra đọc hết.