Function calling là cơ chế cho phép mô hình AI 'nói' với phần mềm của bạn rằng: hãy chạy hàm này với các tham số này. Mô hình không tự kết nối vào cơ sở dữ liệu, không tự bấm nút. Nó chỉ sinh ra một đoạn dữ liệu có cấu trúc, phần còn lại do ứng dụng xử lý.
Một chatbot thông thường chỉ dựa vào kiến thức đã học và nội dung trong cuộc trò chuyện. Hỏi 'đơn hàng DH1024 giao chưa' thì nó chỉ đoán hoặc xin lỗi vì không biết. Khi có function calling, mô hình nhận ra câu hỏi cần dữ liệu thật, trả về yêu cầu gọi công cụ tra_don_hang với tham số ma_don = DH1024. Ứng dụng gọi phần mềm bán hàng, lấy trạng thái, gửi lại cho mô hình để diễn đạt thành câu trả lời tự nhiên.
OpenAI dùng từ function calling, Anthropic gọi là tool use, Google Gemini cũng dùng function calling. Các giao thức như MCP chuẩn hóa cách mô tả và cung cấp công cụ cho nhiều ứng dụng AI. Dù tên khác, bản chất đều là: mô hình chọn công cụ, ứng dụng thực thi, kết quả quay lại mô hình.
"}, {"h2": "Luồng hoạt động của function calling diễn ra thế nào", "html": "Một lượt gọi công cụ điển hình gồm năm bước:
tao_lich_hen với chi nhánh, ngày, buổi. Nếu thiếu thông tin, mô hình có thể hỏi lại người dùng.Một câu hỏi có thể dẫn tới nhiều lượt gọi liên tiếp. AI agent thực chất là vòng lặp này chạy nhiều lần: gọi công cụ, xem kết quả, quyết định bước tiếp theo cho đến khi xong việc.
"}, {"h2": "Mô tả công cụ thế nào để AI chọn đúng", "html": "Chất lượng function calling phụ thuộc rất nhiều vào cách bạn mô tả công cụ. Mô hình chỉ đọc tên, mô tả và lược đồ tham số để quyết định. Mô tả mơ hồ dẫn tới gọi sai hàm hoặc điền sai tham số.
tra_ton_kho tốt hơn xu_ly_kho làm đủ thứ.tra_don_hang: Tra trạng thái giao hàng của một đơn theo mã đơn dạng DHxxxx. Trả về trạng thái, đơn vị vận chuyển, ngày dự kiến. Một dòng mô tả cụ thể như vậy giúp mô hình hiểu đúng phạm vi.
Function calling là nền tảng cho hầu hết ứng dụng AI 'làm được việc' chứ không chỉ trò chuyện. Một số tình huống phổ biến với công ty 20–50 người hoặc cửa hàng:
", "table": {"caption": "Ví dụ công cụ cho từng bộ phận", "head": ["Bộ phận", "Công cụ AI được gọi", "Mức rủi ro"], "rows": [["Chăm sóc khách hàng", "Tra đơn, tra bảo hành, tạo phiếu hỗ trợ", "Thấp đến trung bình"], ["Bán hàng", "Tra tồn kho, tạo báo giá nháp, ghi lead vào CRM", "Trung bình"], ["Kế toán", "Đọc hóa đơn, tra công nợ, đối chiếu sổ phụ", "Trung bình đến cao"], ["Nhân sự", "Tra số ngày phép, nộp đơn nghỉ", "Trung bình"], ["IT nội bộ", "Reset mật khẩu, kiểm tra trạng thái máy in, mở ticket", "Cao nếu có quyền quản trị"]]}}, {"h2": "Phân biệt function calling, structured output và MCP", "html": "Ba khái niệm này hay bị nhầm vì đều liên quan đến dữ liệu có cấu trúc.
Nói ngắn gọn: structured output trả lời câu hỏi 'dữ liệu có dạng gì', function calling trả lời 'cần làm gì tiếp theo', MCP trả lời 'công cụ được cung cấp theo chuẩn nào'. Một hệ thống thực tế thường dùng cả ba.
Nếu không có lập trình viên, các nền tảng như n8n, Make, Dify hay Flowise cho phép khai báo công cụ bằng giao diện kéo thả. Bên dưới chúng vẫn dùng function calling của mô hình.
"}, {"h2": "Rủi ro bảo mật khi cho AI gọi công cụ", "html": "Khi AI có quyền gọi công cụ, câu trả lời sai không còn chỉ là chữ sai, mà có thể thành hành động sai. Các rủi ro chính:
Đừng bắt đầu bằng một agent làm mọi thứ. Chọn một quy trình hẹp, tần suất cao, rủi ro thấp.
Đo hiệu quả bằng tỷ lệ gọi đúng công cụ, tỷ lệ câu hỏi phải chuyển người, thời gian phản hồi và số sự cố do tham số sai.
"}, {"h2": "Khi nào không nên dùng function calling", "html": "Function calling không phải lúc nào cũng là lựa chọn tốt nhất.
Cách tiếp cận hợp lý là dùng quy trình cố định cho phần lặp lại và để AI quyết định ở những điểm cần hiểu ngôn ngữ tự nhiên, như phân loại yêu cầu hoặc trích xuất thông tin từ tin nhắn khách.
"} ], "tip": "Hãy bắt đầu với công cụ chỉ đọc và log mọi lượt gọi trong ít nhất hai tuần trước khi cấp quyền ghi. Đọc log thật là cách nhanh nhất để biết mô tả công cụ của bạn có đủ rõ hay chưa.", "faq": [ {"q": "Function calling có phải là AI tự chạy code không?", "a": "Không. Mô hình chỉ sinh ra yêu cầu gọi hàm kèm tham số. Ứng dụng của bạn quyết định có thực thi hay không và thực thi thế nào."}, {"q": "Mô hình AI nào hỗ trợ function calling?", "a": "Phần lớn mô hình thương mại lớn và nhiều mô hình mở hiện hỗ trợ tool use. Mức độ chính xác khác nhau theo mô hình và phiên bản, nên kiểm tra tài liệu chính thức và tự thử với bộ câu hỏi của bạn."}, {"q": "Function calling có tốn thêm token không?", "a": "Có. Danh sách công cụ, mô tả, lược đồ tham số và kết quả trả về đều nằm trong ngữ cảnh nên tính token. Càng nhiều công cụ và kết quả càng dài thì chi phí càng tăng."}, {"q": "Có thể dùng function calling với mô hình chạy cục bộ không?", "a": "Có, nhiều mô hình mở chạy qua Ollama hoặc vLLM hỗ trợ tool calling. Mô hình nhỏ thường gọi sai tham số nhiều hơn, nên cần kiểm thử kỹ và kiểm tra tham số chặt hơn."}, {"q": "Function calling khác AI agent thế nào?", "a": "Function calling là cơ chế một lần gọi công cụ. AI agent là hệ thống dùng cơ chế đó nhiều lần trong vòng lặp, tự lên kế hoạch và quyết định bước tiếp theo."}, {"q": "Làm sao ngăn AI gọi công cụ nguy hiểm?", "a": "Không cấp công cụ nguy hiểm nếu chưa cần, dùng quyền tối thiểu, kiểm tra tham số ở phía ứng dụng và bắt buộc người xác nhận với thao tác ghi, xóa, thanh toán."} ], "sources": [ {"t": "OpenAI – Function calling guide", "u": "https://platform.openai.com/docs/guides/function-calling"}, {"t": "Anthropic – Tool use documentation", "u": "https://docs.anthropic.com"}, {"t": "Model Context Protocol", "u": "https://modelcontextprotocol.io"}, {"t": "JSON Schema", "u": "https://json-schema.org"} ], "related": ["mcp-la-gi", "structured-output-json-la-gi", "ai-agent-hoat-dong-the-nao", "ai-agent-la-gi", "prompt-injection-la-gi", "api-ai-la-gi", "xay-ai-agent-bang-n8n", "agentic-workflow-la-gi"] }, { "id": 2167, "slug": "graphrag-la-gi", "title": "GraphRAG là gì? RAG kết hợp đồ thị tri thức cho câu hỏi phức tạp", "meta_desc": "GraphRAG là gì: kỹ thuật RAG kết hợp đồ thị tri thức giúp AI trả lời câu hỏi tổng hợp, nhiều mối quan hệ. So sánh với RAG thường, chi phí và khi nào nên dùng.", "excerpt": "RAG thông thường tìm vài đoạn văn giống câu hỏi nhất, nhưng gặp khó khi câu hỏi cần nối nhiều thông tin rải rác. GraphRAG thêm lớp đồ thị tri thức để AI hiểu các thực thể và quan hệ giữa chúng.", "answer": "GraphRAG là kỹ thuật RAG (truy xuất tăng cường cho sinh văn bản) có thêm đồ thị tri thức: hệ thống dùng AI trích xuất thực thể như người, sản phẩm, hợp đồng, khách hàng và quan hệ giữa chúng từ tài liệu, lưu thành đồ thị, rồi dùng đồ thị này khi tìm ngữ cảnh để trả lời. GraphRAG mạnh ở câu hỏi tổng hợp và nhiều bước, ví dụ 'những khách hàng nào liên quan đến các hợp đồng có điều khoản phạt chậm giao'. Đổi lại, chi phí xây dựng và cập nhật cao hơn RAG thường, nên chỉ đáng dùng khi dữ liệu có nhiều mối quan hệ chéo.", "kws": ["GraphRAG là gì", "RAG đồ thị tri thức", "GraphRAG vs RAG", "knowledge graph RAG"], "sections": [ {"h2": "GraphRAG là gì và ra đời để giải quyết vấn đề gì", "html": "GraphRAG là cách tổ chức tri thức cho RAG dưới dạng đồ thị gồm các nút (thực thể) và cạnh (quan hệ), thay vì chỉ là các đoạn văn rời rạc được biến thành vector. Khái niệm này được biết đến rộng rãi sau khi Microsoft Research công bố phương pháp và mã nguồn GraphRAG, sau đó nhiều thư viện và cơ sở dữ liệu đồ thị cũng hỗ trợ cách làm tương tự.
Vấn đề GraphRAG hướng tới là điểm yếu của RAG dựa trên vector. RAG thường lấy vài đoạn văn có nghĩa gần câu hỏi nhất. Nó làm tốt câu hỏi kiểu 'chính sách đổi trả trong bao nhiêu ngày'. Nhưng với câu hỏi như 'tóm tắt các vấn đề chính khách hàng phàn nàn trong năm' hay 'nhà cung cấp nào xuất hiện trong cả hợp đồng thuê kho và biên bản sự cố', câu trả lời nằm rải rác ở hàng chục tài liệu. Lấy 5 đoạn giống nhất không đủ để thấy bức tranh.
Đồ thị cho phép hệ thống đi theo quan hệ: từ khách hàng A sang hợp đồng, từ hợp đồng sang điều khoản, từ điều khoản sang sự cố liên quan. Nhờ vậy AI gom được ngữ cảnh có liên kết logic chứ không chỉ giống nhau về chữ.
"}, {"h2": "GraphRAG hoạt động qua những bước nào", "html": "Một hệ thống GraphRAG thường có hai giai đoạn: lập chỉ mục và truy vấn.
Cuối cùng, ngữ cảnh lấy từ đồ thị được đưa vào mô hình để viết câu trả lời, giống bước sinh văn bản của RAG.
"}, {"h2": "So sánh GraphRAG với RAG thông thường", "html": "Hai cách tiếp cận không thay thế hoàn toàn nhau. Nhiều hệ thống thực tế kết hợp cả hai: tìm vector cho câu hỏi đơn giản, đi theo đồ thị cho câu hỏi cần nối thông tin.
", "table": {"caption": "RAG vector và GraphRAG theo tiêu chí", "head": ["Tiêu chí", "RAG thông thường", "GraphRAG"], "rows": [["Câu hỏi tra cứu một ý", "Tốt, nhanh", "Tốt nhưng thừa công"], ["Câu hỏi tổng hợp nhiều tài liệu", "Hay bỏ sót", "Mạnh hơn rõ rệt"], ["Câu hỏi về quan hệ nhiều bước", "Yếu", "Mạnh"], ["Chi phí lập chỉ mục", "Thấp, chủ yếu tính embedding", "Cao, cần mô hình đọc toàn bộ tài liệu"], ["Cập nhật khi tài liệu đổi", "Đơn giản", "Phức tạp hơn, có thể phải tính lại cụm"], ["Khả năng giải thích nguồn", "Trỏ về đoạn văn", "Trỏ về thực thể, quan hệ và đoạn văn"]]}}, {"h2": "Ví dụ GraphRAG trong doanh nghiệp Việt Nam", "html": "Hãy xem vài tình huống mà đồ thị tri thức tạo khác biệt rõ.
Ngược lại, kho câu hỏi thường gặp của cửa hàng bán lẻ, nội quy công ty, hướng dẫn sử dụng sản phẩm thường không cần GraphRAG. RAG thông thường với chunking tốt và reranker đã đủ.
"}, {"h2": "Chi phí và độ phức tạp cần lường trước", "html": "GraphRAG hấp dẫn trên lý thuyết nhưng có chi phí thật cần tính trước khi chọn.
Vì vậy, GraphRAG nên là bước nâng cấp sau khi RAG cơ bản đã chạy ổn, không phải điểm xuất phát.
"}, {"h2": "Lộ trình thử GraphRAG từng bước", "html": "Nếu bạn đã có chatbot tài liệu nội bộ và thấy nó yếu ở câu hỏi tổng hợp, có thể thử theo lộ trình sau:
Nếu phần lớn câu hỏi thất bại thực ra do tài liệu thiếu, lỗi thời hoặc chia đoạn kém, hãy sửa dữ liệu trước. GraphRAG không bù được dữ liệu nguồn kém chất lượng.
"}, {"h2": "Khi nào doanh nghiệp không cần GraphRAG", "html": "Phần lớn doanh nghiệp nhỏ và vừa chưa cần GraphRAG ở giai đoạn đầu. Bạn có thể bỏ qua nếu:
Điểm cuối rất quan trọng: nếu thông tin 'khách hàng nào ký hợp đồng nào' đã nằm trong cơ sở dữ liệu có cấu trúc, đừng bắt AI suy ra lại từ file PDF. GraphRAG phù hợp nhất với tri thức đang nằm trong văn bản tự do và chưa từng được cấu trúc hóa.
"} ], "tip": "Trước khi xây GraphRAG, hãy liệt kê 20 câu hỏi quan trọng mà chatbot hiện tại trả lời kém. Nếu hơn một nửa là câu hỏi cần nối nhiều tài liệu, GraphRAG đáng thử; nếu không, hãy cải thiện chunking và reranker trước.", "faq": [ {"q": "GraphRAG có thay thế vector database không?", "a": "Thường là không. Nhiều triển khai vẫn dùng vector để tìm điểm bắt đầu, sau đó mới đi theo đồ thị để mở rộng ngữ cảnh."}, {"q": "GraphRAG có tốn kém hơn RAG thường không?", "a": "Có, chủ yếu ở bước lập chỉ mục vì mô hình phải đọc toàn bộ tài liệu để trích xuất thực thể và quan hệ. Chi phí truy vấn cũng có thể cao hơn với câu hỏi toàn cục."}, {"q": "Có cần Neo4j để làm GraphRAG không?", "a": "Không bắt buộc. Một số thư viện lưu đồ thị dạng tệp. Cơ sở dữ liệu đồ thị hữu ích khi đồ thị lớn hoặc cần truy vấn phức tạp, cập nhật thường xuyên."}, {"q": "GraphRAG có hoạt động tốt với tiếng Việt không?", "a": "Có thể dùng được nếu mô hình trích xuất hiểu tốt tiếng Việt. Cần chú ý bước chuẩn hóa tên viết tắt, có dấu, không dấu để tránh một thực thể bị tách thành nhiều nút."}, {"q": "GraphRAG có giảm hallucination không?", "a": "Nó giúp AI có ngữ cảnh đầy đủ hơn cho câu hỏi tổng hợp nên có thể giảm trả lời bịa. Nhưng nếu đồ thị trích xuất sai, AI vẫn trả lời sai, nên cần kiểm tra chất lượng đồ thị."}, {"q": "Doanh nghiệp nhỏ có tự làm GraphRAG được không?", "a": "Có thể thử bằng thư viện mã nguồn mở nếu có người biết lập trình Python. Với đội không có kỹ thuật, nên làm RAG cơ bản ổn định trước rồi mới tính đến GraphRAG."} ], "sources": [ {"t": "Microsoft GraphRAG – GitHub", "u": "https://github.com/microsoft/graphrag"}, {"t": "Microsoft Research – GraphRAG", "u": "https://www.microsoft.com/en-us/research/project/graphrag/"}, {"t": "Knowledge graph – Wikipedia", "u": "https://en.wikipedia.org/wiki/Knowledge_graph"}, {"t": "Neo4j", "u": "https://neo4j.com"} ], "related": ["rag-la-gi", "knowledge-graph-la-gi", "vector-database-la-gi", "chunking-la-gi", "reranker-la-gi", "hybrid-search-la-gi", "xay-kho-tri-thuc-ai-noi-bo", "ai-hallucination-la-gi"] }, { "id": 2168, "slug": "reranker-la-gi", "title": "Reranker là gì? Tăng độ chính xác tìm kiếm cho RAG", "meta_desc": "Reranker là gì: mô hình chấm lại thứ hạng kết quả tìm kiếm để RAG lấy đúng đoạn tài liệu. Cách hoạt động, so với embedding, khi nào nên thêm và cách đo hiệu quả.", "excerpt": "Chatbot tài liệu nội bộ trả lời sai thường không phải do mô hình kém, mà do lấy nhầm đoạn văn. Reranker là lớp chấm điểm lại giúp đưa đoạn đúng lên đầu trước khi AI viết câu trả lời.", "answer": "Reranker là mô hình chấm lại mức độ liên quan giữa câu hỏi và từng đoạn tài liệu ứng viên, rồi sắp xếp lại thứ tự trước khi đưa vào mô hình ngôn ngữ. Trong RAG, bước tìm kiếm đầu (vector hoặc từ khóa) lấy nhanh khoảng 20–100 đoạn, reranker đọc kỹ từng cặp câu hỏi và đoạn văn để chọn ra 3–8 đoạn sát nhất. Nhờ vậy câu trả lời chính xác hơn, ít bị nhiễu. Đổi lại, reranker thêm độ trễ và chi phí tính toán, nên cần cân bằng số ứng viên đưa vào.", "kws": ["reranker là gì", "rerank RAG", "cross-encoder", "sắp xếp lại kết quả tìm kiếm"], "sections": [ {"h2": "Reranker là gì và nằm ở đâu trong hệ thống RAG", "html": "Reranker (mô hình xếp hạng lại) là một bước lọc thứ hai trong quy trình tìm kiếm. Hệ thống RAG điển hình có bốn bước: nhận câu hỏi, tìm đoạn tài liệu liên quan, chọn ngữ cảnh, sinh câu trả lời. Reranker nằm giữa bước tìm và bước chọn.
Hình dung như tuyển dụng: bước tìm kiếm đầu là lọc hồ sơ nhanh theo từ khóa, lấy 50 hồ sơ. Reranker là vòng phỏng vấn, xem kỹ từng ứng viên để chọn 5 người phù hợp nhất. Vòng đầu cần nhanh và rộng, vòng sau cần kỹ và chính xác.
Tìm kiếm bằng embedding so sánh vector của câu hỏi và vector của đoạn văn đã tính sẵn. Cách này rất nhanh vì không cần đọc lại văn bản, nhưng vector là bản nén ý nghĩa nên mất chi tiết. Câu hỏi 'được nghỉ phép bao nhiêu ngày khi kết hôn' có thể kéo về đoạn nói chung về nghỉ phép năm, vì về nghĩa chúng gần nhau. Reranker đọc cả câu hỏi lẫn đoạn văn cùng lúc nên phân biệt được chi tiết 'kết hôn'.
"}, {"h2": "Reranker hoạt động như thế nào", "html": "Phần lớn reranker hiện nay dựa trên kiến trúc cross-encoder. Khác với embedding (bi-encoder) mã hóa câu hỏi và đoạn văn riêng rẽ, cross-encoder đưa cả hai vào mô hình cùng lúc và trả về một điểm liên quan.
Vì phải chấm từng cặp, reranker chậm hơn nhiều so với tìm vector. Đó là lý do không dùng reranker cho toàn bộ kho tài liệu mà chỉ cho tập ứng viên nhỏ.
Ba cách đánh giá mức liên quan này thường được dùng phối hợp theo tầng.
", "table": {"caption": "Ba tầng đánh giá mức liên quan", "head": ["Phương pháp", "Tốc độ", "Độ chính xác", "Vai trò phù hợp"], "rows": [["Embedding (bi-encoder)", "Rất nhanh, quét được hàng triệu đoạn", "Khá, mất chi tiết", "Tìm ứng viên ban đầu"], ["Reranker (cross-encoder)", "Trung bình, vài chục đến vài trăm đoạn", "Cao", "Lọc lại top ứng viên"], ["LLM chấm điểm", "Chậm, tốn token", "Cao, giải thích được lý do", "Đánh giá offline hoặc kho nhỏ"], ["Tìm từ khóa BM25", "Rất nhanh", "Tốt với mã số, tên riêng", "Kết hợp với embedding trong hybrid search"]]}}, {"h2": "Dấu hiệu chatbot của bạn cần thêm reranker", "html": "Không phải hệ thống RAG nào cũng cần reranker ngay. Hãy xem log và kiểm tra các dấu hiệu sau:
Ngược lại, nếu đoạn đúng thậm chí không có trong top 50, reranker không cứu được. Vấn đề nằm ở chunking, embedding hoặc dữ liệu nguồn. Khi đó hãy xem lại cách chia tài liệu hoặc thêm tìm kiếm từ khóa.
Một cửa hàng điện máy có 300 file hướng dẫn cho nhiều model máy lạnh. Khách hỏi lỗi E4 của model cụ thể, tìm vector trả về đoạn lỗi E4 của model khác. Reranker đọc kỹ mã model trong câu hỏi giúp đẩy đúng đoạn lên đầu.
"}, {"h2": "Cách thêm reranker vào hệ thống RAG", "html": "Chạy lại bộ câu hỏi, đo tỷ lệ đoạn đúng nằm trong top 3 trước và sau khi thêm reranker, đồng thời đo độ trễ trung bình. Chỉ giữ reranker nếu độ chính xác tăng rõ mà độ trễ vẫn chấp nhận được với người dùng.
"}, {"h2": "Lỗi thường gặp khi dùng reranker", "html": "Nếu dữ liệu nhạy cảm và bạn muốn mọi thứ chạy trong mạng nội bộ, reranker có thể chạy cùng máy chủ với mô hình embedding. Mô hình reranker phổ biến thường nhỏ hơn nhiều so với LLM, cỡ vài trăm triệu tham số.
Các con số này chỉ là ước lượng, phụ thuộc mô hình cụ thể, độ dài đoạn và phần mềm phục vụ. Hãy thử tải thật trước khi chốt cấu hình máy chủ.
"} ], "tip": "Đo trước, thêm sau: ghi lại vị trí đoạn đúng trong kết quả tìm kiếm với 50 câu hỏi thật. Nếu đoạn đúng thường nằm ở vị trí 6–30, reranker gần như chắc chắn đáng thêm.", "faq": [ {"q": "Reranker khác embedding thế nào?", "a": "Embedding mã hóa câu hỏi và đoạn văn riêng rẽ thành vector để so sánh nhanh. Reranker đọc cả hai cùng lúc nên chính xác hơn nhưng chậm hơn, vì vậy chỉ dùng cho tập ứng viên nhỏ."}, {"q": "Có bắt buộc phải dùng reranker cho RAG không?", "a": "Không bắt buộc. Với kho tài liệu nhỏ, ít đoạn trùng ý, RAG không có reranker vẫn có thể tốt. Reranker hữu ích khi đoạn đúng hay bị xếp sau các đoạn tương tự."}, {"q": "Reranker có hỗ trợ tiếng Việt không?", "a": "Nhiều reranker đa ngôn ngữ hỗ trợ tiếng Việt ở mức chấp nhận được. Chất lượng khác nhau giữa các mô hình nên cần thử với câu hỏi thật của doanh nghiệp."}, {"q": "Reranker làm chatbot chậm hơn bao nhiêu?", "a": "Tùy số ứng viên, độ dài đoạn và phần cứng. Với vài chục đoạn trên GPU hoặc dịch vụ API, thời gian thêm thường nhỏ; trên CPU yếu và nhiều ứng viên thì có thể chậm rõ rệt."}, {"q": "Có thể dùng ChatGPT hay Claude làm reranker không?", "a": "Có thể yêu cầu mô hình ngôn ngữ chấm điểm mức liên quan, nhưng tốn token và chậm hơn reranker chuyên dụng. Cách này hợp cho đánh giá offline hơn là chạy mỗi câu hỏi."}, {"q": "Reranker có giúp giảm chi phí API không?", "a": "Có thể. Khi lọc chính xác hơn, bạn chỉ cần đưa ít đoạn vào prompt, giảm token đầu vào cho mô hình ngôn ngữ lớn."} ], "sources": [ {"t": "Sentence Transformers – Cross-Encoders", "u": "https://www.sbert.net"}, {"t": "Learning to rank – Wikipedia", "u": "https://en.wikipedia.org/wiki/Learning_to_rank"}, {"t": "LlamaIndex documentation", "u": "https://docs.llamaindex.ai"} ], "related": ["rag-la-gi", "embedding-la-gi", "hybrid-search-la-gi", "chunking-la-gi", "semantic-search-la-gi", "vector-database-la-gi", "graphrag-la-gi", "evals-la-gi"] } ]