Proposal: context-aware learning from accepted and reverted suggestions
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 28/100
調査の方向性
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時間 11分
- マージ済み PR(30日)
- 47
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
LeanBitLab/LeanType のほかの issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
LeanBitLab/LeanType#713 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
LeanBitLab/LeanType#423 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Crush Reportオープン
難易度 3/5 1〜2日 初心者へのやさしさ 20/100
LeanBitLab/LeanType#715 ·
メンテナーはふだん 1 日以内に返信
-
Text Expander/cursor-handling bug対応中かも @LeanBitLab が 2 日前に担当しました。 オープンbug
難易度 3/5 1〜2日 初心者へのやさしさ 62/100
LeanBitLab/LeanType#703 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
LeanBitLab/LeanType#699 ·
メンテナーはふだん 1 日以内に返信
LeanBitLab/LeanType の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
apache/cassandra-easy-stress#112 ·
-
afk-ok area:data-quality importer size:S
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
enorm-labs/event-junkie#3767 ·
メンテナーはふだん 1 日以内に返信
-
resource-submission validation-passed
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
hesreallyhim/awesome-claude-code#3201 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
software-mansion/starknet-jvm#641 ·
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
leboncoin/spark-android#2342 ·
メンテナーはふだん 1 日以内に返信