# RAG từ web trực tiếp: truy xuất bằng một tìm kiếm, trả lời kèm trích dẫn

> Tìm kiếm web với RAG: đọc các trang hàng đầu dạng Markdown, chia nhỏ và trả lời kèm trích dẫn. Mã Python, không cần KYC, trả bằng crypto.

- URL: https://llmwebsearch.com/vi/use-cases/rag/
- Cập nhật lần cuối: 2026-10-22
- Đơn vị phát hành: LLMWebSearch (https://llmwebsearch.com)

Một chỉ mục vector lưu những gì bạn đã tải vào tháng trước. Một số câu hỏi cần những gì web nói hôm nay. Live-web RAG truy xuất ngay tại thời điểm hỏi: một tìm kiếm, các trang hàng đầu dưới dạng Markdown, vài đoạn đưa vào prompt, và trích dẫn trở lại từng trang.

**Trả lời nhanh — Làm thế nào để tôi làm RAG với kết quả tìm kiếm web trực tiếp?**

Chạy một tìm kiếm web ngay tại thời điểm hỏi, đọc các trang hàng đầu, chia chúng thành các đoạn, giữ những đoạn liên quan nhất và yêu cầu mô hình trả lời kèm trích dẫn đánh số. **LLMWebSearch** xử lý hai bước đầu trong một lần gọi: kết quả đã xếp hạng với 3 trang đầu dưới dạng Markdown, với một credit, từ 1,20 US$/1K lượt tìm kiếm. Không cần KYC; thanh toán bằng crypto.

## Live-web RAG là gì?

Đó là retrieval-augmented generation trong đó bước truy xuất là một web search thay vì tra cứu trong index của riêng bạn. Câu hỏi được gửi đến web search API, API trả về các trang, và model trả lời dựa trên những trang đó.

Mô hình này phù hợp với các câu hỏi về những thứ thay đổi: giá cả, bản phát hành, quy định, lịch trình và tin tức. Nó cũng phù hợp với những câu hỏi long-tail mà tài liệu của bạn chưa từng đề cập. Chi phí là một truy vấn mỗi câu hỏi, hoặc hai khi lần đầu không trúng.

## Khi nào nên fetch mới và khi nào nên lưu trữ?

Lưu trữ những gì ổn định và là của bạn; fetch những gì thay đổi. Hướng dẫn sử dụng sản phẩm, chính sách nội bộ và tài liệu của riêng bạn thuộc về một chỉ mục vector, được làm mới theo lịch. Giá đối thủ, quy định và tin tức thuộc về truy xuất trực tiếp.

Nhiều đội kết hợp cả hai. Họ tìm kiếm chỉ mục của riêng mình trước và chỉ gọi web khi chỉ mục không có kết quả khớp tốt, hoặc khi câu hỏi nhắc đến một ngày gần đây.

Nếu bạn quyết định giữ các trang đã truy xuất, hãy lưu ý quan điểm của chúng tôi: Chúng tôi không huấn luyện bất kỳ model nào trên truy vấn của bạn hay trên những gì API trả về, và chúng tôi không thêm quy tắc riêng nào chống lại việc lưu trữ kết quả; quyền của các trang có nội dung bạn đọc vẫn áp dụng. Hãy kiểm tra điều khoản của từng trang trước khi tạo một bản sao thường trực nội dung của nó.

## Làm thế nào để tôi biến kết quả tìm kiếm thành các đoạn?

Chia mỗi trang theo các tiêu đề của nó, rồi cắt các phần dài về một độ dài cố định. Markdown làm việc này dễ dàng, vì tiêu đề là những dòng bắt đầu bằng `#`. Giữ URL nguồn và tiêu đề trên mỗi đoạn để các trích dẫn còn sống sót qua bước chia.

Ví dụ bên dưới tìm kiếm, đọc ba trang, chia nhỏ chúng và chọn sáu đoạn chia sẻ nhiều từ ngữ nhất với câu hỏi. Hãy thay số đếm từ bằng mô hình embedding của bạn khi chạy thực tế; cấu trúc vẫn giữ nguyên.

*Python: truy xuất từ web trực tiếp với các đoạn và nguồn được đánh số*

```python
import os
import re

import requests

API = "https://llmwebsearch.com/api/v1/search"
HEADERS = {"Authorization": "Bearer " + os.environ["LLMWEBSEARCH_API_KEY"]}


def live_chunks(query, read=3, chunk_len=1200):
    """Search, then cut each page that was read into heading-based chunks tagged with its source."""
    body = {"q": query, "max_results": 5, "read": read, "max_chars": 12000}
    results = requests.post(API, headers=HEADERS, json=body, timeout=60).json()["results"]
    chunks = []
    for r in results:
        if r.get("content_status") != "ok":
            continue
        for section in re.split(r"\n(?=#{1,3} )", r["content"]):
            section = section.strip()
            for start in range(0, len(section), chunk_len):
                chunks.append({"url": r["url"], "title": r["title"], "text": section[start:start + chunk_len]})
    return chunks


def top_chunks(chunks, question, k=6):
    """A plain keyword score; swap in your embedding model for better ranking."""
    words = set(re.findall(r"\w{4,}", question.lower()))

    def score(chunk):
        return sum(1 for w in re.findall(r"\w{4,}", chunk["text"].lower()) if w in words)

    return sorted(chunks, key=score, reverse=True)[:k]


def build_prompt(question):
    picked = top_chunks(live_chunks(question), question)
    urls = list(dict.fromkeys(c["url"] for c in picked))
    blocks = [f"[{urls.index(c['url']) + 1}] {c['title']}\n{c['text']}" for c in picked]
    sources = "\n".join(f"[{i}] {u}" for i, u in enumerate(urls, 1))
    return (
        "Use only the context to answer and cite sources as [n].\n\n"
        + "\n\n".join(blocks)
        + f"\n\nSources:\n{sources}\n\nQuestion: {question}"
    )
```

## Mỗi câu hỏi nên đọc bao nhiêu trang?

Ba là một khởi đầu tốt, và nó giữ tìm kiếm ở mức một credit. Hầu hết câu hỏi về sự thật được trả lời trong hai hoặc ba trang đầu của một truy vấn tốt.

Yêu cầu các trang dài hơn so với khi bạn dùng trong một chat agent, vì bộ chia đoạn dù sao cũng sẽ loại bỏ phần lớn văn bản. Một `max_chars` từ 10.000 đến 15.000 cho mỗi trang cho bộ xếp hạng đủ để chọn lựa. Nếu câu trả lời phụ thuộc vào một trang đã biết, hãy thêm nó bằng `include_domains` thay vì đọc thêm nhiều trang.

## Làm thế nào để mô hình trích dẫn nguồn của nó?

Đánh số các nguồn trong prompt và yêu cầu các con số trong câu trả lời. Một chỉ dẫn ngắn hoạt động tốt: chỉ dùng ngữ cảnh, trích dẫn mỗi khẳng định dưới dạng [n], và nói khi ngữ cảnh không bao quát câu hỏi.

Giữ danh sách nguồn ở cuối prompt, với một URL cho mỗi số. Sau đó hiển thị [n] dưới dạng liên kết trong giao diện của bạn. Người dùng tin tưởng những câu trả lời họ có thể kiểm tra, và các trích dẫn sai rất dễ phát hiện khi xem lại.

## Nếu một trang bị chặn hoặc trống thì sao?

Hãy bỏ qua nó và dùng các trang khác. Mọi kết quả đều mang một `content_status`; chỉ các kết quả `ok` mới có văn bản. Một trang có thể bị thiếu vì Trình đọc của chúng tôi tôn trọng robots.txt: nó tự giới thiệu là LLMWebSearch, tuân theo các quy tắc mà một trang viết cho nó hoặc cho tất cả robot, và bỏ qua nội dung của bất kỳ trang nào nó không được phép đọc.

Khi tất cả các trang của một tìm kiếm đều trả về trống, hãy thử lại một lần với một truy vấn khác hoặc thêm `include_domains` cho một trang bạn biết là mở. Khi một trang từ chối trình đọc của chúng tôi, kết quả trả về không có nội dung kèm trạng thái của trang: chúng tôi không bao giờ giải CAPTCHA, đăng nhập vào tài khoản hay lách qua một chặn chặn hoặc paywall.

## Live-web RAG tốn bao nhiêu?

Một tìm kiếm mỗi câu hỏi trong hầu hết các trường hợp. Một trợ lý hỗ trợ trả lời 5.000 câu hỏi mỗi tháng, với một tìm kiếm thứ hai cho một trong năm câu hỏi, dùng khoảng 6.000 tìm kiếm. 25.000 lượt tìm kiếm với 41,25 US$ đủ cho bốn tháng như vậy.

Mô hình của bạn cũng đọc các đoạn bạn gửi cho nó. Sáu đoạn, mỗi đoạn 1.200 ký tự, thêm khoảng 2.000 token mỗi câu hỏi, mà bạn kiểm soát qua kích thước và số lượng đoạn.

## Gói nào phù hợp với khối lượng công việc RAG?

Một credit cho mỗi câu hỏi với hầu hết quy trình. Credit tìm kiếm không có ngày hết hạn: phần bạn không dùng trong tháng này vẫn còn đó vào năm sau.

| Gói | Số lượng | Giá | Giá mỗi đơn vị |
| --- | --- | --- | --- |
| Dùng thử | 5.000 lượt tìm kiếm | 9,25 US$ | 1,85 US$/1K lượt tìm kiếm |
| Người xây dựng | 25.000 lượt tìm kiếm | 41,25 US$ | 1,65 US$/1K lượt tìm kiếm |
| Production | 100.000 lượt tìm kiếm | 145 US$ | 1,45 US$/1K lượt tìm kiếm |

Trong mọi gói: Top 3 trang được đọc dưới dạng Markdown · Bộ lọc theo quốc gia, ngôn ngữ, thời gian và tên miền · Không tính phí các lần gọi thất bại · Credit không bao giờ hết hạn

**Trước khi bạn thanh toán**

- Nạp tối thiểu 25 US$. Nạp một lần bằng crypto, rồi mua bất kỳ gói nào từ số dư của bạn.
- Tiền trong số dư của bạn không hết hạn và mua credit tìm kiếm bất cứ khi nào bạn muốn. Khi một pack rẻ hơn mức nạp tối thiểu, phần bạn đã trả chỉ để đạt mức tối thiểu đó sẽ được hoàn lại cho bạn theo yêu cầu trong vòng 30 ngày kể từ ngày thanh toán, bằng USDT hoặc USDC, miễn là phần đó vẫn chưa được dùng. Phần còn lại của số dư sẽ không được hoàn trả trừ khi pháp luật yêu cầu.
- Được ghi có khi thanh toán của bạn đã được kiểm tra trên blockchain. Thời gian xác nhận mạng thông thường: BTC ≈ 20 phút · USDT TRC-20 ≈ 1 phút · USDT ERC-20 ≈ 5 phút · USDC ERC-20 ≈ 5 phút · ETH ≈ 5 phút · SOL ≈ 1 phút · LTC ≈ 15 phút

## RAG trên web trực tiếp: các câu hỏi thường gặp

### Tôi có thể dùng LangChain hoặc LlamaIndex không?

Có. [Trang LangChain và LlamaIndex](https://llmwebsearch.com/vi/docs/langchain/) đóng gói tìm kiếm thành một retriever và thành một công cụ.

### Tôi có thể truy xuất từ các URL tôi đã biết không?

Có, với [endpoint extract](https://llmwebsearch.com/vi/docs/extract/). Đọc các trang mà bạn đã có URL tốn 1 credit cho mỗi nhóm 3 trang bắt đầu được trả về kèm nội dung, tối đa 20 URL mỗi lượt gọi; các URL bị từ chối hoặc thất bại không được tính.

### LLMWebSearch có lưu trữ các trang nó đọc cho tôi không?

Không. Mỗi lượt gọi để lại một dòng log: thời gian, tài khoản, 60 ký tự đầu của truy vấn, số kết quả và số trang được trả về, và số credit. Các dòng log bị xóa sau 30 ngày. Nội dung của các trang chúng tôi đọc không được lưu. Số tài khoản, đơn hàng, các khoản nạp và tổng credit được giữ trong suốt thời gian tài khoản tồn tại, sau đó chỉ giữ trong thời hạn mà luật kế toán yêu cầu. Cơ quan chức năng chỉ nhận hồ sơ khi pháp luật buộc chúng tôi.

### Tôi có thể giới hạn truy xuất theo một ngôn ngữ hoặc quốc gia không?

Có. Đặt `language` và `country`, ví dụ `language=de` và `country=de` cho kết quả tiếng Đức từ Đức.

---

LLMWebSearch: LLMWebSearch là một web search API cho AI agent, trả về kết quả đã xếp hạng kèm nội dung của các trang hàng đầu ở định dạng Markdown, thanh toán bằng crypto mà không cần tải lên giấy tờ tùy thân. Credit trả trước từ 1,20 US$/1K lượt tìm kiếm không bao giờ hết hạn. Không cần KYC — không ID, không selfie, không giấy tờ. Thanh toán bằng crypto.