사용자에게 모드를 고르게 하지 마세요: 의도를 추측하는 검색

KoiSpeak은 입력창 하나에서 세 가지 입력을 받습니다. 베트남어, 병음, 한자입니다. 뻔한 설계는 모드 전환 버튼이겠죠. 저희는 의도적으로 그것을 만들지 않았고, 그 이유는 사전을 훨씬 넘어 일반화됩니다.

모드 전환이 실패하는 이유

전환 스위치는 무해해 보입니다. 사용자에게 드는 비용은 탭 한 번. 그런데 그 비용이 매번 들고, 아주 구체적이고 짜증나는 방식으로 실패합니다. 모드가 틀리면 결과가 0건이고, 0건은 "이 단어는 존재하지 않는다"와 구분되지 않습니다.

사용자의 실제 심성 모형은 "나는 지금 병음 검색을 수행하고 있다"가 아닙니다. "이게 무슨 뜻이지"입니다. 그 의도와 답 사이에 끼어드는 모든 인터페이스 요소는 마찰이고, 하루 마흔 번 여는 도구에서 마찰은 누적됩니다.

여기 일반 규칙이 숨어 있습니다. 시스템이 입력에서 판단할 수 있는 것을 사용자에게 물어서는 안 됩니다. 모드 전환은 인터페이스가 그 일을 하기 싫다고 인정한 흔적입니다.

세 문자 체계는 보기보다 잘 분리된다

좋은 소식은 이것들이 차지하는 공간이 거의 겹치지 않는다는 점입니다.

한자는 검출이 자명할 정도로 쉽다

한자는 알려진 유니코드 블록에 있습니다. 주로 CJK 통합 한자 U+4E00부터 U+9FFF까지이고 확장 영역이 따로 있습니다. 입력에 그 범위의 문자가 있으면 사용자는 중국어를 친 것입니다. 추측이 아니라 사실상 확정입니다.

베트남어에는 병음이 쓰지 않는 기호가 있다

베트남어는 라틴 문자로 쓰이며 고유한 기호 세트를 가집니다. 뿔 기호 (ơ, ư), 곡절 부호 (â, ê, ô), 짧은 소리 기호 (ă), 획이 그어진 đ, 그리고 아래점 (ạ)과 갈고리 (ả)를 포함한 성조 기호입니다.

병음은 장음 부호, 양음 부호, 하체크, 억음 부호를 쓰고, 그것도 a, e, i, o, u, ü 위에서만 씁니다. 두 집합은 거의 겹치지 않습니다. đ, ơ, ư 또는 아래점이 들어간 문자열은 베트남어입니다. 다른 가능성은 없습니다.

병음은 작고 닫힌 집합이다

여기가 사람들이 과소평가하는 부분입니다. 표준중국어에 적법한 음절은 수백 개뿐입니다. zhang, xue, qiong은 적법하고 blorp과 strem은 아닙니다.

그래서 검증할 수 있습니다. 입력을 적법한 병음 음절로 쪼개 보는 겁니다. 깔끔하게 쪼개지면 병음일 가능성이 매우 높습니다. 이 방법은 성조 부호 없는 병음도 잡아냅니다. 대부분의 사람이 실제로 치는 건 그쪽이니까요.

어려운 건 겹치는 부분

명확한 경우의 검출은 쉽고, 모호한 경우가 흥미롭습니다. 실제 충돌은 이렇습니다.

• 양쪽 다인 짧은 문자열. ma는 적법한 병음이면서 동시에 적법한 베트남어 단어입니다. ba, co, can도 마찬가지.
• 기호 없는 베트남어. 상당수가 기호 없이 베트남어를 치고, 그러면 가장 강한 신호가 사라집니다.
• 영어. 학습자는 영어 단어를 치는데, 영어는 세 언어 중 어느 것도 아닙니다.

규칙을 더 얹어 해결하려는 건 지는 싸움입니다. 규칙은 길어지고, 서로 모순되고, 그래도 틀립니다.

분류하지 말고, 전부 검색한 뒤 순위를 매기세요

실제로 통한 설계는 이것을 분류 문제로 다루기를 그만두는 것이었습니다.

입력이 무엇인지 정해서 색인 하나를 뒤지는 대신, 질의를 모든 해석에 대해 실행하고, 각 해석이 얼마나 그럴듯한지를 반영한 점수로 결과를 합칩니다.

대략:

1. 각 해석에 점수를 매깁니다. 한자를 포함하는지, 베트남어 고유 기호를 가졌는지, 적법한 병음으로 쪼개지는지.
2. 그 해석들이 가리키는 색인을 조회합니다.
3. 합치되, 해석의 점수, 일치의 정확도, 단어 빈도로 가중치를 줍니다.

사용자가 보는 건 하나의 목록입니다. ma를 치면 병음 결과와 베트남어 결과가 함께, 흔한 단어부터 나옵니다. 어느 쪽을 원했든 답은 화면에 있습니다. 모호함은 오류 상태가 아니라 순위가 매겨진 목록이 됩니다.

분류는 틀릴 수 있는 결정을 강요합니다. 순위 매기기는 확신하지 못한 채로도 쓸모 있게 해 줍니다. 시스템이 확신할 수 없을 때는, "자신 있는 하나의 오답"이 아니라 "그럴듯한 여러 답"으로 퇴화하는 설계를 고르세요.

대가

거래에 대해 솔직히 말하면, 키 입력마다 더 많은 질의를 실행하게 됩니다. 사실이고, 그래서 이 설계는 성능에 따라 살거나 죽습니다.

감당 가능하게 만든 것들:

• 싼 해석을 먼저. 한자 검출은 앞 몇 글자의 범위 확인일 뿐입니다. 맞으면 나머지는 전부 건너뜁니다.
• 문자 체계별 접두사 색인. 개별 질의가 훑기가 아니라 값싼 조회가 됩니다.
• 빈도를 색인에 미리 구워 넣기. 순위를 매기려고 결과를 한 번 더 돌 필요가 없습니다.
• 디바운스하고, 입력이 바뀌면 진행 중인 질의를 취소. 대부분의 키 입력은 완료된 검색을 만들지 않습니다.

그래도 비상구가 필요한 곳

자동 인식이 유일한 통로여서는 안 됩니다. 정말 다른 수단이 필요한 두 경우가 있습니다.

• 그 글자를 아예 칠 수 없을 때. 손글씨 입력과 부수 검색이 그걸 위해 있습니다.
• 방향을 강제하고 싶을 때. 가끔 사용자는 정말로 베트남어에서 중국어만 원합니다. 방향 지정 컨트롤을 제공하지만, 처음부터 강요하는 결정이 아니라 필요할 때 쓰는 재정의로 둡니다.

이 순서가 진짜 원칙입니다. 기본값에서는 잘 추측하고, 사람이 그 추측을 고칠 수 있게 하라. 추측을 거부하고 모두에게 신고하게 만들지 말고.

일반화되는 교훈

어떤 제품에나, 가장 쉬운 구현이 시스템이 스스로 답할 수 있었던 질문을 사용자에게 던지는 순간이 있습니다. 파일 형식. 국가. 통화. 검색 모드.

하나하나는 작습니다. 합치면, 그것이 "생각 없이 손이 가는 도구"와 "조작해야 하는 도구"의 차이입니다.