Khi việc trích xuất LLM không còn bù đắp được chi phí

Khi việc trích xuất LLM không còn bù đắp được chi phí

Firecrawl tính 1 credit để scrape một trang và 5 credit để trích xuất các trường dữ liệu có cấu trúc từ cùng một trang đó (Firecrawl pricing, 2026). Đó là mức giá tăng gấp 5 lần cho cùng một đoạn HTML được gửi qua model.

Lời chào mời rất thực 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 layout không ổn định và các mục tiêu chỉ dùng một lần, nó xứng đáng với mức giá đó. Nhưng đối với một pipeline production kéo 500 nghìn trang sản phẩm mỗi ngày từ cùng năm nhà bán lẻ, thì không.

Chúng tôi đã chứng kiến các team triển khai trích xuất mặc định bằng LLM, nhận hóa đơn cuối tháng, và bắt đầu tìm cách thoát ra. Cách giải quyết thường không phải là loại 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ệ

Lấy Firecrawl ở mức giá rẻ làm ví dụ. Scrape cộng với trích xuất bằng AI tốn 6 credit mỗi trang nếu không crawl, 7 credit nếu có crawl (ScrapeGraphAI breakdown, 2026). 100 nghìn trang mỗi ngày trên gói growth của họ tiêu tốn khoảng 21.000 đô la mỗi tháng trước khi tính phí retry, và trước khi bạn phải trả cho một proxy nào.

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

Đó là model rẻ. Chuyển sang Claude Sonnet 4.6 (3 đô la input, 15 đô la output) và hóa đơn sẽ tăng gấp đôi (PE Collective, 2026). Chuyển sang một reasoning model và bạn sẽ phải chịu thêm mức phạt gấp 3-10 lần tùy thuộc vào việc nó suy nghĩ bao nhiêu trước khi trả lời.

Những con số đó chưa tính đến các trường hợp thất bại. Tỷ lệ ảo giác 3-5% nghe có vẻ vô hại cho đến khi bạn làm phép tính. Với 100 nghìn trang mỗi ngày, đó là 3.000-5.000 bản ghi sai chảy vào kho dữ liệu của bạn, trông hoàn toàn giống hệt những bản ghi đúng vì model trả về chúng một cách tự tin. Như DataHen đã nói: "Không phải là AI thỉnh thoảng mắc sai lầm. Mà là nó mắc sai lầm một cách rất tự tin." (DataHen, 2026).

Các team có kinh nghiệm thực sự làm gì

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

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

Vì vậy, sự phân chia trong production diễn ra như sau:

• LLM tạo ra selector (một lệnh gọi cho mỗi target, tốn chưa đến một xu)
• Selector chạy trên mọi trang (miễn phí)
• Một trình xác thực (thường là regex hoặc kiểm tra sự tồn tại) bắt lỗi sai lệch
• Lỗi sai lệch kích hoạt việc tạo lại selector, vài tuần hoặc vài tháng sau đó

Chi phí mỗi trang giảm mạnh từ khoảng 0,005 đô la xuống thấp hơn nhiều so với mức 0,0001 đô la. Chất lượng tăng lên vì quá trình parse xác định không bị ảo giác. Và bạn tiêu tốn token vào những công việc mà LLM thực sự giỏi: đọc cấu trúc mới, chứ không phải lặp lại như vẹt cấu trúc mà bạn đã ánh xạ.

Dù sao thì LLM vẫn đáng giá ở những điểm nào

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

• Các layout không ổn định thay đổi hàng tuần. Các selector bị hỏng vào mỗi thứ Ba tiêu tốn thời gian của kỹ sư nhiều hơn chi phí token trích xuất LLM. Hãy chạy model.
• Các target ở phân khúc đuôi dài (long-tail) mà bạn không bao giờ ghé thăm lần thứ hai. Không có lợi ích gì khi viết selector. Hãy chạy model.
• Nội dung phi cấu trúc nơi chính output là một bản tóm tắt. Chuyển mô tả công việc thành các kỹ năng, bài viết thành các luận điểm, đánh giá thành phân tích cảm xúc. Các selector không thể giúp ích. Hãy chạy model.
• Các trang có những trường tùy chọn rải rác trên các biến thể layout. Một template duy nhất với hai mươi điều kiện render là nơi chính xác mà LLM đánh bại các chuỗi regex.

Hãy nhìn vào pipeline của bạn. Sắp xếp các target theo khối lượng. Nhóm 20% có số lượng request cao nhất gần 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 đã chủ động tích hợp chúng). Chúng là những ứng cử viên lý tưởng cho selector. Phần đuôi dài là nơi model phát huy tác dụng.

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

Lời quảng cáo của nhà cung cấp vào năm 2026 muốn bạn mặc định sử dụng trích xuất LLM. Việc tính giá bằng credit làm cho đ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ô, giống như cách kích thước proxy pool ngừng dự đoán thành công thực sự một khi tín hiệu cơ bản bị phá vỡ.

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

1. Tách biệt việc fetch và parse. Nếu nhà cung cấp scraping 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 selector khi nhận được hóa đơ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 lộ trình trích xuất.
2. Tích cực cache ở cấp độ selector. Các selector được tạo ra có thể tái sử dụng qua hàng nghìn trang. Lệnh gọi tốn kém là quá trình tạo, chứ không phải quá trình sử dụng.
3. Đo lường chi phí trên mỗi bản ghi, không phải trên mỗi trang. Một pipeline có giá 0,001 đô la/trang nhưng tạo ra 5% bản ghi xấu sẽ tốn kém hơn một pipeline có giá 0,005 đô la/trang và cung cấp dữ liệu sạch. Storage, các truy vấn downstream và việc dọn dẹp sau cùng đều đóng vai trò quan trọng.

Hãy chọn phương pháp nhàm chán hơn

Mặc định sử dụng trích xuất LLM là mô hình phù hợp cho một bản demo và sai lầm đối với production. Những team làm đúng là những team coi LLM như một công cụ để hiểu một trang, chứ không phải công cụ để đọc một trang. Code xác định nhàm chán vẫn chiến thắng trong bài toán số lượng vào năm 2026; model giành chiến thắng trong tính mới mẻ. Cả hai đều có vị trí trong stack.

Tại FourA, Single và Browser trả về response thô (HTML, DOM đã render, headers, body) và dừng lại ở đó. Việc bạn parse bằng các selector, gửi nó đến một model, hay làm cả hai, đó là quyết định của bạn. Chúng tôi không cộng 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.