3.11 Sửa lỗi, "có phải bạn muốn tìm", và autocomplete

Ba tính năng nhìn giống nhau (đều liên quan tới việc người dùng gõ chưa xong hoặc gõ chưa đúng) nhưng khác nhau ở thời điểm và ở ai quyết định:

Tính năng	Xảy ra khi	Ai quyết định	Rủi ro khi sai
Autocomplete	đang gõ	người dùng chọn	thấp — họ chỉ bỏ qua gợi ý
“Có phải bạn muốn tìm…”	sau khi tìm	người dùng bấm	thấp
Tự sửa im lặng	sau khi tìm	hệ thống	cao — người dùng nhận kết quả của một truy vấn khác mà không biết

Tự sửa im lặng: chỉ khi nào?

Ba điều kiện, phải đủ cả ba:

1. Truy vấn gốc trả về 0 kết quả (hoặc gần 0).
2. Bản sửa cách gốc ≤ 1 phép sửa, và có tần suất cao hơn nhiều trong log.
3. Giao diện nói ra là đã sửa: “Đang hiển thị kết quả cho mật khẩu. Kèm nút quay lại truy vấn gốc.

Thiếu điều 3 thì bạn đã tạo ra một lớp bug không ai báo được: người dùng nghĩ họ tìm X, hệ thống trả về Y, và không có manh mối nào ở giao diện.

Chọn bản sửa: noisy channel

Cách chuẩn để xếp hạng ứng viên sửa. Với truy vấn q, chọn c cực đại:

P(c | q)  ∝  P(q | c)  ·  P(c)
              ^            ^
        mô hình lỗi    mô hình ngôn ngữ
     (gõ c ra q dễ đến  (c có phổ biến
      mức nào — theo    không — theo log
      khoảng cách,      truy vấn và corpus
      theo phím gần)    của bạn)

Điểm mấu chốt: P(c) phải lấy từ dữ liệu của bạn, không phải từ điển tiếng Việt phổ thông. Trong một sản phẩm tài chính, sao kê phổ biến hơn sao khê rất nhiều; trong sản phẩm khác thì ngược lại. Nguồn tốt nhất là log truy vấn có click — những truy vấn dẫn tới click là những truy vấn “đúng” đã được người dùng xác nhận.

Đọc thêm

• [EN] IR Book §3.3 — Spelling correction — sửa lỗi chính tả trong search: hai nhóm phương pháp
• [VI] Tự động sửa lỗi chính tả với SymSpell — Viblo — gợi ý sửa bằng SymSpell, có code tiếng Việt

Autocomplete: bài toán prefix, không phải bài toán fuzzy

Chuỗi xử lý tối thiểu:

người dùng gõ "mat kh"
  → chuẩn hoá (bỏ dấu, hạ chữ)          ← 3.1, 3.10
  → tra prefix trên FST/trie             ← 3.6
  → xếp theo độ phổ biến (số lần tìm, số click), không theo alphabet
  → trả 5–10 gợi ý

Bốn quyết định thiết kế, theo thứ tự tác động:

Quyết định	Khuyến nghị
Nguồn gợi ý	Log truy vấn thành công, không phải tiêu đề tài liệu. Người dùng gõ theo cách người dùng nói
Ranking	Độ phổ biến, có suy giảm theo thời gian. Alphabet là lựa chọn tệ nhất
Ngân sách latency	< 50 ms p95. Trên mức đó gợi ý tới sau khi người dùng đã gõ tiếp — vô dụng
Fuzzy trong autocomplete	Chỉ khi prefix trả về rỗng, và tối đa k=1

Chuẩn hoá bỏ dấu ở đây gần như bắt buộc: người đang gõ dở chưa gõ dấu (Telex đặt dấu sau khi xong âm tiết), nên prefix có dấu sẽ trượt ở gần như mọi ký tự trung gian.

Đọc thêm

• [EN] Elasticsearch autocomplete: search-as-you-type — Elastic Search Labs — autocomplete: completion suggester vs edge n-gram vs search_as_you_type
• [EN] Using finite state transducers in Lucene — Mike McCandless — FST — vì sao suggester tốn RAM nhưng nhanh

Ba lỗi hay gặp

Lỗi	Hệ quả
Autocomplete lấy từ tiêu đề tài liệu	Gợi ý toàn ngôn ngữ nội bộ (Chính sách hoàn tiền v2.1) — không ai gõ như thế
Sửa lỗi cho cả truy vấn có mã định danh	E2003 bị “sửa” thành E2008 vì mã đó phổ biến hơn. Xem cảnh báo ở 3.7
Không log việc đã sửa	Không đo được sửa đúng hay sai. Luôn log cặp (gốc, đã sửa, người dùng có click không)

Nối với phần còn lại của cẩm nang

Sửa truy vấn ở đây là query understanding mức từ. Mức cao hơn — viết lại truy vấn, tách câu hỏi nhiều bước, HyDE, routing — ở Tầng 6. Thứ tự đúng: chuẩn hoá và sửa chính tả trước (rẻ, tiền đoán được), rồi mới đến viết lại bằng LLM (đắt, thêm latency, thêm một nguồn lỗi).