Proposal: context-aware learning from accepted and reverted suggestions
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start by reading DictionaryFacilitatorImpl, Suggest, and the existing UserHistoryDictionary mechanisms to understand candidate generation, final ranking, and available storage; the issue does not name specific test files. The proposed first step is rejection feedback: detect an immediate revert, store a bounded negative association, and apply a capped penalty to an existing candidate, with regression tests and no learning in sensitive fields or incognito mode.
由索引模型根据 Issue 内容生成。
描述
Problem
LeanType already has several personalization mechanisms:
UserHistoryDictionary- personal dictionary suggestions
- session word boost
- bigram/trigram history
- configurable personal-suggestion boost
However, these mechanisms mainly learn that a word was used. They do not reliably learn that a particular candidate was the correct choice for a specific mistyped input and context.
For users who mostly enter text by selecting suggestions, this can produce a recurring pattern:
- The intended word is present in the suggestion strip, but ranked second or third.
- The user repeatedly selects it manually.
- The same less suitable candidate remains ranked first on future occurrences.
- A suggestion reverted immediately with Backspace may still remain highly ranked.
This appears related to the personalization balance discussed in #382, but the proposed change would not increase the global weight of personal words.
Proposed direction
Keep the existing dictionary candidate generation unchanged and add a small, bounded feedback layer for suggestion ranking.
Possible feedback signals:
- Selecting suggestion #2 or #3: weak positive feedback for that candidate for the same typed form.
- Repeatedly selecting the same candidate: gradually increase its contextual preference.
- Reverting an autocorrection immediately with Backspace: strong negative feedback for that correction.
- Replacing a selected suggestion immediately: negative feedback for the removed candidate and positive feedback for the replacement.
- Matching previous-word context: allow a larger adjustment than a typed-form-only match.
The feedback should only reorder candidates already produced by the existing dictionaries. It should not generate new words or replace the current decoder.
A simplified model could be:
finalScore = originalScore + contextualFeedbackBoost - rejectionPenalty
The adjustment should be capped so that learned feedback cannot override a clearly better dictionary/spatial match.
Shadow-mode evaluation
Before changing visible suggestions, the candidate ranker could first run in an optional local shadow mode:
baseline order: A, B, C
candidate order: B, A, C
user selected: B
outcome: helped
This would make the feature measurable rather than opaque:
helped: the candidate ranker would move the selected word higher;hurt: the baseline ranked the selected word higher;neutral: no meaningful rank change.
Useful local metrics would include Top-1/Top-3 accuracy, mean reciprocal rank, immediate revert rate, helped vs hurt, and suggestion latency. Visible reranking could remain disabled until enough local evidence shows a meaningful positive margin.
Integration constraints
I would like to keep this compatible with the existing architecture:
- candidate generation remains in
DictionaryFacilitatorImpl; - final suggestion construction remains in
Suggest; - reuse existing user-history mechanisms where practical;
- no network access or telemetry;
- no learning in password fields or incognito mode;
- bounded local storage with decay or eviction;
- no complete-message storage;
- no noticeable latency in the suggestion hot path;
- optional/experimental behavior if it may not be wanted by everyone.
Non-goals
This proposal does not include:
- replacing the AOSP/native dictionary decoder;
- adding an LLM or large neural model;
- introducing a new unified dictionary format;
- changing gesture typing;
- globally increasing the priority of all personal words.
Suggested implementation sequence
PR 1: rejection feedback
Teach LeanType not to repeatedly prefer a suggestion that the user immediately reverted.
This would be intentionally small and independently useful:
- detect immediate revert of an autocorrection or selected suggestion;
- record a bounded negative association;
- apply a capped penalty when the same correction is proposed again;
- add focused regression tests;
- do not learn in sensitive fields or incognito mode.
Candidate generation would remain unchanged; this PR would only apply a bounded penalty to an already generated candidate.
PR 2: accepted-suggestion feedback
After the first behavior is validated:
- learn when the user repeatedly selects a lower-ranked candidate;
- include previous-word context;
- cap and decay old feedback;
- add ranking tests with synthetic candidates and contexts.
Touch-position adaptation could be considered separately only if evidence shows that the intended word is frequently absent from the candidate list rather than merely ranked poorly.
Questions before implementation
- Would a small feedback layer on top of the existing suggestion scores fit the direction of LeanType?
- Should rejection feedback be stored through
UserHistoryDictionary, or would a separate bounded local store be preferable? - Is immediate Backspace after autocorrection a sufficiently reliable rejection signal for the first PR?
- Would you prefer this behind the existing personalized-suggestions setting or a separate experimental toggle?
I can prepare the first narrowly scoped PR after agreeing on the storage and integration point.
- 主要语言
- Kotlin
- 星标
- 1k
- 派生
- 59
- 平均合并
- 13 小时 21 分钟
- 30 天内合并 PR
- 48
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
LeanBitLab/LeanType 的其他 Issue
-
Voice input fails in browser address bars due to incorrect password field detection (v4.2.9, follow-up to #516)可能已有人在做 @LeanBitLab 今天认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 76/100
LeanBitLab/LeanType#713 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
LeanBitLab/LeanType#423 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 3/5 1-2 天 新手友好度 54/100
LeanBitLab/LeanType#717 ·
维护者通常 1 天内回复
-
Crush Report可能已有人在做 @LeanBitLab 今天认领。 未关闭
难度 3/5 1-2 天 新手友好度 20/100
LeanBitLab/LeanType#715 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Text Expander/cursor-handling bug可能已有人在做 @LeanBitLab 于 2 天前认领。 未关闭bug
难度 3/5 1-2 天 新手友好度 62/100
LeanBitLab/LeanType#703 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 LeanBitLab/LeanType 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
mcnaveen/health-connect-webhook#110 ·
维护者通常 1 天内回复
-
Delete all above未关闭enhancement
难度 2/5 1-3 小时 新手友好度 68/100
mjaakko/NeoStumbler#1307 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
tanujnotes/Olauncher#770 ·
-
难度 2/5 1-3 小时 新手友好度 66/100
-
submit-adaption submit-adaption-pre
难度 1/5 1 小时以内 新手友好度 76/100
BetterAndroid/android-notification-icon-project#795 · 1 条评论 ·
维护者通常 1 天内回复