Cách thêm tìm kiếm vào ứng dụng do AI xây dựng (để mọi người thực sự tìm được thứ họ cần)

Có một thời điểm mà bất kỳ ứng dụng do AI xây dựng nào, nếu thực sự tốt, đều sẽ chạm tới: nó đầy lên. Ứng dụng công thức nấu ăn từng thú vị với mười hai công thức giờ trở thành cực hình khi có tới ba trăm. Ứng dụng theo dõi khách hàng từng gọn gàng với tám khách hàng giờ biến thành chuỗi cuộn trang bất tận khi có hai trăm người. Không có gì hỏng cả. Ứng dụng đã được sử dụng, đó chính là mục đích của nó — nhưng giờ đây, việc mà người dùng muốn làm, tìm một mục cụ thể, lại mất quá nhiều thời gian.

Đó chính là tín hiệu cho thấy đã đến lúc thêm chức năng tìm kiếm vào ứng dụng của bạn — một ô nhập liệu mà chỉ cần gõ vài chữ cái là thu hẹp cả danh sách dài xuống còn đúng một mục bạn đang tìm. Không phải vì tìm kiếm nghe ấn tượng, mà vì cuộn trang không phải là tìm kiếm. Hãy cùng đi qua cách làm điều này mà không xây dựng quá mức, vì phiên bản cầu kỳ thường là bước đi sai lầm đầu tiên.

Khi nào là lúc cần thêm tìm kiếm vào ứng dụng của bạn?

Bạn sẽ nhận ra vì việc cuộn trang bắt đầu mất nhiều thời gian hơn mức cần thiết — danh sách của bạn đã phát triển từ vài mục gọn gàng lên đến hàng trăm, và để tìm một thứ cụ thể nghĩa là phải cuộn qua tất cả những thứ khác. Không có gì hỏng để dẫn đến tình trạng này; ứng dụng đã được sử dụng, đó chính là mục đích của nó.

Đây là một ví dụ thực tế cho vấn đề này. Một người làm nghề chăm sóc thú cưng đã xây dựng một ứng dụng để theo dõi khách hàng của mình — tên chủ, tên chó, giống chó, ghi chú về việc con chó nào ghét máy sấy. Trong vài tháng đầu, đó là một danh sách sạch sẽ mà cô có thể lướt mắt qua là thấy ngay. Đến khi có hai trăm khách hàng, cô phải mở ứng dụng ngay lúc khách đang đứng trước mặt, và phải cuộn qua cả trăm cái tên mới tìm được “mẹ của Bella.”

Ứng dụng vẫn đang làm đúng những gì cô yêu cầu. Chỉ là danh sách không còn là cách hữu ích để tìm một thứ bên trong nó nữa. Đó là điều mà tìm kiếm khắc phục: nó biến “cuộn cho đến khi thấy” thành “gõ vài chữ cái là có ngay.”

Nếu ứng dụng của bạn hiển thị danh sách bất kỳ thứ gì — đơn hàng, công thức nấu ăn, khách hàng, sản phẩm, ghi chú — và danh sách đó cứ tiếp tục phát triển, bạn sẽ gặp phải vấn đề này. Tin vui là phiên bản tìm kiếm đầu tiên, đơn giản nhất, đã giải quyết được vấn đề cho hầu hết mọi người.

Làm thế nào để thêm tìm kiếm vào một ứng dụng do AI xây dựng?

Hãy bắt đầu với một ô lọc — một trường văn bản ở đầu danh sách, ẩn đi mọi thứ không khớp khi bạn gõ — chứ không phải phiên bản “tìm kiếm bằng AI” thông minh nhất có thể. Đó là toàn bộ bước đầu tiên, và với hầu hết các ứng dụng, đó cũng là bước duy nhất bạn cần.

Khi yêu cầu một công cụ xây dựng AI tạo chức năng tìm kiếm, bạn rất dễ bị cám dỗ để yêu cầu phiên bản thông minh nhất có thể: hiểu được ý bạn muốn nói, xử lý được từ đồng nghĩa, xếp hạng theo mức độ liên quan. Đừng làm vậy. Phiên bản thông minh chạy chậm hơn, tốn kém hơn để vận hành, và khó làm cho đúng hơn — và gần như chắc chắn bạn chưa cần đến nó.

Gõ “bella” và danh sách sẽ thu hẹp lại chỉ còn những Bella. Vậy là xong. Nó tức thì, gần như không tốn chi phí vận hành, và đó chính xác là điều mọi người muốn nói khi họ bảo “tôi muốn có thể tìm kiếm.”

Hãy yêu cầu công cụ xây dựng của bạn chính xác điều đó: “Thêm một ô tìm kiếm phía trên danh sách này, lọc ra những mục khớp với những gì tôi gõ.” Bạn sẽ ngạc nhiên vì bao nhiêu lần đó chính là toàn bộ dự án.

Tìm kiếm nên thực sự nhìn vào những trường nào?

Chỉ hai hoặc ba trường thực sự xác định thứ bạn đang tìm — không phải mọi trường trên mọi mục. Nói rõ điều này cho công cụ xây dựng của bạn chính là chỉ dẫn duy nhất biến tìm kiếm từ khó chịu thành hữu ích, và hầu hết mọi người lại bỏ qua nó.

Theo mặc định, một công cụ xây dựng có thể tìm kiếm mọi thứ — mọi trường trên mọi mục. Nghe có vẻ kỹ lưỡng nhưng thường lại tệ hơn. Hãy tưởng tượng bạn tìm trong danh sách khách hàng đó và nhận được kết quả khớp chỉ vì từ “nhỏ” xuất hiện trong một ghi chú về kích thước con chó. Giờ bạn phải lọc qua hàng loạt kết quả khớp về mặt kỹ thuật nhưng không phải điều bạn muốn tìm.

Vì vậy, hãy cụ thể về những trường nào thực sự quan trọng. Với người chăm sóc thú cưng, đó là tên chủ và tên con chó — không phải ghi chú, không phải giống chó, không phải lịch sử các lần hẹn. Với một ứng dụng công thức nấu ăn, đó là tên món và có thể là nguyên liệu chính, chứ không phải toàn bộ phần hướng dẫn. Hãy nói với công cụ xây dựng của bạn: “Tìm kiếm chỉ nên nhìn vào trường tiêu đề và trường tên.” Tìm đúng hai trường luôn tốt hơn tìm cả mười hai trường, không có ngoại lệ.

Nên xây dựng tìm kiếm hay bộ lọc trước?

Thường thì là bộ lọc — vì phần lớn những gì mọi người gọi là “tìm kiếm” thực ra là “cho tôi xem một tập con,” và ô tìm kiếm là công cụ sai cho việc đó. Đây là điều khiến những người xây dựng không chuyên về kỹ thuật bất ngờ.

Một người bán hàng với ba trăm mặt hàng tồn kho thường không muốn phải gõ chữ — cô ấy muốn chạm vào “Đã bán” hoặc “Còn hàng” hoặc “Đăng tuần này.” Đó là một bộ lọc: vài nút bấm hoặc một menu thả xuống thu hẹp danh sách theo một danh mục bạn đã theo dõi sẵn. Bộ lọc thường dễ xây dựng hơn tìm kiếm và hữu ích hơn trong công việc hàng ngày, vì mọi người duyệt theo trạng thái nhiều hơn hẳn so với việc lùng tìm một thứ cụ thể theo tên.

Một quy tắc hay: thêm ô tìm kiếm cho trường hợp “tôi biết đại khái nó tên gì,” và thêm bộ lọc cho trường hợp “cho tôi xem loại này.” Người chăm sóc thú cưng của chúng ta cuối cùng muốn có cả hai — một ô tìm kiếm để nhảy thẳng đến khách hàng theo tên khi họ đang đứng trước mặt cô, và một bộ lọc “quá hạn chăm sóc” để cô có thể nhìn thoáng qua là biết nên nhắn tin cho ai vào một buổi chiều vắng khách. Cùng một dữ liệu, nhưng hai cách tiếp cận hoàn toàn khác nhau.

Nếu chỉ có thể xây dựng một thứ trước, hãy quan sát cách mọi người thực sự sử dụng ứng dụng. Nếu họ cứ liên tục hỏi “tất cả các X ở đâu,” họ muốn một bộ lọc, chứ không phải ô tìm kiếm.

Điều gì nên hiển thị khi tìm kiếm không ra kết quả?

Một thông báo đơn giản, cụ thể — kiểu như “Không có khách hàng nào khớp với ‘zelda’ — kiểm tra lại chính tả hoặc xóa tìm kiếm” — chứ không phải một màn hình trống, khiến người dùng hiểu là “ứng dụng bị lỗi.” Nó không hề bị lỗi; chỉ là không có kết quả khớp thôi, nhưng hầu hết mọi người lại quên lên kế hoạch cho trường hợp này.

Mặc định thường là một màn hình trống. Vì vậy, hãy nói rõ với công cụ xây dựng của bạn nên hiển thị gì ở trạng thái rỗng đó. Chỉ một câu đó thôi cũng là ranh giới giữa việc người dùng nghĩ ứng dụng của bạn bị lỗi và việc họ nghĩ mình gõ sai.

Nhân tiện, hãy đảm bảo có một cách rõ ràng để xóa tìm kiếm và quay lại toàn bộ danh sách. Một dấu “x” nhỏ trong ô, hoặc một liên kết “xóa.” Người dùng bị mắc kẹt trong một lượt tìm kiếm không thoát ra được thường xuyên hơn bạn tưởng.

Khi nào bạn cần tìm kiếm bằng AI thay vì một ô lọc thông thường?

Hai dấu hiệu cụ thể, không phải cảm tính: lỗi chính tả, và ý nghĩa. Nếu mọi người tìm “stephanie” mà bỏ lỡ “Stefanie,” bạn cần kiểu khớp linh hoạt, chấp nhận sai lệch nhỏ — hãy yêu cầu công cụ xây dựng của bạn tạo “tìm kiếm vẫn ra kết quả ngay cả khi chính tả hơi sai.” Và nếu bạn thực sự cần “tìm cho tôi những ghi chú về vấn đề thanh toán” thay vì “tìm từ thanh toán,” đó là kiểu tìm kiếm thông minh, dùng AI — đáng để bỏ thêm chi phí và độ phức tạp một khi nó giải quyết được vấn đề mà ô lọc đơn giản không làm được.

Chỉ là đừng bắt đầu từ đó. Hãy bắt đầu với ô lọc, thêm khả năng khớp linh hoạt khi lỗi chính tả gây khó chịu, và chỉ tìm đến phiên bản thông minh khi “khớp đúng từ” không còn đủ nữa. Hầu hết các ứng dụng chẳng bao giờ cần vượt qua bước một.

Vì vậy, trước khi xây dựng bất cứ thứ gì, hãy quan sát chính mình sử dụng ứng dụng của mình trong một tuần. Thứ mà bạn cứ phải cuộn trang để tìm — một khách hàng, một đơn hàng, một công thức nấu ăn — đó chính là lý do ô tìm kiếm của bạn tồn tại. Hãy xây dựng nó cho đúng một thứ đó trước, và bạn sẽ giải quyết được vấn đề cho gần như tất cả những ai sử dụng ứng dụng.