Hướng dẫn Công cụ Tìm kiếm Tệp của Google: Xây dựng ứng dụng RAG với Gemini API

Trong hướng dẫn này, tôi sẽ dẫn bạn xây dựng một trợ lý lập tài liệu y khoa với Google File Search. Bạn sẽ thấy cách thiết lập, thực hiện truy vấn và dùng các tính năng nâng cao như chia khúc tuỳ chỉnh và lọc siêu dữ liệu. Kết thúc, bạn sẽ hiểu khi nào nên dùng RAG quản lý sẵn so với tự xây dựng stack của riêng bạn.

Google File Search Tool là gì?

Xây dựng ứng dụng RAG thường đồng nghĩa phải xử lý cơ sở dữ liệu vector, pipeline nhúng và nhiều hạ tầng. Công cụ File Search của Google, ra mắt tháng 11/2025, loại bỏ sự phức tạp này với một hệ thống RAG được quản lý hoàn toàn và tích hợp trực tiếp vào Gemini API.

Công cụ xử lý những phần phức tạp cho bạn: chia khúc tài liệu, tạo embedding và quản lý tìm kiếm ngữ nghĩa mà không cần công cụ bên ngoài như Pinecone hay ChromaDB. Quy trình rất trực quan—tải tệp lên, tạo store, và bắt đầu truy vấn. Bạn cũng có trích dẫn tích hợp sẵn để xác minh nguồn gốc câu trả lời.

Hiểu về RAG và lý do Google đơn giản hoá nó

Gemini File Search tự định vị là một hệ thống RAG được quản lý. Hiểu RAG sẽ giúp bạn dùng công cụ hiệu quả và quyết định khi nào nó phù hợp với bài toán của bạn.

Cốt lõi của retrieval-augmented generation (RAG) là kết nối mô hình ngôn ngữ với tri thức bên ngoài. Trước khi tạo phản hồi, mô hình sẽ truy xuất thông tin liên quan từ tài liệu của bạn, giúp câu trả lời được neo vào dữ liệu thực thay vì chỉ dựa vào dữ liệu huấn luyện.

Thách thức với RAG tự làm

Dù RAG nghe có vẻ đơn giản về khái niệm, tự xây dựng một pipeline RAG đồng nghĩa bạn phải quản lý nhiều thành phần:

• Cơ sở dữ liệu vector: Thiết lập và vận hành các dịch vụ như Pinecone, ChromaDB, hoặc Weaviate để lưu embedding
• Pipeline nhúng: Chuyển tài liệu thành vector số và xử lý cập nhật khi nội dung thay đổi
• Chiến lược chia khúc: Chia tài liệu thành phần cân bằng giữa ngữ cảnh và độ chính xác truy xuất
• Hạ tầng: Theo dõi hiệu năng, tinh chỉnh tham số và xử lý mở rộng khi dữ liệu tăng

Mỗi thành phần đều đòi hỏi chuyên môn và bảo trì liên tục. Dù bạn xây dựng hệ thống sản xuất cần độ tin cậy hay nguyên mẫu cần tốc độ, chi phí hạ tầng vẫn là nút thắt giống nhau.

Vì sao RAG được quản lý lại quan trọng

Các dịch vụ quản lý như Google File Search loại bỏ nút thắt này. Thay vì tinh chỉnh hệ thống truy xuất, bạn chỉ cần viết truy vấn. Thay vì gỡ lỗi pipeline nhúng, bạn xác nhận kết quả. Hạ tầng chạy ở hậu trường, còn bạn tập trung vào logic ứng dụng.

Gemini File Search xử lý phần kỹ thuật phức tạp trong khi bạn kiểm soát điều cốt lõi: tài liệu nào được lập chỉ mục, cách truy vấn và cách dùng kết quả. Sự cân bằng này hiệu quả khi bạn cần chất lượng sản xuất mà không phải gánh vận hành. Để nắm nền tảng RAG sâu hơn, tôi khuyên bạn tham khảo hướng dẫn của DataCamp về agentic RAG.

Cách tốt nhất để hiểu Google File Search là dùng thử. Ở phần tiếp theo, bạn sẽ xây dựng một trợ lý lập tài liệu y khoa hoàn chỉnh, minh hoạ toàn bộ quy trình từ tải tài liệu đến phản hồi được neo nguồn với trích dẫn.

Xây dựng Trợ lý Lập tài liệu Y khoa với Google File Search

Tuyên bố miễn trừ trách nhiệm: Hướng dẫn này trình diễn khả năng của File Search bằng cách sử dụng nhãn thuốc của FDA chỉ nhằm mục đích giáo dục. Trợ lý bạn xây dựng không nhằm sử dụng trong lâm sàng, quyết định chăm sóc bệnh nhân hay chẩn đoán y khoa. Luôn tham khảo ý kiến các chuyên gia y tế có thẩm quyền để được tư vấn y khoa. Hệ thống AI có thể tạo ra thông tin không chính xác ngay cả khi đã neo vào tài liệu nguồn.

Phần này hướng dẫn bạn xây dựng một trợ lý lập tài liệu y khoa hoàn chỉnh bằng File Search. Bạn sẽ làm việc với nhãn thuốc của FDA cho ba loại thuốc phổ biến, tạo ra hệ thống trả lời các câu hỏi về tương tác thuốc, tác dụng phụ và chống chỉ định. Trợ lý cung cấp câu trả lời có thể kiểm chứng bằng cách trích dẫn các đoạn văn bản cụ thể từ tài liệu nguồn.

File Search hoạt động theo hai giai đoạn: bạn lập chỉ mục tài liệu một lần, rồi truy vấn nhiều lần. Bạn sẽ thiết lập hạ tầng lập chỉ mục trước, sau đó tập trung hoàn toàn vào đặt câu hỏi và diễn giải phản hồi có neo nguồn.

Bước 1: Cài đặt API và cấu hình xác thực

Bạn cần Python 3.9 trở lên. Cài đặt Google Generative AI SDK và các phụ thuộc:

pip install google-genai python-dotenvĐược hỗ trợ bởi

Lấy khóa API của bạn từ Google AI Studio. Lưu nó trong tệp .env ở thư mục dự án của bạn:

GOOGLE_API_KEY=your_api_key_hereĐược hỗ trợ bởi

Thiết lập import và khởi tạo client:

from google import genai
from google.genai import types
import time
from dotenv import load_dotenv

load_dotenv()
client = genai.Client()Được hỗ trợ bởi

Đối tượng genai.Client() xử lý xác thực tự động bằng biến môi trường của bạn. Bạn sẽ dùng đối tượng client này cho mọi thao tác File Search.

Bước 2: Tạo một store File Search

Tạo một store để chứa các tài liệu đã lập chỉ mục:

file_search_store = client.file_search_stores.create(
    config={"display_name": "fda-drug-labels"}
)
print(f"Created store: {file_search_store.name}")Được hỗ trợ bởi

Một store File Search hoạt động như vùng chứa cho các tài liệu đã lập chỉ mục của bạn. Khác với việc tải tệp tạm thời sẽ hết hạn sau 48 giờ, các store tồn tại vô thời hạn. Điều này có nghĩa bạn lập chỉ mục tài liệu một lần và truy vấn hàng nghìn lần mà không cần tải lại hay xử lý lại.

Thuộc tính file_search_store.name chứa một định danh duy nhất bạn sẽ tham chiếu khi truy vấn. Nó có dạng fileSearchStores/fdadruglabels-abc123. Hãy lưu giá trị này nếu bạn cần truy vấn store từ phiên làm việc khác.

Bước 3: Tải lên và lập chỉ mục tài liệu PDF

Trong hướng dẫn này, bạn sẽ làm việc với ba nhãn thuốc đã được FDA phê duyệt. Tải các PDF này từ website của FDA:

• Metformin (Glucophage) - Thuốc điều trị tiểu đường
• Atorvastatin (Lipitor) - Thuốc hạ cholesterol
• Lisinopril (Zestril) - Thuốc hạ huyết áp

Lưu chúng trong thư mục dự án của bạn, sau đó tải lên store File Search:

pdf_files = ["metformin.pdf", "atorvastatin.pdf", "lisinopril.pdf"]

for pdf_file in pdf_files:
    operation = client.file_search_stores.upload_to_file_search_store(
        file=pdf_file,
        file_search_store_name=file_search_store.name,
        config={"display_name": pdf_file.replace(".pdf", "")},
    )

    # Wait for indexing to complete
    while not operation.done:
        time.sleep(3)
        operation = client.operations.get(operation)

    print(f"{pdf_file} indexed")Được hỗ trợ bởi

Trong quá trình tải lên, File Search chia mỗi PDF thành các khúc và chuyển các đoạn đó thành embedding bằng mô hình gemini-embedding-001. Các embedding là biểu diễn số học nắm bắt ý nghĩa ngữ nghĩa, cho phép hệ thống tìm các đoạn phù hợp ngay cả khi câu hỏi của bạn không khớp chính xác câu chữ trong tài liệu.

Mẫu thăm dò (while not operation.done) xử lý tính bất đồng bộ của quá trình lập chỉ mục. Tài liệu lớn mất nhiều thời gian hơn để xử lý, nên API trả về ngay, và bạn kiểm tra trạng thái hoàn thành định kỳ. Với hệ thống sản xuất, hãy cân nhắc thêm logic timeout để tránh vòng lặp vô hạn.

Mỗi khúc giữ lại siêu dữ liệu liên kết nó với tài liệu nguồn và vị trí. Siêu dữ liệu này trở nên quan trọng khi bạn truy cập trích dẫn sau đó.

Bước 4: Truy vấn thông tin trong một tài liệu

Giờ hãy truy vấn các tài liệu đã lập chỉ mục:

query1 = "What are the contraindications for metformin?"

response1 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query1,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response1.text)Được hỗ trợ bởi

Điều này sẽ in ra câu trả lời đã tạo:

Metformin is contraindicated in several conditions:

* Severe renal impairment (eGFR below 30 mL/min/1.73 m2)
* Acute or chronic metabolic acidosis
* Hypersensitivity to metforminĐược hỗ trợ bởi

File Search truy xuất các khúc có độ tương đồng ngữ nghĩa cao nhất trong tài liệu của bạn và cung cấp chúng như ngữ cảnh cho gemini-2.5-flash, mô hình sẽ tạo câu trả lời. Cấu hình mảng tools cho mô hình biết phải dùng File Search trong quá trình tạo. Bạn có thể kết hợp File Search với các công cụ khác như thực thi mã hoặc Google Search trong cùng một yêu cầu.

Bước 5: Truy cập trích dẫn và siêu dữ liệu neo nguồn

Trích xuất những tài liệu đã góp phần tạo nên câu trả lời:

print("Sources used:")
for i, chunk in enumerate(response1.candidates[0].grounding_metadata.grounding_chunks, 1):
    source_name = chunk.retrieved_context.title
    print(f"  [{i}] {source_name}")Được hỗ trợ bởi

Kết quả:

Sources used:
  [1] metformin
  [2] atorvastatinĐược hỗ trợ bởi

Mỗi khúc trong siêu dữ liệu neo nguồn bao gồm tiêu đề tài liệu nguồn và đoạn văn bản cụ thể đã góp phần vào câu trả lời. Điều này tạo ra đường dẫn xác minh từ phản hồi được tạo quay lại tài liệu gốc của bạn—cần thiết cho các ứng dụng y tế, pháp lý hoặc tài chính nơi độ chính xác là quan trọng.

Mảng grounding_chunks chứa mọi đoạn được truy xuất, sắp theo mức độ liên quan. Dù truy vấn hỏi cụ thể về metformin, File Search cũng truy xuất nội dung từ tài liệu atorvastatin, có thể vì nó chứa thông tin chống chỉ định liên quan. Điều này cho thấy cách truy xuất ngữ nghĩa: hệ thống tìm nội dung liên quan về mặt khái niệm, không chỉ khớp từ khoá.

Bước 6: Truy vấn trên nhiều tài liệu

Kiểm thử một câu hỏi tương tác thuốc đa tài liệu:

query2 = "Can a patient take both atorvastatin and metformin together? Are there any drug interactions?"

response2 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query2,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response2.text)Được hỗ trợ bởi

Cùng một mẫu API giờ sẽ lấy dữ liệu từ nhiều tài liệu và tổng hợp thông tin. Truy cập các đoạn văn bản đã truy xuất:

print("Sources used:")

for i, chunk in enumerate(response2.candidates[0].grounding_metadata.grounding_chunks, 1):
    source_name = chunk.retrieved_context.title
    source_text = chunk.retrieved_context.text[:100] + "..."
    print(f"  [{i}] {source_name}")
    print(f"      {source_text}")Được hỗ trợ bởi

Kết quả hiển thị trích đoạn từ cả hai nhãn thuốc:

Sources used:
  [1] atorvastatin
      Concomitant use with diabetes medications is generally safe but monitor glucose levels...
  [2] metformin
      Carbonic anhydrase inhibitors may increase the risk of lactic acidosis...Được hỗ trợ bởi

File Search truy xuất các phần liên quan từ cả hai tài liệu, và mô hình tổng hợp chúng thành câu trả lời mạch lạc. Thuộc tính retrieved_context.text cung cấp chính xác đoạn văn đã dùng, cho phép bạn xác minh mô hình không bịa thông tin.

Bước 7: Thực hiện so sánh xuyên tài liệu

Đặt một câu hỏi phân tích đòi hỏi so sánh cả ba tài liệu:

query3 = "Which medications have muscle-related side effects?"

response3 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query3,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response3.text)

# Check which documents were consulted
metadata = response3.candidates[0].grounding_metadata
for i, chunk in enumerate(metadata.grounding_chunks, 1):
    print(f"  [{i}] {chunk.retrieved_context.title}")Được hỗ trợ bởi

Kết quả xác định atorvastatin có tác dụng phụ liên quan đến cơ (đau cơ, bệnh cơ, tiêu cơ vân) và xác nhận các thuốc còn lại không liệt kê tác dụng như vậy. Siêu dữ liệu neo nguồn cho thấy File Search đã tham khảo cả ba tài liệu để trả lời câu hỏi so sánh.

Bạn đã xây dựng xong một trợ lý lập tài liệu y khoa hoạt động. Quy trình cốt lõi nhất quán: cấu hình công cụ File Search trong lời gọi generate_content(), lấy văn bản phản hồi và truy cập siêu dữ liệu neo nguồn để xác minh. Store tồn tại trên máy chủ của Google, nên bạn có thể truy vấn từ các phiên sau mà không cần lập chỉ mục lại.

Tiếp theo, bạn sẽ khám phá các tính năng nâng cao như cấu hình chia khúc tuỳ chỉnh và lọc siêu dữ liệu để kiểm soát hành vi truy xuất chi tiết hơn.

Tính năng nâng cao và tuỳ biến của Google File Search Tool

Quy trình File Search cơ bản đáp ứng phần lớn trường hợp, nhưng hệ thống sản xuất thường cần kiểm soát tinh tế hơn đối với hành vi truy xuất. Phần này cho thấy cách tuỳ chỉnh chiến lược chia khúc, lọc tài liệu bằng siêu dữ liệu, tối ưu hiệu năng và quản lý nhiều store cho các bài toán khác nhau.

Cấu hình chia khúc tuỳ chỉnh

File Search tự động chia tài liệu thành các khúc trong quá trình lập chỉ mục. Mặc định, nó dùng chiến lược chia khúc tối ưu cho tài liệu chung, nhưng bạn có thể tuỳ chỉnh khi các loại tài liệu cụ thể cần cách xử lý khác.

Xem lại ví dụ trợ lý y khoa. Nhãn thuốc chứa thông tin kỹ thuật dày đặc trong bảng và các đoạn ngắn. Khúc nhỏ hơn giúp bạn truy xuất chính xác thông tin như liều dùng cụ thể hoặc chống chỉ định mà không kéo theo ngữ cảnh không liên quan. Khúc lớn phù hợp hơn cho phần mô tả cần nhiều ngữ cảnh để hiểu đúng.

Cấu hình tham số chia khúc khi tải tài liệu lên:

operation = client.file_search_stores.upload_to_file_search_store(
    file="metformin.pdf",
    file_search_store_name=file_search_store.name,
    config={
        "display_name": "metformin",
        "chunking_config": {
            "white_space_config": {
                "max_tokens_per_chunk": 200,
                "max_overlap_tokens": 20
            }
        }
    }
)Được hỗ trợ bởi

Tham số chunking_config kiểm soát cách File Search chia tài liệu của bạn. max_tokens_per_chunk đặt kích thước tối đa của mỗi khúc, trong khi max_overlap_tokens xác định mức nội dung chồng lặp giữa các khúc liên tiếp. Phần chồng lặp này đảm bảo thông tin trải qua ranh giới khúc không bị mất khi truy xuất.

Sự đánh đổi rất quan trọng: khúc ngắn cho truy xuất chính xác hơn nhưng có thể bỏ lỡ ngữ cảnh rộng hơn, trong khi khúc lớn giữ nhiều ý nghĩa hơn nhưng có thể kèm thông tin không liên quan. 

Với tài liệu kỹ thuật có ranh giới mục rõ ràng, dùng khúc nhỏ (150-250 token). Với tài liệu mang tính tường thuật như bài nghiên cứu hay báo cáo, khúc lớn (400-600 token) sẽ giữ mạch lập luận và ngữ cảnh. Tài liệu chính thức về File Search cung cấp hướng dẫn bổ sung về chọn kích thước khúc cho các loại tài liệu khác nhau.

Lọc siêu dữ liệu

Khi store của bạn chứa hàng chục hoặc hàng trăm tài liệu, lọc siêu dữ liệu thu hẹp phạm vi truy xuất trước khi tìm kiếm ngữ nghĩa chạy. Điều này cải thiện độ chính xác và giảm thời gian xử lý.

Thêm siêu dữ liệu trong lúc tải tài liệu để có thể lọc về sau:

operation = client.file_search_stores.upload_to_file_search_store(
    file="metformin.pdf",
    file_search_store_name=file_search_store.name,
    config={
        "display_name": "metformin",
        "custom_metadata": [
            {"key": "category", "string_value": "diabetes"},
            {"key": "year", "numeric_value": 2017},
            {"key": "drug_class", "string_value": "biguanide"}
        ]
    }
)Được hỗ trợ bởi

Tham số custom_metadata nhận một mảng các cặp khoá-giá trị. Dùng string_value cho siêu dữ liệu dạng văn bản như danh mục hay nhóm thuốc, và numeric_value cho năm, phiên bản hoặc dữ liệu số khác.

Truy vấn với bộ lọc siêu dữ liệu để chỉ tìm trong tài liệu liên quan:

query = "What are the common side effects?"

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name],
                    metadata_filter="category=diabetes"
                )
            )
        ]
    )
)Được hỗ trợ bởi

Tham số metadata_filter giới hạn truy xuất vào các tài liệu khớp tiêu chí đã chỉ định. Trong ví dụ này, File Search chỉ xem xét các tài liệu có category=diabetes, bỏ qua các thuốc hạ huyết áp và cholesterol dù chúng nằm trong cùng store.

Điều này trở nên quan trọng khi store chứa tài liệu dị thể. Một cơ sở tri thức y khoa có thể gồm nhãn thuốc, bài nghiên cứu và hướng dẫn lâm sàng. Lọc theo loại tài liệu đảm bảo bạn lấy thông tin liều dùng từ nhãn thuốc, không phải tóm tắt nghiên cứu.

Bạn có thể kết hợp lọc siêu dữ liệu với khả năng tìm kiếm ngữ nghĩa đầy đủ. Bộ lọc chạy trước để chọn tài liệu ứng viên, rồi tìm kiếm ngữ nghĩa sẽ tìm các đoạn phù hợp nhất trong những tài liệu đó.

Tối ưu hiệu năng

Hiệu năng File Search phụ thuộc vào kích thước store, độ phức tạp truy vấn và lựa chọn mô hình. Tuân theo các hướng dẫn này sẽ giữ truy xuất nhanh và chi phí hợp lý.

Giới hạn kích thước store: Giữ từng store dưới 20GB để có độ trễ truy xuất tối ưu. File Search lưu embedding cùng với tài liệu của bạn, và embedding xấp xỉ gấp ba lần kích thước tệp gốc. Bộ sưu tập PDF 7GB tạo ra khoảng 21GB dữ liệu lưu trữ sau khi lập chỉ mục, vượt quá mức khuyến nghị.

Khi bạn chạm tới giới hạn này, hãy tạo các store riêng biệt được tổ chức theo danh mục, giai đoạn thời gian hoặc mẫu truy cập. Với trợ lý y khoa, bạn có thể tạo store riêng cho các nhóm thuốc khác nhau thay vì lập chỉ mục mọi thuốc có sẵn trong một store duy nhất.

Cấu trúc chi phí: File Search tính phí $0,15 trên mỗi 1 triệu token cho việc lập chỉ mục. Sau khi lập chỉ mục, bạn có thể chạy hàng nghìn truy vấn mà không tốn thêm chi phí lập chỉ mục. Mô hình giá này có lợi cho khối lượng đọc lớn, nơi bạn truy vấn cùng tài liệu lặp lại nhiều lần.

Lựa chọn mô hình: Dùng gemini-2.5-flash cho hầu hết truy vấn. Nó xử lý yêu cầu trong 1–2 giây và rẻ hơn đáng kể so với gemini-2.5-pro. Dành gemini-2.5-pro cho những truy vấn đòi hỏi suy luận sâu trên nhiều nguồn hoặc xử lý tác vụ tổng hợp cực kỳ phức tạp. Với ứng dụng lưu lượng lớn, chênh lệch chi phí giữa mô hình quan trọng hơn chi phí lập chỉ mục.

Theo dõi kích thước store khi bạn thêm tài liệu. Bạn có thể kiểm tra qua API, dù phép tính kích thước diễn ra ở backend của Google và có thể không phản ánh ngay sau khi tải lên. Để biết đầy đủ thông số kỹ thuật và giới hạn, hãy tham khảo tài liệu Gemini File API.

Quản lý nhiều store

Mỗi dự án Google Cloud hỗ trợ tối đa 10 store File Search. Nhiều store cho phép bạn tách tài liệu theo kiểm soát truy cập, yêu cầu hiệu năng hoặc tổ chức logic.

Tạo các store chuyên biệt cho những bài toán khác nhau:

# Create separate stores for different document categories
diabetes_store = client.file_search_stores.create(
    config={"display_name": "diabetes-medications"}
)

cardio_store = client.file_search_stores.create(
    config={"display_name": "cardiovascular-medications"}
)Được hỗ trợ bởi

Truy vấn nhiều store trong một yêu cầu:

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="What medications treat both diabetes and heart disease?",
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[
                        diabetes_store.name,
                        cardio_store.name
                    ]
                )
            )
        ]
    )
)Được hỗ trợ bởi

File Search truy xuất từ tất cả các store đã chỉ định và tổng hợp kết quả. Siêu dữ liệu neo nguồn xác định trích dẫn đến từ store nào, đảm bảo khả năng truy vết đầy đủ. 

Các store tồn tại vô thời hạn và cần xoá thủ công khi không còn cần thiết, khiến chúng phù hợp cho ứng dụng sản xuất nơi tài liệu cần được truy vấn xuyên suốt các phiên và lần triển khai.

Tiếp theo, bạn sẽ thấy File Search so với các giải pháp RAG khác thế nào và khi nào nên chọn phương án quản lý hay tự xây dựng.

Google File Search Tool so với các công cụ Tìm kiếm Tệp và RAG khác

File Search không phải lựa chọn duy nhất để xây dựng ứng dụng RAG. Hiểu cách nó so với các phương án thay thế sẽ giúp bạn chọn công cụ phù hợp. Hãy so sánh cách tiếp cận của Google với giải pháp của OpenAI và các bản dựng tuỳ chỉnh truyền thống.

Google File Search vs OpenAI File Search

Cả hai đều cung cấp RAG dạng dịch vụ, nhưng đi theo hướng khác nhau về giá và khả năng.

Giá: Google tính phí một lần khi lập chỉ mục ($2,50 cho mỗi nghìn truy vấn cộng $0,10 mỗi GB lưu trữ hằng ngày). Nếu bạn chạy nhiều truy vấn nhưng hiếm khi cập nhật tài liệu, mô hình của Google sẽ tiết kiệm. Nếu bạn liên tục lập chỉ mục lại, bài toán chi phí trở nên thú vị.

Mức độ cấu hình: Google giữ mọi thứ đơn giản với chia khúc tự động và cấu hình hạn chế. OpenAI cho bạn kiểm soát nhiều hơn. Bạn có thể đặt kích thước khúc (mặc định 800 token) và chồng lặp (400 token). OpenAI còn chạy tìm kiếm lai kết hợp vector và từ khoá, trong khi Google chỉ dựa vào tìm kiếm ngữ nghĩa. Điều này quan trọng khi truy vấn của bạn chứa thuật ngữ kỹ thuật cụ thể hoặc mã sản phẩm.

Định dạng tệp: Google xử lý hơn 150 loại tệp, gồm tệp mã và nhiều định dạng tài liệu. OpenAI hỗ trợ sáu loại: TXT, MD, HTML, DOCX, PPTX và PDF. Cả hai đều không xử lý tốt dữ liệu có cấu trúc như CSV hay JSONL. Đây là nơi các bản dựng tuỳ chỉnh vượt trội.

Tích hợp: Google kết nối với các mô hình Gemini và dịch vụ Google Cloud. OpenAI kết nối với hệ mô hình của họ và Azure. Cả hai đều cung cấp trích dẫn và theo dõi nguồn.

Khác biệt thực sự nằm ở sự đơn giản so với mức độ kiểm soát. Google gói gọn mọi thứ trong một lời gọi API. OpenAI cho phép bạn tinh chỉnh truy xuất với cái giá là tăng độ phức tạp. Không có người thắng tuyệt đối. Tuỳ dự án bạn cần tốc độ hay tuỳ biến.

Khả năng của RAG tuỳ chỉnh

Tự xây dựng hệ thống RAG với công cụ như LangChain mở ra các khả năng mà dịch vụ lưu trữ không có. Khoá học RAG với LangChain của DataCamp hướng dẫn chi tiết cách tiếp cận này.

Bản dựng tuỳ chỉnh cho phép các kỹ thuật nâng cao:

• Chia ngữ nghĩa phát hiện điểm chuyển chủ đề thay vì cắt theo độ dài cố định
• Chia khúc theo token tôn trọng chính xác cửa sổ ngữ cảnh của mô hình
• Truy xuất lai kết hợp tìm kiếm từ khoá BM25 với vector đặc
• Biến đổi truy vấn như HyDE tạo câu trả lời giả định để cải thiện tìm kiếm
• Graph RAG biểu diễn tài liệu dưới dạng mạng thực thể và quan hệ

Hướng dẫn của DataCamp về cải thiện hiệu năng RAG khám phá các kỹ thuật này với ví dụ cho thấy cải thiện chất lượng đo lường được. Đổi lại là độ phức tạp vận hành: bạn phải theo dõi hiệu năng cơ sở dữ liệu, tinh chỉnh mô hình nhúng và xử lý cập nhật trên nhiều dịch vụ.

Khi nào dùng từng cách tiếp cận

Chọn công cụ lưu trữ như File Search khi:

• Xây dựng nguyên mẫu hoặc proof-of-concept nơi tốc độ quan trọng
• Bài toán của bạn phù hợp với mẫu chuẩn (H&Đ trên tài liệu, cơ sở tri thức, tìm kiếm tài liệu)
• Đội ngũ của bạn thiếu chuyên môn sâu về RAG
• Bạn muốn chi phí dự đoán được và tối thiểu hoá vận hành

Tự xây dựng khi:

• Bạn cần chia khúc nâng cao hoặc phương pháp truy xuất chuyên biệt
• Làm việc với dữ liệu có cấu trúc hoặc định dạng tệp bất thường
• Xây dựng agentic RAG kết hợp nhiều chiến lược
• Tối ưu chi phí ở quy mô cực lớn đủ bù đắp đầu tư kỹ thuật
• Tuân thủ yêu cầu hạ tầng hoặc mô hình cụ thể

Hầu hết dự án bắt đầu bằng giải pháp lưu trữ và chỉ chuyển sang bản dựng tuỳ chỉnh khi yêu cầu bắt buộc. Các kỹ thuật từ RAG tuỳ chỉnh (chia khúc thông minh, tìm kiếm lai, tối ưu truy vấn) vẫn định hướng cách bạn dùng công cụ lưu trữ. Hiểu toàn cảnh sẽ giúp bạn đưa ra lựa chọn tốt hơn khi nhu cầu phát triển.

Kết luận

Bạn đã xây dựng một hệ thống RAG hoàn chỉnh bằng Google File Search Tool, từ lập chỉ mục nhãn thuốc của FDA đến truy vấn kèm trích dẫn. Trợ lý y khoa cho thấy cách dịch vụ quản lý xử lý hạ tầng trong khi bạn tập trung vào logic ứng dụng.

File Search hoạt động tốt khi bạn cần RAG đáng tin cậy mà không phải quản lý cơ sở dữ liệu vector hay pipeline nhúng. Lưu trữ miễn phí và embedding cho truy vấn giúp chi phí có thể dự đoán. Store tồn tại lâu dài loại bỏ chi phí lập chỉ mục lại, cho phép bạn mở rộng truy vấn mà không tăng bảo trì hạ tầng.

Trước khi triển khai sản xuất, hãy bổ sung các biện pháp bảo vệ thiết yếu mà hướng dẫn đã lược bớt cho ngắn gọn. Triển khai xử lý lỗi với timeout cho thao tác tải lên và khối try-catch quanh lời gọi API. Cân nhắc tác động quyền riêng tư dữ liệu khi tải tài liệu lên máy chủ của Google, nhất là với nội dung nhạy cảm. Thêm xác thực để đảm bảo có siêu dữ liệu neo nguồn trước khi truy cập trích dẫn. Kiểm thử kỹ với chuyên gia lĩnh vực để phát hiện các trường hợp mô hình tạo câu trả lời có vẻ hợp lý nhưng sai, dù đã có neo nguồn.

Bước tiếp theo, hãy mở rộng trợ lý của bạn bằng lọc siêu dữ liệu để tổ chức tài liệu theo danh mục. Thử nghiệm kích thước khúc phù hợp với loại tài liệu của bạn. Các kỹ thuật bạn học ở đây áp dụng cho cả bot hỗ trợ, tìm kiếm tài liệu hay trợ lý tri thức.