open-spaced-repetition / fsrs4anki

A modern Anki custom scheduling based on Free Spaced Repetition Scheduler algorithm
https://github.com/open-spaced-repetition/fsrs4anki/wiki
MIT License
2.77k stars 137 forks source link

FSRS and reviewing ahead of schedule #707

Closed jcznk closed 5 days ago

jcznk commented 6 days ago

I noticed that if I use a filtered deck (rescheduling enabled) to perform multiple same day reviews that are ahead of schedule, FSRS-5 intervals grow very fast. I am using Anki 24.11 rc.

SM-2:

image

Another card, using FSRS-5 (default parameters, 90% desired retention)

image

L-M-Sherlock commented 6 days ago

Because FSRS-5 takes the same-day reviews into account.

jcznk commented 6 days ago

I understand that. What I'm wondering is if the behavior I described regarding "not yet due" cards is actually desirable.

The one above is an extreme example for testing purposes. My personal use case is that I would like to use a filtered deck to review ~25 random cards each day, independently of their due state, in addition to scheduled reviews.
This is to maximize interleaving, and to counteract the fact that sometimes I am able to guess the answer to a card based on my knowledge of which cards might or might not be due.

I would like to enable rescheduling for this filtered deck so that my answers will influence the normal scheduling. E.g., if I fail a card, I definitely want to see it sooner than previously scheduled. I would also like to give a slight boost to cards that I answer correctly. But I'm worried this will lead to intervals that grow too fast.

Admittedly, I'm not a FSRS expert and my testing is limited to the example above. Is there any "dampening" to the growth of the interval/change of memory state when a card is reviewed ahead of schedule?

L-M-Sherlock commented 6 days ago

I would also like to give a slight boost to cards that I answer correctly. But I'm worried this will lead to intervals that grow too fast.

I think 15 days -> 20 days doesn't grow too fast. The extreme case is very rare.

jcznk commented 6 days ago

While I agree on that, I'm personally mostly concerned about very mature cards (>1 year interval). Especially since there is a good chance they will come up 2+ times in the filtered deck before their due date is reached. Sticking to the above example, going from 2.8 months to 4.27 months, or from 4.27 to 5.67 months, seems like a pretty significant leap for a "same day" review.

Expanded FSRS example: image

L-M-Sherlock commented 6 days ago

Ideally, multiple reviews of the same cards only happens when you learn a new card or forget a card. And in these cases, the number of same-day reviews are limited.

For your case, I don't recommend review the same card in the same day too many times. If you insist doing that, please set these two parameters to zeros:

image
jcznk commented 6 days ago

The focus is actually not on "same-day" reviews but on all reviews performed before the actual due date. Same-day reviews are simply an extreme example of this.

  1. I only included same-day reviews in my examples because performing same-day reviews is easier for testing purposes, as it does not require testing across multiple days, using a simulator, or adjusting the clock.
  2. I’m also assuming that if a pattern applies to same-day reviews, it will also apply to reviews performed on different days. For example, sticking to the scenario in the screenshot above, it doesn’t really matter whether I perform the review today, tomorrow, or a month from now: if I press "Good", the interval will increase from 7.3 years to approximately 10.13 years. This might be undesirable depending on how much time has elapsed since the last "normal" review.

If I understand correctly, the last two FSRS-5 parameters are designed to handle same-day reviews but do not account for cases where users perform "before due date" reviews spread across multiple days.

That said, I understand this is a rather niche case.

L-M-Sherlock commented 6 days ago

The focus is actually not on "same-day" reviews but on all reviews performed before the actual due date. Same-day reviews are simply an extreme example of this.

So it's not a specific issue related to FSRS-5, right?

For reviews performed before the actual due data, the interval increases slower. It's designed in FSRS v3 and newer versions:

image

https://github.com/open-spaced-repetition/fsrs4anki/wiki/The-Algorithm

jcznk commented 6 days ago

If I’m interpreting the formula you posted correctly, it seems that when R = 1, S' = S. Therefore, a same-day review (which implies R = 1) should yield the same stability.

Upon further inspection, it appears that FSRS-5 uses a specific formula to calculate stability after same-day reviews:
image

This indicates that my assumption about same-day reviews was incorrect—they behave differently compared to "reviews ahead of schedule" performed across multiple days.

It also seems that same-day reviews might yield longer intervals compared to reviews spread across multiple days, as the stability growth is not constrained by R.
For example, a review performed yesterday increased the interval by approximately 2.8 years, while the first review performed today (my Anki day starts at 8 AM) on the same card increased the interval by only ~0.7 years.

By the way, would it make sense to use the same-day review formula for stability only for "learning" and "re-learning" cards, and apply the standard formula for "review" cards, even when they are reviewed multiple times in a single day?

image

L-M-Sherlock commented 6 days ago

It also seems that same-day reviews might yield longer intervals compared to reviews spread across multiple days, as the stability growth is not constrained by R.

Yes, because I haven't figured out the short-term memory model to deal with it. And Anki also cannot let FSRS know how long the time elapses since the last same-day review. So I uses different formula to deal with the same-day reviews and other reviews.

By the way, would it make sense to use the same-day review formula for stability only for "learning" and "re-learning" cards, and apply the standard formula for "review" cards, even when they are reviewed multiple times in a single day?

FSRS cannot distinguish whether a review is from in "learning" and "re-learning" card or a "review" card. It only knows the intervals and ratings.

Expertium commented 6 days ago

Yes, this is one of the three edge cases where this formula doesn't work well. image

1) If the user had one or two learning steps, but then switched to something like 30s 2m 5m 15m 30m 1h 2h 4h 6h 8h, then his stability will be overestimated. 2) If the user uses a filtered deck to do an unlimited number of same-day reviews (your case). 3) If the user is in a Good - Again - Good - Again loop (during the same day), stability will either explode or fall to near 0. This is possible if his learning steps are, for example, 10m 30m.

There is no solution as of today, so all 3 of these will remain troublesome for the foreseeable future.

jcznk commented 6 days ago

Thank you both for the explanation.

I’m curious why FSRS cannot distinguish between learn/re-learn and review cards. Is there anywhere I can read more about this?

L-M-Sherlock commented 6 days ago

I’m curious why FSRS cannot distinguish between learn/re-learn and review cards. Is there anywhere I can read more about this?

Because I don't want to consider card types in FSRS. FSRS is based on DSR model, where the card type doesn't have its place.

jcznk commented 6 days ago

I see. One idea I had was to assign a numerical value based on the card type, for example:

Then, we can obtain the new formula for "stability after a same-day review" by combining the two formulas, like this: $(\text{formula for same-day reviews})^{1-X} \cdot (\text{standard formula})^X$

This way, FSRS would apply the appropriate formula based on the card state, which could help cover this edge case. Anyway, if this is a design or philosophy choice, I guess there's nothing to do about it.

L-M-Sherlock commented 5 days ago

It's a philosophy choice. Many SRS apps don't have the concept of card type, so I don't want to support it in FSRS.