"Search as Code": để model tự viết pipeline tra cứu — builder Việt nên mừng hay nên dè?
Lâu nay khi dựng một con bot tra cứu, bạn — người build — viết sẵn đường đi: nhận câu hỏi, gọi API tìm kiếm, lọc kết quả, nhồi vào prompt. Perplexity vừa đề xuất lật ngược: để chính model tự viết đoạn code điều phối tìm kiếm đó.
Tin gọn: Perplexity ra "Search as Code" — thay vì model gọi một API tìm kiếm cố định, nó tự viết một đoạn Python để điều phối quá trình truy hồi, được cho là giảm tới 85% token ở một số tác vụ (tuyên bố từ Perplexity cho trường hợp cụ thể, chưa kiểm chứng độc lập — nguồn: the-decoder, 08.06.2026). Với người chỉ xài chatbot thì đây là tin nội bộ kỹ thuật. Nhưng với ai đang tự dựng RAG hay bot tra cứu cho doanh nghiệp, nó chạm thẳng vào một quyết định kiến trúc bạn sẽ phải chọn.
Tóm tắt cho người bận
- Search as Code = model tự viết đoạn code để điều phối việc tìm kiếm/truy hồi, thay vì người build đóng cứng các bước (gọi API → lọc → nhồi prompt).
- Lợi quảng cáo: tiết kiệm token (Perplexity nói tới 85% ở vài ca) và linh hoạt — model tự quyết tìm gì, tìm mấy vòng, lọc ra sao thay vì chạy một lối mòn cố định.
- Cái giá: bạn mất quyền kiểm soát đường truy hồi. Code do model sinh ra mỗi lần một khác, khó test, khó tái lập, và là một bề mặt tấn công mới.
- Với builder nhỏ ở VN: đáng thử cho prototype và bài toán tra cứu phức tạp, nhưng với bot CSKH tra giá/dịch vụ thì pipeline cứng vẫn an toàn hơn — ít nhất là cho đến khi bạn có bộ test đủ chặt.
Search as Code thực ra đổi cái gì
Hãy gọi đúng tên hai trường phái.
Pipeline cứng (cách phổ biến hiện nay): bạn viết tay luồng. Khách hỏi giá → bot embed câu hỏi → tìm trong vector store → lấy top-k đoạn → ghép vào prompt → model trả lời. Mỗi bước bạn nắm rõ. Lỗi ở đâu bạn dò ra đó. Nhược điểm: cứng. Câu hỏi nào lệch khỏi kịch bản — ví dụ "spa có gói nào cho mẹ sau sinh dưới 2 triệu không" — thì lối mòn top-k có thể trả về sai đoạn.
Search as Code (cách Perplexity đề xuất): bạn đưa model công cụ và để nó tự viết code điều phối. Model có thể tự quyết: tìm hai vòng, lọc theo giá, gộp kết quả, rồi mới trả lời. Linh hoạt hơn với câu hỏi rắc rối. Và vì nó chỉ kéo về đúng thứ cần thay vì nhồi cả đống ngữ cảnh thừa, token giảm — đó là gốc của con số 85% (cho một số tác vụ, không phải mọi tác vụ).
Khác biệt cốt lõi: ai là người điều phối truy hồi — bạn hay model. Đó là toàn bộ câu chuyện.
Góc builder: con bot tra giá của bạn thì sao
Tôi đang chạy thật một bot CSKH cho spa, phần lõi là tra cứu bảng giá và dịch vụ. Tôi thử đặt câu hỏi: nếu cho model tự viết pipeline tìm kiếm, sản phẩm của tôi tốt lên hay rủi ro hơn?
Câu trả lời thành thật: tuỳ bài toán, và phần lớn ca của tôi thì chưa nên.
Khi pipeline cứng vẫn thắng — và đó là đa số bot SME:
- Bài toán hẹp, câu hỏi lặp lại. 90% khách spa hỏi vài thứ: giá gói này bao nhiêu, có khuyến mãi không, đặt lịch thế nào. Một pipeline top-k tử tế giải sạch. Để model tự viết code cho mấy câu này là lấy dao mổ trâu giết gà — tốn thêm độ trễ, thêm điểm hỏng, không đổi lại gì.
- Cần kết quả tái lập. Khách hỏi giá gói A, bot phải trả đúng một con số, hôm nay giống hôm qua. Code model sinh động mỗi lần một khác → cùng câu hỏi có thể đi hai đường khác nhau. Với chuyện giá tiền của khách, đó là rủi ro không đáng đánh đổi.
- Bề mặt tấn công. Tuần này mục /ai cũng nói về prompt injection. Nếu model tự viết và chạy code dựa trên nội dung khách gửi, bạn vừa mở thêm một cửa: một câu chèn khéo trong tin nhắn khách có thể uốn cong đoạn code truy hồi đó. Pipeline cứng không có cửa này vì đường đi do bạn đóng sẵn.
Khi Search as Code đáng thử:
- Câu hỏi đa bước, không đoán trước được. Bot tra cứu nội bộ cho nhân viên — "tổng hợp các hợp đồng quý 2 có điều khoản phạt trễ hạn rồi so với mẫu chuẩn" — kiểu này pipeline cứng viết tay rất mệt, để model tự điều phối truy hồi lại hợp.
- Bạn đau vì hoá đơn token. Nếu RAG của bạn đang nhồi cả tấn ngữ cảnh mỗi lượt và bill phình to, cơ chế "chỉ kéo đúng thứ cần" có thể cứu chi phí thật. Nhưng hãy đo trước trên tải thật của bạn, đừng tin con số 85% của hãng.
- Giai đoạn prototype. Khi chưa biết khách sẽ hỏi gì, để model tự xoay sở giúp bạn dò ra dạng câu hỏi thật, rồi sau đó đóng cứng lại những lối đã rõ.
Nguyên tắc tôi sẽ áp
Tôi không bỏ pipeline cứng cho bot tra giá. Nhưng đây là cách tôi nghĩ về lằn ranh:
- Bài toán càng liên quan đến tiền/cam kết với khách, càng giữ cứng. Giá, lịch, hợp đồng — đường đi phải do người build kiểm soát.
- Để model tự điều phối ở phần "đọc hiểu nội bộ", không phải phần "trả lời khách". Cho nhân viên dùng kiểu Search as Code thì được; cho khách lạ kích hoạt code động thì không.
- Không có test thì không động dao. Trước khi giao quyền điều phối cho model, phải có bộ câu hỏi vàng và kết quả mong đợi để chạy lại mỗi lần. Linh hoạt mà không đo được là linh tinh, không phải tính năng.
Đây cũng là khác biệt giữa "nghịch được kỹ thuật mới" và "bán được sản phẩm cho doanh nghiệp": cái thứ hai phải trả lời đúng và giống nhau khi khách trả tiền hằng tháng — chứ không phải gây ấn tượng bằng một kiến trúc thời thượng.
Nếu bạn đang dựng con bot tra cứu đầu tiên, lời khuyên của tôi: bắt đầu bằng pipeline đơn giản, đo cái đã, rồi mới tính cho model tự lo. Cách dựng từ con bot chạy đúng trước khi chạy hoa mỹ là phần tôi dạy kỹ trong mini-course miễn phí.
Nguồn tham khảo (qua bản tin AI nội bộ tôi theo dõi hằng ngày): the-decoder.com — 08.06.2026. Con số "giảm 85% token" là tuyên bố của Perplexity cho trường hợp cụ thể, chưa được kiểm chứng độc lập.