LangChain web search: nối search API, tải trang và lưu trích dẫn
LangChain web search giúp mô hình ngôn ngữ tìm thông tin mới trên Internet thay vì chỉ dựa vào dữ liệu huấn luyện cũ. Muốn câu trả lời kiểm chứng được, anh em cần thêm bước tải trang và lưu trích dẫn. Bài này, ProxyVN hướng dẫn nối search API làm tool, tải trang qua proxy, ghi nguồn và giới hạn số request của agent.
LangChain web search gồm những phần nào
Một luồng tìm kiếm web trong LangChain thường có ba phần: công cụ tìm kiếm trả về danh sách kết quả, công cụ tải trang lấy nội dung chi tiết và mô hình tổng hợp câu trả lời. Mỗi phần là một tool hoặc một bước trong chuỗi xử lý. Tách bạch ba phần giúp anh em kiểm soát chi phí và chất lượng từng khâu.
Tài liệu khái niệm tool của LangChain mô tả tool là một hàm có tên, mô tả và schema đầu vào để mô hình biết khi nào nên gọi. Mô hình không tự truy cập Internet. Nó chỉ quyết định gọi tool nào với tham số gì, còn code của anh em thực hiện request thật.
Kết quả tìm kiếm chưa phải nội dung
Search API thường trả tiêu đề, URL và một đoạn trích ngắn cho mỗi kết quả. Đoạn trích này do công cụ tìm kiếm tạo ra, có thể đã cũ hoặc bị cắt mất ngữ cảnh. Nếu mô hình chỉ đọc đoạn trích, câu trả lời dễ sai ở chi tiết như con số hay phiên bản.
Vì vậy, với câu hỏi cần độ chính xác, nên tải trang gốc của hai tới ba kết quả đầu. Mô hình đọc nội dung thật rồi mới trả lời. Đoạn trích tìm kiếm chỉ dùng để chọn trang, không dùng làm căn cứ trả lời.
Vai trò của trích dẫn
Trích dẫn là danh sách URL và đoạn văn mà câu trả lời dựa vào. Người đọc dùng trích dẫn để tự kiểm tra, còn anh em dùng nó để dò lỗi khi câu trả lời sai. Không có trích dẫn, mọi câu trả lời đều phải tin theo lời mô hình.
Trích dẫn cần lưu cả thời điểm tải trang. Trang web thay đổi, nên một câu trả lời đúng hôm nay có thể sai vào tuần sau. Ghi thời điểm giúp người đọc biết thông tin được lấy khi nào.
Tóm lại, LangChain web search không chỉ là gọi một search API. Đó là chuỗi tìm, tải, đọc và ghi nguồn, mỗi khâu cần được kiểm soát riêng.
Search API và proxy tự cấp trong LangChain web search
Có hai cách lấy kết quả tìm kiếm: dùng search API của nhà cung cấp, hoặc tự tải trang kết quả của công cụ tìm kiếm. Hai cách khác nhau về hạ tầng mạng, chi phí và điều khoản sử dụng. Hiểu khác biệt này giúp anh em đặt proxy đúng chỗ.

Search API và proxy tự cấp
Search API tự lo phần mạng
Các dịch vụ như Brave Search API, Tavily hay SerpAPI nhận truy vấn qua HTTP và trả JSON. Nhà cung cấp tự vận hành hạ tầng tìm kiếm hoặc thu thập phía sau, bao gồm cả việc quản lý IP. Anh em chỉ cần khoá API và gọi từ máy mình.
Với cách này, anh em không cần proxy cho bước tìm kiếm. Gắn proxy vào request tới search API chỉ thêm độ trễ và có thể làm nhà cung cấp nghi ngờ khi IP đổi liên tục. Ngoại lệ là khi mạng doanh nghiệp bắt buộc mọi kết nối ra ngoài đi qua proxy nội bộ.
Tự tải trang kết quả tìm kiếm
Cách thứ hai là tự gửi request tới trang kết quả của Google hay Bing rồi phân tích HTML. Cách này đòi hỏi proxy, xử lý CAPTCHA và cập nhật bộ phân tích mỗi khi giao diện đổi. Quan trọng hơn, điều khoản của các công cụ tìm kiếm lớn thường không cho phép truy vấn tự động kiểu này.
Nếu nhu cầu là theo dõi thứ hạng hoặc nghiên cứu SERP có quy mô, anh em nên đọc bài SERP API trên blog ProxyVN để so sánh các lựa chọn. Với agent hỏi đáp thông thường, search API là con đường gọn và ít rủi ro hơn nhiều.
Proxy dùng cho bước tải trang
Bước tải trang gốc là nơi proxy tự cấp phát huy tác dụng. Agent có thể cần đọc trang từ nhiều website khác nhau, và một số website giới hạn theo IP. Proxy giúp tách lưu lượng của agent khỏi IP văn phòng, đồng thời cho phép kiểm tra nội dung theo khu vực khi cần.
Bảng dưới tóm tắt nơi nên và không nên đặt proxy trong luồng LangChain web search. Anh em đối chiếu khi thiết kế hoặc khi gặp lỗi mạng.
Khâu |
Đích kết nối |
Cần proxy thu thập |
Ghi chú |
|---|---|---|---|
Tìm kiếm |
Search API |
Không |
Dùng khoá API, giữ IP ổn định |
Tải trang gốc |
Nhiều website |
Tuỳ nhu cầu |
Gắn qua Session riêng |
Gọi mô hình |
Nhà cung cấp LLM |
Không |
Theo chính sách mạng doanh nghiệp |
Lưu trích dẫn |
Tệp hoặc cơ sở dữ liệu |
Không |
Chạy cục bộ |
Như vậy, proxy trong LangChain web search chỉ nên gắn vào khâu tải trang gốc. Các khâu còn lại có cấu hình mạng riêng và nên được giữ đơn giản.
Chuẩn bị môi trường LangChain web search
Lab dùng gói langchain-core để định nghĩa tool, Requests để gọi API và tải trang, BeautifulSoup để làm sạch HTML. Phần gọi mô hình dùng gói tích hợp của nhà cung cấp anh em chọn. Code minh họa giữ phần mô hình tách riêng để dễ thay thế.
Cài thư viện
Các lệnh dưới chạy trên PowerShell. Gói langchain-openai chỉ cần khi dùng mô hình của OpenAI; nếu dùng nhà cung cấp khác, thay bằng gói tương ứng.
python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install langchain-core langchain-openai requests beautifulsoup4
python -m pip freeze > requirements-lock.txt
Ghi lại tệp phiên bản là thói quen quan trọng với LangChain, vì cấu trúc gói và tên lớp thay đổi khá nhanh giữa các bản. Khi một đoạn code mẫu không chạy, việc đầu tiên là so phiên bản đang cài với phiên bản trong tài liệu.
Biến môi trường cho khoá và proxy
Lab cần ba biến: khoá search API, khoá mô hình và địa chỉ proxy cho bước tải trang. Đặt chúng trong môi trường thay vì ghi trong code. Ví dụ dưới dùng Brave Search API; anh em đăng ký khoá theo hướng dẫn trên trang Brave Search API.
$env:BRAVE_API_KEY = 'YOUR_BRAVE_KEY'
$env:OPENAI_API_KEY = 'YOUR_OPENAI_KEY'
$env:FETCH_PROXY = 'http://USERNAME:PASSWORD@HOST:PORT'
Các giá trị trên là mẫu. Không chụp màn hình hay gửi log chứa khoá thật. Nếu mật khẩu proxy có ký tự đặc biệt, mã hoá URL trước khi ghép vào chuỗi để tránh lỗi phân tích địa chỉ.
Quyết định giới hạn ngay từ đầu
Trước khi viết code, anh em nên chốt ba con số: số kết quả tìm kiếm tối đa mỗi truy vấn, số trang tải tối đa mỗi câu hỏi và thời gian chờ tối đa mỗi request. Agent không có giới hạn có thể gọi tool liên tục, tốn tiền API và gửi quá nhiều request tới website.
Với lab, năm kết quả tìm kiếm, ba trang tải và 30 giây chờ là mức khởi đầu hợp lý. Sau khi chạy thử vài chục câu hỏi, anh em điều chỉnh theo thực tế. Tóm lại, môi trường tốt là môi trường có giới hạn rõ ràng ngay từ dòng code đầu tiên.
Viết tool tìm kiếm cho LangChain web search
Tool tìm kiếm nhận chuỗi truy vấn và trả danh sách kết quả gọn gồm tiêu đề, URL và đoạn trích. Định dạng gọn giúp mô hình đọc nhanh và giảm token. Code dưới dùng decorator tool của langchain-core để biến hàm Python thành tool.
Code tool gọi Brave Search API
Hàm web_search gửi request tới endpoint tìm kiếm web của Brave với header chứa khoá. Request này không đi qua proxy thu thập, đúng như phân tích ở phần trước. Kết quả được cắt còn số lượng giới hạn và chuyển thành chuỗi JSON.
import os
import json
import requests
from langchain_core.tools import tool
MAX_RESULTS = 5
@tool
def web_search(query: str) -> str:
"""Tìm kiếm web và trả về tiêu đề, URL, đoạn trích của các kết quả đầu."""
r = requests.get(
"https://api.search.brave.com/res/v1/web/search",
params={"q": query, "count": MAX_RESULTS},
headers={"Accept": "application/json",
"X-Subscription-Token": os.environ["BRAVE_API_KEY"]},
timeout=20,
)
r.raise_for_status()
items = r.json().get("web", {}).get("results", [])[:MAX_RESULTS]
slim = [{"title": i.get("title"), "url": i.get("url"),
"snippet": i.get("description")} for i in items]
return json.dumps(slim, ensure_ascii=False)
Docstring của hàm trở thành mô tả tool mà mô hình đọc. Mô tả càng rõ, mô hình càng gọi đúng lúc. Nên viết mô tả nêu rõ tool trả về gì, tránh để mô hình nghĩ tool trả nội dung đầy đủ của trang.
Xử lý lỗi từ search API
Search API có hạn mức theo gói. Khi vượt, API thường trả mã 429 hoặc thông báo lỗi trong JSON. Hàm raise_for_status ném ngoại lệ với mã lỗi HTTP, giúp agent dừng thay vì nhận kết quả rỗng và tiếp tục suy luận sai.
Tài liệu MDN về mã 429 giải thích header Retry-After. Khi gặp mã này từ search API, đừng đổi IP hay thêm proxy để vượt hạn mức. Hãy chờ, nâng gói hoặc giảm số truy vấn mỗi câu hỏi.
- 401 hoặc 403: kiểm tra khoá API và gói đăng ký.
- 429: vượt hạn mức, chờ theo Retry-After.
- Kết quả rỗng: thử lại truy vấn ngắn hơn hoặc đổi từ khoá.
- Timeout: kiểm tra mạng của máy chạy, không phải proxy thu thập.
Viết truy vấn tìm kiếm tốt hơn
Mô hình thường tạo truy vấn dài như một câu hỏi đầy đủ. Công cụ tìm kiếm cho kết quả tốt hơn với truy vấn ngắn, chứa từ khoá chính. Anh em có thể thêm hướng dẫn trong prompt hệ thống, yêu cầu mô hình viết truy vấn dưới mười từ và giữ tên riêng nguyên văn.
Với câu hỏi tiếng Việt về chủ đề kỹ thuật, tài liệu gốc thường bằng tiếng Anh. Anh em có thể cho phép mô hình tạo hai truy vấn, một tiếng Việt và một tiếng Anh, rồi chọn kết quả từ cả hai. Cách này tăng khả năng gặp tài liệu chính thức, nhưng nhớ tính vào giới hạn số truy vấn mỗi câu hỏi.
Một mẹo nữa là cho phép mô hình thêm toán tử site: khi đã biết tên miền tài liệu chính thức. Ví dụ hỏi về Requests thì truy vấn kèm site của trang tài liệu. Kết quả trả về ít nhưng đúng nguồn, giảm số trang phải tải để kiểm tra.
Kết lại, tool tìm kiếm tốt là tool trả kết quả gọn, báo lỗi rõ và có giới hạn số lượng. Đây là nền cho bước tải trang ở phần tiếp theo.
Tool tải trang qua proxy trong LangChain web search
Tool tải trang nhận một URL, tải qua Session có proxy, kiểm tra phản hồi và trả về văn bản sạch. Đây là nơi anh em kiểm soát toàn bộ cấu hình mạng cho phần đọc nội dung. Code dưới là ví dụ triển khai chung.

Tool tải trang có kiểm tra
Code tool fetch_page
Session đặt trust_env bằng False để bỏ qua biến môi trường proxy cũ, chỉ dùng proxy khai báo trong code. Văn bản trả về được cắt tới độ dài tối đa để không làm tràn ngữ cảnh mô hình. Mỗi lần tải được ghi vào sổ trích dẫn.
import time
import hashlib
from datetime import datetime, timezone
from bs4 import BeautifulSoup
MAX_CHARS = 6000
CITATIONS = []
def _session():
s = requests.Session()
s.trust_env = False
p = os.environ.get("FETCH_PROXY")
if p:
s.proxies.update({"http": p, "https": p})
s.headers["User-Agent"] = "langchain-search-lab/0.1 (contact: you@example.com)"
return s
SESSION = _session()
@tool
def fetch_page(url: str) -> str:
"""Tải nội dung chính của một trang web từ URL và trả về văn bản đã làm sạch."""
time.sleep(1.5)
r = SESSION.get(url, timeout=(10, 30))
if r.status_code != 200 or "html" not in r.headers.get("Content-Type", ""):
return f"ERROR status={r.status_code} url={r.url}"
soup = BeautifulSoup(r.text, "html.parser")
for t in soup(["script", "style", "nav", "footer", "header", "aside", "form"]):
t.decompose()
root = soup.find("main") or soup.find("article") or soup.body or soup
lines = [x.strip() for x in root.get_text("\n").splitlines()]
text = "\n".join(x for x in lines if len(x) > 30)[:MAX_CHARS]
title = soup.title.get_text(strip=True) if soup.title else ""
CITATIONS.append({
"n": len(CITATIONS) + 1,
"url": r.url,
"title": title,
"sha": hashlib.sha256(text.encode("utf-8")).hexdigest()[:16],
"fetched": datetime.now(timezone.utc).isoformat(),
})
return f"[{len(CITATIONS)}] {title}\n{r.url}\n\n{text}"
Mỗi đoạn văn bản trả về có số thứ tự trích dẫn ở đầu. Mô hình được hướng dẫn ghi số này sau mỗi ý trong câu trả lời. Nhờ đó, câu trả lời cuối có thể đối chiếu với danh sách CITATIONS.
Kiểm tra tuyến proxy trước khi chạy agent
Trước khi để agent gọi fetch_page, anh em chạy một lần với trang trả IP công khai. So IP nhận được với IP proxy để xác nhận tuyến mạng. Bước này nên chạy riêng, không để agent tự làm.
print(SESSION.get("https://api.ipify.org", timeout=15).text)
print(requests.get("https://api.ipify.org", timeout=15).text)
Dòng đầu là IP đi qua proxy, dòng sau là IP trực tiếp. Hai giá trị phải khác nhau. Nếu giống nhau, kiểm tra biến FETCH_PROXY có tồn tại trong cửa sổ đang chạy Python hay không.
Giới hạn độ dài và loại nội dung
MAX_CHARS giữ văn bản trong mức mô hình xử lý được. Trang dài bị cắt có thể mất phần cần thiết, nên ưu tiên lấy thẻ main hoặc article để phần nội dung chính nằm ở đầu. Với PDF hoặc tệp khác HTML, tool trả lỗi rõ ràng thay vì đưa dữ liệu nhị phân cho mô hình.
Một tool trả lỗi rõ ràng tốt hơn một tool trả văn bản rác. Mô hình đọc thông báo lỗi sẽ chọn trang khác, còn đọc văn bản rác sẽ suy luận sai. Tóm lại, tool tải trang tốt là tool có proxy riêng, giới hạn độ dài và sổ trích dẫn đi kèm.
Ghép agent cho LangChain web search kèm trích dẫn
Khi đã có hai tool, bước tiếp theo là cho mô hình dùng chúng. Cách đơn giản và dễ kiểm soát là vòng lặp gọi tool tự viết, với số bước tối đa cố định. Cách này minh bạch hơn so với dùng agent dựng sẵn, vì anh em thấy rõ từng lần gọi.

Sổ trích dẫn
Code vòng lặp gọi tool
Mô hình được gắn hai tool bằng bind_tools. Mỗi vòng, mô hình trả về lời gọi tool hoặc câu trả lời cuối. Nếu là lời gọi tool, code thực thi và đưa kết quả trở lại. Vòng lặp dừng khi có câu trả lời hoặc vượt số bước tối đa.
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, SystemMessage, ToolMessage
TOOLS = {"web_search": web_search, "fetch_page": fetch_page}
MAX_STEPS = 6
SYSTEM = (
"Bạn trả lời dựa trên trang web đã tải. "
"Dùng web_search để chọn trang, rồi fetch_page tối đa 3 trang. "
"Ghi số trích dẫn trong ngoặc vuông sau mỗi ý. "
"Nếu không đủ thông tin, nói rõ là chưa tìm thấy."
)
def ask(question):
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools(list(TOOLS.values()))
msgs = [SystemMessage(SYSTEM), HumanMessage(question)]
fetched = 0
for _ in range(MAX_STEPS):
ai = llm.invoke(msgs)
msgs.append(ai)
if not ai.tool_calls:
return ai.content
for call in ai.tool_calls:
if call["name"] == "fetch_page":
fetched += 1
if fetched > 3:
msgs.append(ToolMessage("LIMIT: đã đủ 3 trang", tool_call_id=call["id"]))
continue
out = TOOLS[call["name"]].invoke(call["args"])
msgs.append(ToolMessage(out, tool_call_id=call["id"]))
return "Dừng vì vượt số bước tối đa."
Tên mô hình trong code chỉ là ví dụ; anh em thay bằng mô hình đang dùng. Hai lớp giới hạn hoạt động cùng lúc: MAX_STEPS chặn tổng số vòng, biến fetched chặn số trang tải. Khi vượt giới hạn, mô hình nhận thông báo rõ ràng để tự kết thúc.
In câu trả lời kèm danh sách nguồn
Sau khi có câu trả lời, in danh sách CITATIONS bên dưới. Người đọc thấy số trích dẫn trong câu trả lời và tra được ngay URL tương ứng. Danh sách nên được xoá trước mỗi câu hỏi mới để số thứ tự không lẫn.
CITATIONS.clear()
print(ask("Phiên bản mới nhất của thư viện Requests là bao nhiêu?"))
for c in CITATIONS:
print(f"[{c['n']}] {c['title']} - {c['url']} ({c['fetched']})")
Với câu hỏi về phiên bản hay giá, thời điểm tải rất quan trọng. Câu trả lời có thể đúng tại thời điểm chạy nhưng sai sau vài tuần. Hiển thị thời điểm giúp người đọc tự đánh giá độ mới của thông tin.
Agent tìm kiếm web tốt không phải agent gọi nhiều tool nhất, mà là agent trả lời đúng với ít request nhất và ghi rõ nguồn.
Kiểm tra trích dẫn có khớp không
Mô hình đôi khi ghi số trích dẫn không tồn tại hoặc gán ý cho nhầm nguồn. Anh em có thể viết một bước kiểm tra đơn giản: tìm mọi số trong ngoặc vuông của câu trả lời và so với danh sách CITATIONS. Số không có trong danh sách là dấu hiệu cần xem lại.
Kiểm tra sâu hơn là tìm một vài cụm từ đặc trưng của mỗi ý trong văn bản của nguồn tương ứng. Cách này tốn thêm công nhưng phát hiện được trường hợp mô hình tự bịa. Như vậy, trích dẫn chỉ có giá trị khi được kiểm tra, không chỉ khi được hiển thị.
Lưu trích dẫn và cache cho LangChain web search
Sổ trích dẫn trong bộ nhớ chỉ tồn tại tới khi chương trình dừng. Khi agent phục vụ nhiều người hoặc chạy lâu dài, anh em cần lưu trích dẫn ra tệp hoặc cơ sở dữ liệu. Cùng lúc đó, cache nội dung trang giúp giảm số request lặp lại tới website.
Ghi trích dẫn ra tệp JSON Lines
Định dạng JSON Lines ghi mỗi bản ghi trên một dòng, dễ nối thêm và dễ đọc lại bằng nhiều công cụ. Mỗi câu hỏi được gán một mã riêng, mọi trích dẫn của câu hỏi đó mang cùng mã. Cách này cho phép tra ngược từ một câu trả lời cũ về đúng trang đã tải.
import uuid
def save_run(question, answer, path="citations.jsonl"):
run_id = uuid.uuid4().hex[:12]
with open(path, "a", encoding="utf-8") as f:
for c in CITATIONS:
row = dict(c, run=run_id, question=question)
f.write(json.dumps(row, ensure_ascii=False) + "\n")
f.write(json.dumps({"run": run_id, "answer": answer}, ensure_ascii=False) + "\n")
return run_id
Tệp citations.jsonl không chứa toàn văn trang, chỉ chứa URL, tiêu đề, mã băm và thời điểm. Nếu cần lưu toàn văn để kiểm toán, nên ghi vào thư mục riêng theo mã băm. Như vậy, cùng một trang được nhiều câu hỏi dùng chung chỉ lưu một lần.
Cache nội dung để giảm request
Nhiều câu hỏi gần nhau thường dẫn tới cùng vài trang. Cache đơn giản theo URL với thời hạn vài giờ giúp agent không tải lại trang vừa đọc. Giảm request vừa nhẹ cho website nguồn, vừa giảm băng thông proxy và thời gian chờ của người dùng.
Thời hạn cache nên tuỳ loại nội dung. Trang tài liệu kỹ thuật có thể cache cả ngày, trang giá hoặc tin nóng nên cache ngắn. Khi người dùng hỏi thông tin cần độ mới cao, có thể thêm tuỳ chọn bỏ qua cache cho câu hỏi đó.
- Khoá cache: URL đã chuẩn hoá, bỏ tham số theo dõi như utm.
- Giá trị cache: văn bản sạch, tiêu đề, mã băm, thời điểm tải.
- Thời hạn: theo loại nguồn, ghi rõ trong cấu hình.
- Ghi chú trong trích dẫn: đánh dấu nội dung lấy từ cache và thời điểm gốc.
Bảo vệ dữ liệu người dùng trong log
Câu hỏi của người dùng có thể chứa thông tin cá nhân hoặc thông tin nội bộ. Khi lưu log trích dẫn, anh em cân nhắc che hoặc rút gọn câu hỏi. Đồng thời, không gửi câu hỏi nguyên văn làm truy vấn tìm kiếm nếu nó chứa dữ liệu nhạy cảm, vì truy vấn đi ra nhà cung cấp search API.
Một cách xử lý là để mô hình tạo truy vấn tìm kiếm ngắn gọn, chỉ giữ từ khoá kỹ thuật và tên riêng công khai. Prompt hệ thống có thể dặn rõ không đưa tên người, số điện thoại hay mã nội bộ vào truy vấn. Truy vấn tìm kiếm cũng là dữ liệu rời khỏi hệ thống, nên cần được đối xử cẩn thận như mọi dữ liệu khác.
Tóm lại, lưu trích dẫn và cache giúp LangChain web search vừa kiểm chứng được về sau, vừa nhẹ hơn cho website nguồn. Hai việc này nên có ngay khi agent bắt đầu phục vụ nhiều hơn một người.
Xử lý lỗi khi chạy LangChain web search
Lỗi trong LangChain web search rơi vào ba nhóm: lỗi search API, lỗi tải trang và lỗi hành vi của mô hình. Mỗi nhóm có dấu hiệu và cách sửa khác nhau. Ghi log từng lần gọi tool giúp phân loại nhanh.
Lỗi tải trang qua proxy
ProxyError hoặc mã 407 cho thấy proxy từ chối xác thực. Kiểm tra lại thông tin đăng nhập và cách mã hoá ký tự đặc biệt. ConnectTimeout nghĩa là không kết nối được tới proxy; kiểm tra địa chỉ, cổng và giao thức. Bài requests.exceptions.ProxyError đi sâu vào từng nguyên nhân.
Mã 403 từ website nghĩa là request đã tới nơi nhưng bị từ chối. Nguyên nhân có thể là User-Agent, tần suất hoặc chính sách của website. Nếu website không cho phép truy cập tự động, hãy bỏ nguồn đó khỏi danh sách thay vì tìm cách vượt qua.
- ProxyError 407: sai thông tin xác thực proxy.
- SSLError: proxy không hỗ trợ CONNECT cho HTTPS.
- 403 hoặc 429 từ website: giảm tốc độ, xem điều khoản, bỏ nguồn nếu cần.
- Văn bản rỗng: trang cần JavaScript, tool hiện tại không đọc được.
Lỗi hành vi của mô hình
Mô hình có thể gọi web_search lặp lại với truy vấn gần giống nhau. Giới hạn MAX_STEPS ngăn vòng lặp vô hạn, nhưng anh em nên xem log để chỉnh prompt. Thêm câu hướng dẫn kiểu "không lặp lại truy vấn đã dùng" thường giảm hiện tượng này.
Mô hình cũng có thể trả lời ngay mà không gọi tool, dựa vào kiến thức cũ. Với câu hỏi cần thông tin mới, prompt hệ thống nên yêu cầu bắt buộc tìm kiếm trước khi trả lời. Kiểm tra log: nếu câu trả lời không kèm trích dẫn nào, đó là dấu hiệu mô hình đã bỏ qua tool.
Ghi log cho từng câu hỏi
Mỗi câu hỏi nên có một bản log gồm truy vấn tìm kiếm, URL đã tải, mã trạng thái, số trích dẫn và câu trả lời cuối. Che khoá API và thông tin proxy trước khi lưu. Log này là tài liệu quý để cải thiện prompt và giới hạn sau vài tuần vận hành.
Tóm lại, xử lý lỗi LangChain web search bắt đầu từ việc biết lỗi thuộc khâu nào. Log rõ ràng cho phép làm điều đó trong vài phút thay vì vài giờ.
Checklist vận hành LangChain web search
Trước khi đưa agent vào sử dụng thật, anh em rà lại các mục dưới đây. Danh sách gom những rủi ro đã nêu trong bài thành các bước kiểm tra cụ thể.

Giới hạn request cho agent
Kiểm tra kỹ thuật
Phần kỹ thuật đảm bảo tuyến mạng đúng, giới hạn hoạt động và dữ liệu nguồn đáng tin. Đây là các điểm cần kiểm tra mỗi khi nâng cấp thư viện hoặc đổi nhà cung cấp.
- Search API gọi trực tiếp, không qua proxy thu thập.
- Tool tải trang dùng Session riêng với trust_env bằng False.
- Đã kiểm chứng IP qua proxy bằng trang trả IP công khai.
- Có MAX_STEPS, giới hạn số trang tải và timeout mỗi request.
- Văn bản trả về bị cắt theo MAX_CHARS và có số trích dẫn.
- Sổ trích dẫn được xoá trước mỗi câu hỏi mới.
Kiểm tra vận hành và chi phí
Phần vận hành liên quan tới hạn mức, chi phí và quyền sử dụng nội dung. Bỏ qua phần này dễ dẫn tới hoá đơn bất ngờ hoặc vi phạm điều khoản của website nguồn.
- Biết hạn mức của gói search API và cách hệ thống phản ứng khi vượt.
- Theo dõi số token mô hình dùng cho mỗi câu hỏi.
- Đã loại các website không cho phép truy cập tự động.
- Log được che khoá và thông tin đăng nhập trước khi chia sẻ.
Khi cần mua proxy cho tool tải trang, anh em có thể xem các gói datacenter hoặc dân cư tĩnh đang hiển thị trên trang chủ ProxyVN, rồi chạy thử với một nhóm website nguồn trước khi mở cho agent dùng rộng. Để hiểu thêm cách agent dùng proxy khi duyệt web, xem bài proxy cho AI agent tự động.
Đánh giá định kỳ
Giữ một bộ khoảng hai mươi câu hỏi đã biết đáp án và nguồn đúng. Mỗi khi đổi mô hình, đổi prompt hay đổi search API, chạy lại bộ câu hỏi và so tỷ lệ trả lời đúng có trích dẫn hợp lệ. Con số này cho biết thay đổi có cải thiện thật hay chỉ khác đi.
Kết quả đánh giá nên ghi kèm ngày chạy và cấu hình. Sau vài lần, anh em sẽ có dữ liệu riêng để chọn cấu hình phù hợp với lĩnh vực của mình. Đây là kinh nghiệm không tài liệu chung nào thay thế được.
LangChain web search đáng tin khi tìm kiếm qua search API, tải trang qua proxy riêng và mọi ý đều có trích dẫn kiểm tra được. Hãy đặt giới hạn rõ, ghi log đầy đủ rồi mới mở rộng. Cần trao đổi về kết nối, anh em nhắn Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam trước khi chạy LangChain web search.