Xây dựng một Bước Khám Phá Nguồn cho Trợ Lý Nghiên Cứu AI

TL;DR:

• Một API Tìm kiếm Google cho các tác nhân AI cung cấp ứng viên nguồn. URL kết quả và đoạn trích là dữ liệu khám phá, không phải bằng chứng đã được xác minh cho một câu trả lời.
• Xây dựng một sự chuyển giao rõ ràng. Giữ bối cảnh truy vấn, các định danh của ứng viên, lý do chọn lựa, và trạng thái truy xuất để các trích dẫn có thể quay lại nội dung đã được xem xét.
• Bắt đầu với một bộ điều hợp địa phương. Chương trình bên dưới biến đổi một bản chụp đã lưu thành hàng đợi xem xét; việc thu thập được xác thực và truy xuất toàn văn vẫn là những yêu cầu riêng biệt.

Một trợ lý nghiên cứu AI có thể trả về một đoạn văn thuyết phục với danh sách các URL trong khi vẫn để một câu hỏi cơ bản không được trả lời: trang nào thực sự hỗ trợ mỗi câu? Việc chỉ thêm tìm kiếm không giải quyết được vấn đề đó. Quy trình làm việc cần phân biệt việc khám phá một đích đến với việc đọc nó và sử dụng nó làm bằng chứng.

API Tìm kiếm Google không scrapeless phù hợp với bước khám phá nguồn. Hướng dẫn này cho thấy cách sử dụng một API Tìm kiếm Google cho các tác nhân AI mà không coi đoạn trích tìm kiếm là một kho dữ liệu nghiên cứu hoàn chỉnh. Bộ điều hợp địa phương giữ đủ bối cảnh để công nhân hoặc người xem xét tiếp theo có thể hiểu lý do tại sao mỗi ứng viên lại vào hàng đợi.

Định nghĩa Hợp đồng Khám phá

Một công việc khám phá bắt đầu với một câu hỏi nghiên cứu và một truy vấn chính xác. Giữ câu hỏi bên ngoài yêu cầu đã gửi như metadata ứng dụng. Nhiều truy vấn có thể khám phá một câu hỏi, nhưng bối cảnh cá nhân của chúng nên vẫn có thể khôi phục.

Hợp đồng đầu ra là một tập hợp các bản ghi ứng viên với các URL, văn bản quan sát, thứ tự nguồn, và trạng thái xem xét. Nó không chứa câu trả lời đã được xác minh. Một ứng viên có thể liên quan, không liên quan, không thể truy xuất, hoặc bị thay thế sau khi một người xem xét đọc nó.

Cho hệ thống bên dưới một quy tắc rõ ràng: chỉ những tài liệu được thu thập và xem xét mới có thể hỗ trợ một tuyên bố. Các ứng viên chỉ tìm kiếm có thể gợi ý một cuộc điều tra khác, nhưng chúng không thể tự động vào danh sách bằng chứng của câu trả lời. Biên giới này làm cho các thất bại trở nên hiển nhiên thay vì cho phép một trình tạo câu trả lời lấp đầy bằng chứng còn thiếu bằng văn bản hợp lý.

Các yêu cầu và Tham số Yêu cầu

Chương trình địa phương cần Python và một bản chụp JSON đã lưu. Nó chỉ sử dụng các mô-đun từ thư viện tiêu chuẩn. Bản chụp là một bao bì ứng dụng chứa request, http_status, response, run_id, và received_at; các tên bên ngoài đó là các trường của người thu thập của bạn, không phải là một bộ bao bọc phản hồi API đã khẳng định.

Việc thu thập trực tiếp yêu cầu một khóa API tài khoản. Quy trình yêu cầu Tìm kiếm Google tài liệu POST https://api.scrapeless.com/api/v1/scraper/request, một tiêu đề x-api-token, và diễn viên scraper.google.search. Đặt các tham số tìm kiếm bên trong input.

Xem lại các tham số Tìm kiếm Google trước khi tạo yêu cầu. Quốc gia, ngôn ngữ, và cách diễn đạt truy vấn quy định bối cảnh tìm kiếm. Nếu bạn sử dụng chế độ URL đầy đủ, các tham số đầu vào khác sẽ bị bỏ qua; giữ nguyên URL đã gửi thay vì phát minh ra một cấu hình hiệu quả sau đó.

Lưu ý: Không có cuộc gọi API được xác thực hoặc truy xuất toàn văn nào được thực hiện cho bài viết này. Bước thực thi là một chuyển đổi địa phương được thử nghiệm với các bản chụp tổng hợp. Để thu thập dữ liệu trực tiếp hoặc giải quyết một nhiệm vụ đang chờ, trước tiên hãy xác minh quy trình tài khoản trong tài liệu hiện tại và kiểm tra đầu ra thực tế của nó.

Bảo tồn Trạng thái Phản hồi Trước khi Đọc Kết quả

HTTP 200 mang dữ liệu nhiệm vụ; HTTP 201 đại diện cho một nhiệm vụ đang chờ. Bảo tồn taskId đã trả về khi có sẵn. Một nhiệm vụ đang chờ phải vẫn đang chờ cho đến khi quy trình hoàn thiện đã được xác minh riêng của bạn sản xuất kết quả cuối cùng; bộ điều hợp không đoán trước một điểm truy xuất.

Đối với một phản hồi hoàn thành, kiểm tra mảng organic_results đã được tài liệu hóa. Thiếu hoặc trường bị gõ sai tạo ra trạng thái unmapped, trong khi một mảng rỗng có mặt tạo ra empty. Những kết quả đó có ý nghĩa khác nhau cho giai đoạn tiếp theo.

Mô hình giá trị JSON hỗ trợ giữ lại phản hồi thô mà không xóa null hoặc các giá trị lồng nhau. Giữ lại bản chụp như là nguồn hồ sơ ngay cả sau khi bộ điều hợp tạo ra một danh sách ứng viên hẹp hơn.

Xây dựng Bộ điều hợp Ứng viên Địa phương

Lưu đoạn mã này dưới dạng source_candidates.py. Chạy python3 source_candidates.py capture.json với tập tin chụp của bạn. Nó in ra JSON đã được tạo ra vào đầu ra chuẩn và để nguyên tập tin đầu vào không thay đổi. Không có yêu cầu API, tải trang, hoặc gọi mô hình nào được thực hiện.

import argparse
import json
from pathlib import Path
from urllib.parse import urlsplit


def candidates(record):
    if not isinstance(record, dict):
        raise ValueError('Capture must be an object')
    status = record.get('http_status')
    payload = record.get('response')
    base = {'run_id': record.get('run_id'), 'request': record.get('request'),
            'received_at': record.get('received_at'), 'candidates': []}
    if status == 201:
        task = payload.get('taskId') if isinstance(payload, dict) else None
        return dict(base, state='pending', task_id=task)
    if status != 200:
        return dict(base, state='transport_error' if status is None else 'http_error')
    rows = payload.get('organic_results') if isinstance(payload, dict) else None
    if not isinstance(rows, list) or any(not isinstance(row, dict) for row in rows):
        return dict(base, state='unmapped')
    output, seen = [], set()
    for ordinal, row in enumerate(rows):
        link = row.get('link')
        reason, host = None, None
        try:
            parsed = urlsplit(link) if isinstance(link, str) else None
            if (parsed is None or parsed.scheme not in ('http', 'https')
                    or not parsed.hostname or parsed.username or parsed.password):
                reason = 'invalid_web_url'
            else:
                host = parsed.hostname.lower()
        except ValueError:
            reason = 'invalid_web_url'
        if reason is None and link in seen:
            reason = 'duplicate_exact_url'
        if reason is None:
            seen.add(link)
        output.append({'candidate_id': f'source-{ordinal}', 'ordinal': ordinal,
                       'position': row.get('position'), 'title': row.get('title'),
                       'url': link, 'hostname': host, 'snippet': row.get('snippet'),
                       'review_state': 'excluded' if reason else 'needs_review',
                       'exclusion_reason': reason, 'evidence_state': 'discovery_only'})
    return dict(base, state='observed' if rows else 'empty', candidates=output)


if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument('capture')
    args = parser.parse_args()
    result = candidates(json.loads(Path(args.capture).read_text(encoding='utf-8')))
    print(json.dumps(result, ensure_ascii=False, indent=2))

Các định danh ứng viên là cục bộ cho một lần chạy; kết hợp chúng với run_id ở phía hạ lưu. Các URL trùng lặp chính xác vẫn được hiển thị dưới dạng hàng bị loại trừ, do đó hàng đợi bảo tồn một lời giải thích thay vì im lặng loại bỏ một kết quả. Các biến thể URL khác vẫn tách biệt chờ xem xét.

Kiểm tra URL sử dụng phân tích thành phần URL để từ chối các máy chủ bị thiếu, các sơ đồ không hỗ trợ và thông tin xác thực nhúng. Đây là một kiểm tra hình dạng đầu vào, không phải là ranh giới bảo mật cho một trình lấy dữ liệu mạng. Dịch vụ truy xuất sau đó phải thi hành chính sách đích của riêng mình, bao gồm phân giải địa chỉ và chuyển hướng.

Bắt đầu thu thập dữ liệu với Scrapeless

Nâng cao quy trình thu thập dữ liệu và tự động hóa trên web của bạn với Scrapeless!
Đăng ký ngay hôm nay và nhận $5 tín dụng miễn phí — không yêu cầu thẻ tín dụng.

Yêu cầu tín dụng miễn phí của bạn ngay bây giờ trong Bảng điều khiển Scrapeless.

Chọn Nguồn và Lấy Nội Dung Một Cách Riêng Biệt

Xem xét từng ứng viên đủ điều kiện với câu hỏi. Ghi lại một lý do lựa chọn hoặc loại trừ và ưu tiên bằng chứng trực tiếp xác lập sự thật cần thiết. Vị trí tự nhiên cao là một quan sát tìm kiếm, không phải điểm độ tin cậy.

URL được chọn sẽ vào giai đoạn truy xuất riêng. Bước đó nên giữ lại URL đã yêu cầu, đích cuối, thời gian truy xuất, tham chiếu nội dung và kết quả. Một đích không thể truy cập vẫn không thể truy cập; đừng thay thế đoạn trích của nó cho phần thân bị thiếu và gọi đó là đã được truy xuất.

Mô tả của Google về đoạn trích tìm kiếm giải thích tại sao đoạn trích chỉ là một đầu. Cách diễn đạt có thể phụ thuộc vào truy vấn và có thể không khớp với đoạn văn mà bạn cần trích dẫn. Kiểm tra nguồn đã truy xuất trước khi suy ra một câu trả lời có thực.

Xem nội dung trang như dữ liệu không đáng tin cậy. Một trang có thể chứa các hướng dẫn nhắm đến một trợ lý; những hướng dẫn đó không làm thay đổi nhiệm vụ nghiên cứu hoặc quyền truy cập công cụ của bạn. Giữ sự phân biệt giữa bằng chứng đã truy xuất và hướng dẫn thực thi rõ ràng trong ứng dụng xung quanh.

Kết Nối Các Khẳng Định với Các Đoạn Đã Xem Xét

Một hồ sơ trích dẫn nên liên kết một khẳng định đề xuất với đoạn hỗ trợ và nguồn tài liệu đã truy xuất của nó. Giữ danh tính ứng viên như nguồn gốc, nhưng lưu trữ vị trí đoạn văn và hồ sơ truy xuất một cách riêng biệt. URL một mình không cho thấy rằng trang hỗ trợ cách diễn đạt của khẳng định.

Kiểm tra phạm vi cũng như sự liên quan. Một nguồn có thể thảo luận về một phiên bản sản phẩm hoặc một thị trường. Một trợ lý không nên tổng quát nó cho mọi cấu hình chỉ vì tiêu đề khớp với chủ đề. Các nguồn mâu thuẫn nên tạo ra một câu hỏi chưa được giải quyết hoặc một câu trả lời có điều kiện, không phải một lựa chọn tùy ý dựa trên vị trí tìm kiếm.

Mô hình nguồn gốc cung cấp những phân biệt hữu ích giữa bằng chứng, hoạt động đã xử lý nó và người hoặc hệ thống chịu trách nhiệm. Việc triển khai của bạn có thể sử dụng các hồ sơ đơn giản hơn trong khi vẫn bảo tồn những mối quan hệ đó.

Khi không có nguồn đã xem xét nào hỗ trợ một khẳng định, hãy bỏ qua nó hoặc xác định khoảng trống. Khám phá nguồn tài liệu cải thiện quy trình làm việc với bằng chứng; nó không đảm bảo việc loại bỏ đầu ra mô hình không hỗ trợ.

Kiểm Tra Bộ Điều Hợp Trước Khi Kết Nối Một Đại Diện

Chạy các kiểm tra cục bộ cho một mảng hữu cơ hiện có, một mảng trống, một trường bị thiếu, một mục không hợp lệ, HTTP 201, và một lỗi HTTP. Bao gồm các URL trùng lặp và một sơ đồ không hợp lệ. Những thiết bị này kiểm tra quyết định ứng dụng, không phải phạm vi hiện tại của API.

Xác nhận rằng các hàng bị loại trừ giữ các quan sát gốc của chúng và rằng mọi ứng viên vẫn discovery_only. Kiểm tra một tài khoản thực tế trước khi áp dụng bộ điều hợp trong sản xuất. Nếu cấu trúc của nó khác, hãy cập nhật ánh xạ một cách rõ ràng và giữ lại phản hồi gốc để so sánh.

Một khung đại diện là tùy chọn tại ranh giới này. Bất kỳ người gọi nào có thể tiêu thụ hợp đồng JSON đều có thể sử dụng hàng đợi xem xét, nhưng tính tương thích với SDK cụ thể hoặc giao thức công cụ cần thử nghiệm tích hợp riêng. Chương trình cục bộ không tuyên bố một cuộc bắt tay như vậy.

Kết Luận

Giữ nhỏ và rõ ràng trong việc khám phá tìm kiếm: bảo tồn yêu cầu, phân loại kết quả thu thập và sản xuất các ứng viên với trạng thái xem xét. Việc truy xuất và kiểm tra trích dẫn sau đó có một hợp đồng đầu vào rõ ràng thay vì thừa hưởng một danh sách liên kết không giải thích.

Kỷ luật xem xét nguồn giống nhau có thể hỗ trợ phân tích khoảng trống nội dung khi một nhóm biên tập cần bằng chứng trước khi giao nhiệm vụ viết một bài báo mới.

Xây Dựng Quan Sát Tìm Kiếm Kế Tiếp Của Bạn

Sử dụng Scrapeless Google Search API để thu thập bằng chứng tìm kiếm cho quy trình này. Xem xét giá cả của Scrapeless khi lập kế hoạch ngân sách thu thập của bạn, và giữ các tham số tìm kiếm Google bên cạnh cấu hình yêu cầu của bạn.

Thảo luận về việc triển khai của bạn với cộng đồng trên Discord hoặc Telegram.

Câu hỏi thường gặp

H: Bộ điều hợp có thu hồi văn bản toàn trang không?

Không. Nó xử lý dữ liệu tìm kiếm đã lưu thành các ứng cử viên. Việc thu hồi văn bản đầy đủ là một bước riêng biệt với kết quả và hồ sơ bằng chứng riêng.

H: Có thể tự động trích dẫn kết quả hữu cơ đầu tiên không?

Vị trí không xác định rằng một trang hỗ trợ yêu cầu của bạn. Hãy thu hồi và xem xét đoạn liên quan trước khi trích dẫn nó.

H: Điều gì xảy ra với HTTP 201?

Bộ điều hợp trả pending và giữ lại mã nhận diện tác vụ khi có sẵn. Nó không thu hồi kết quả đang chờ hoặc tính nó là một tìm kiếm trống.

H: Phân tích URL có khiến việc lấy ứng cử viên an toàn không?

Không. Bộ điều hợp kiểm tra hình dạng cơ bản của URL. Bộ lấy vẫn cần một chính sách đích xử lý các địa chỉ đã được giải quyết và chuyển hướng.

H: Điều này có yêu cầu một khung tác nhân cụ thể không?

Không. Giới hạn được chứng minh là JSON cục bộ. Một sự tích hợp khung và quy trình tài khoản trực tiếp yêu cầu xác minh riêng biệt.