Khi việc trích xuất bằng LLM không còn mang lại hiệu quả kinh tế

Khi việc trích xuất bằng LLM không còn mang lại hiệu quả kinh tế

Firecrawl tính phí 1 credit để cào một trang và 5 credit để trích xuất các trường có cấu trúc từ chính trang đó (bảng giá Firecrawl, 2026). Đó là mức giá tăng gấp 5 lần cho cùng một mã HTML được gửi qua một mô hình.

Lời quảng cáo là có thật: mô tả những gì bạn muốn, nhận lại JSON, không cần duy trì các selector. Đối với các bố cục không ổn định và các mục tiêu thu thập một lần, nó hoàn toàn xứng đáng với mức phí tăng thêm đó. Nhưng đối với pipeline production thu thập 500K trang sản phẩm mỗi ngày từ cùng năm nhà bán lẻ, nó không còn hiệu quả nữa.

Chúng tôi đã chứng kiến nhiều đội ngũ triển khai việc trích xuất mặc định bằng LLM, nhận hóa đơn vào cuối tháng, và bắt đầu tìm lối thoát. Giải pháp thường không phải là từ bỏ LLM. Mà là đặt chúng vào đúng vị trí trong pipeline.

Bài toán chi phí nhanh chóng trở nên tồi tệ

Hãy lấy Firecrawl ở phân khúc giá rẻ làm ví dụ. Cào dữ liệu cộng với trích xuất bằng AI là 6 credit cho mỗi trang không có crawl, 7 credit nếu có crawl (phân tích từ ScrapeGraphAI, 2026). Với 100K trang mỗi ngày trên gói growth của họ, chi phí sẽ rơi vào khoảng 21.000 USD mỗi tháng trước khi tính đến các lượt thử lại (retry), và trước khi bạn phải trả tiền cho bất kỳ proxy nào.

Tự vận hành pipeline LLM của riêng bạn và bài toán chi phí sẽ thay đổi nhưng con số vẫn không hề nhỏ. GPT-4o có giá 2,50 USD cho mỗi triệu input token và 10 USD cho mỗi triệu output token (PricePerToken, 2026). Một trang sản phẩm sau khi chuyển đổi sang markdown sẽ tốn khoảng 4K-8K input token. Giả sử là 6K input, 200 output cho một khối JSON. Với 100K trang mỗi ngày, chi phí sẽ là 360 USD hàng ngày, tương đương 11.000 USD hàng tháng cho một công việc mà các CSS selector có thể thực hiện miễn phí sau một lần thiết lập.

Đó là với mô hình giá rẻ. Chuyển sang Claude Sonnet 4.6 (3 USD input, 15 USD output) và hóa đơn sẽ tăng gấp đôi (PE Collective, 2026). Chuyển sang một mô hình suy luận (reasoning model) và bạn sẽ phải gánh thêm mức phạt chi phí gấp 3-10 lần tùy thuộc vào mức độ suy nghĩ của nó trước khi trả lời.

Tất cả những điều đó còn chưa tính đến các lỗi thất bại. Tỷ lệ ảo tưởng (hallucination) từ 3-5% nghe có vẻ vô hại cho đến khi bạn làm phép tính thực tế. Với 100K trang mỗi ngày, điều đó đồng nghĩa với việc có 3.000-5.000 bản ghi sai lệch chảy vào kho dữ liệu (warehouse) của bạn, trông hoàn toàn giống như các bản ghi chính xác vì mô hình trả về chúng một cách đầy tự tin. Như DataHen đã nhận định: "Vấn đề không phải là đôi khi AI đưa ra kết quả sai. Mà là nó đưa ra kết quả sai một cách đầy tự tin." (DataHen, 2026).

Những gì các đội ngũ giàu kinh nghiệm thực sự làm

Đọc tài liệu từ các nhà cung cấp thực sự vận hành scraper trong môi trường production và bạn sẽ thấy một mô hình nhất quán: hybrid (lai). Sử dụng LLM để phân tích trang một lần, sau đó chạy mã xác định (deterministic code) giá rẻ cho tất cả các bước tiếp theo.

Zyte đã giải thích rõ ràng trong tài liệu của họ: "Thay vì sử dụng LLM cho từng trang, hãy sử dụng LLM của bạn để tạo các CSS selector cho các trường mong muốn dựa trên mã HTML thô của trang đầu tiên, và sử dụng các selector đó để parse tất cả các trang khác." (hướng dẫn LLM của Zyte, 2026). Apify cũng đề xuất quy trình tương tự trong hướng dẫn năm 2026 của họ: thử các CSS selector trước, và chỉ chuyển hướng sang LLM khi chúng thất bại (hướng dẫn năm 2026 của Apify). Một bài viết trên DEV Community về việc triển khai thực tế trong môi trường production đã mô tả chính xác kiến trúc này: đường dẫn selector được cache không tốn chi phí, LLM chỉ kích hoạt khi quá trình xác thực (validation) thất bại (DEV.to, 2026).

Vì vậy, mô hình phân chia trong production sẽ trông như thế này:

• LLM khởi tạo (bootstrap) selector (một cuộc gọi cho mỗi mục tiêu, chi phí chỉ bằng một phần nhỏ của một cent)
• Selector chạy trên mọi trang (miễn phí)
• Một bộ xác thực (validator, thường là regex hoặc kiểm tra sự tồn tại) sẽ phát hiện sự thay đổi cấu trúc (drift)
• Sự thay đổi cấu trúc (drift) sẽ kích hoạt việc khởi tạo lại (re-bootstrap) sau vài tuần hoặc vài tháng

Chi phí cho mỗi trang giảm mạnh từ khoảng 0,005 USD xuống dưới 0,0001 USD. Chất lượng tăng lên vì việc parse xác định (deterministic parsing) không bị ảo tưởng. Và bạn chỉ chi tiêu token cho những công việc mà LLM thực sự giỏi: đọc các cấu trúc mới lạ, chứ không phải lặp lại một cấu trúc mà bạn đã lập bản đồ sẵn.

Những trường hợp LLM thực sự xứng đáng với chi phí

Đây không phải là một bài viết phản đối LLM. Có rất nhiều tác vụ trích xuất mà mô hình chính là công cụ phù hợp và bài toán chi phí credit hoàn toàn hợp lý:

• Các bố cục không ổn định thay đổi hàng tuần. Các selector bị hỏng vào mỗi thứ Ba hàng tuần sẽ tiêu tốn nhiều thời gian của kỹ sư hơn là chi phí token cho việc trích xuất bằng LLM. Hãy chạy mô hình.
• Các mục tiêu đuôi dài (long-tail) mà bạn sẽ không bao giờ truy cập lại lần thứ hai. Không có lợi ích gì khi viết một selector. Hãy chạy mô hình.
• Nội dung không có cấu trúc mà bản thân đầu ra là một bản tóm tắt. Từ mô tả công việc sang kỹ năng, từ bài viết sang các tuyên bố, từ đánh giá sang phân tích sắc thái (sentiment). Các selector không thể giúp ích gì. Hãy chạy mô hình.
• Các trang có các trường tùy chọn nằm rải rác trên các biến thể bố cục khác nhau. Một template duy nhất với hai mươi điều kiện render chính là nơi LLM vượt trội hơn hẳn so với các chuỗi regex.

Hãy nhìn vào pipeline của bạn. Sắp xếp các mục tiêu theo lưu lượng. Nhóm 20% dẫn đầu về số lượng request hầu như luôn có cấu trúc ổn định (đó là lý do tại sao chúng nằm trong top 20% — bạn đã tích hợp chúng một cách có chủ đích). Chúng là những ứng viên phù hợp cho selector. Nhóm đuôi dài (long tail) mới là nơi mô hình thuộc về.

Điều này có ý nghĩa gì đối với stack của bạn

Lời chào mời từ các nhà cung cấp vào năm 2026 muốn bạn mặc định sử dụng việc trích xuất bằng LLM. Cách tính phí theo credit khiến điều đó có vẻ hợp lý đối với các dự án nhỏ. Nhưng nó sẽ không còn hợp lý khi bạn mở rộng quy mô, tương tự như cách quy mô proxy pool không còn là yếu tố dự báo thành công thực tế một khi tín hiệu cốt lõi bị phá vỡ.

Ba bài học rút ra cho các đội ngũ đang xây dựng các pipeline thực tế:

1. Tách biệt quá trình tải (fetch) và parse. Nếu nhà cung cấp dịch vụ cào dữ liệu của bạn chỉ trả về JSON được trích xuất bằng LLM, bạn sẽ không thể quay lại sử dụng các selector khi hóa đơn gửi đến. Hãy chọn cơ sở hạ tầng cung cấp cho bạn HTML và cho phép bạn tự chọn phương thức trích xuất.
2. Cache mạnh mẽ ở cấp độ selector. Các selector được tạo ra có thể tái sử dụng trên hàng ngàn trang. Cuộc gọi tốn kém là bước tạo ra selector, chứ không phải bước sử dụng.
3. Đo lường chi phí trên mỗi bản ghi, chứ không phải trên mỗi trang. Một pipeline có chi phí 0,001 USD/trang nhưng chuyển đi 5% bản ghi hỏng sẽ tốn kém hơn một pipeline có chi phí 0,005 USD/trang nhưng cung cấp dữ liệu sạch. Chi phí lưu trữ, các truy vấn hạ nguồn (downstream query), và việc dọn dẹp dữ liệu sau đó đều là những gánh nặng tài chính.

Chọn phần tẻ nhạt hơn

Việc mặc định trích xuất bằng LLM là mô hình phù hợp cho một bản demo nhưng lại sai lầm cho môi trường production. Những đội ngũ đang đi đúng hướng là những người coi LLM như một công cụ để hiểu một trang, chứ không phải một công cụ để đọc một trang. Mã xác định (deterministic code) tẻ nhạt vẫn chiến thắng trong bài toán về lưu lượng vào năm 2026; mô hình chỉ chiến thắng trong bài toán về tính mới lạ. Cả hai đều có vị trí riêng trong stack.

Tại FourA, Single và Browser trả lại response thô (HTML, DOM đã render, các header, body) và dừng lại ở đó. Việc bạn parse bằng các selector, gửi nó đến một mô hình, hay thực hiện cả hai, hoàn toàn là quyết định của bạn. Chúng tôi không tính thêm hệ số nhân credit cho việc trích xuất mà chúng tôi không thực hiện.