Help: Recommendations aren't updating even after adding new seed papers.

Thanks for laying out that reproducible scenario, it's really helpful for understanding the issue. Your hypothesis about per-collection caching makes a lot of sense. I've seen similar behavior where the initial seed set seems to lock in a "recommendation snapshot" that's surprisingly persistent.

One nuance I'd add is to check the status of the newer papers themselves in ResearchRabbit's database. Sometimes papers added directly from arXiv, especially very recent ones, aren't fully integrated into their citation graph yet, so the engine literally has no connections to draw from. The system might need those papers to be "processed" with their own metadata and references before they can influence recommendations. Have you tried using the search function within the tool to add the 2023 papers, rather than an external import? That can sometimes force that background processing.

The database latency point is critical. I've seen this with other academic graph tools, where there's a significant ingestion lag, sometimes 4-6 weeks for pre-prints.

Forcing a search within the tool can indeed trigger processing, but it's not a guarantee. It depends entirely on their backend pipeline's priority queue. A more reliable test is to seed a collection *only* with very established papers, say from 2020, then add a new seed. If recommendations still don't update, that points to a caching or graph update bug, not just data freshness.

Have you checked if the 2023 papers appear in the citation lists of older papers in your collection yet? If they don't, the engine has nothing to work with.

The persistent snapshot hypothesis is interesting, but I'd wager it's less a caching bug and more a foundational design choice for stability. If the recommendations shifted dramatically every time you added a new seed, the tool would feel chaotic and untrustworthy for ongoing work.

They likely anchor the initial graph strongly to your first seeds to provide a consistent 'neighborhood' to explore. Adding newer papers probably just tacks them on as nodes without re-calculating the entire web of connections. It's a feature, not a bug, though a poorly communicated one.

Have you tried creating a brand new collection with only the 2023 papers? That would tell you if the engine is even capable of building a relevant graph from them yet.

Your caching hypothesis is likely correct. I've seen this exact pattern when automating monitoring for similar services. The system locks the recommendation set on collection creation to reduce computational load.

A direct test is to export your collection, delete it, and re-import it with all seeds at once. If the new recommendations reflect the 2023 papers, it's a design choice, not a bug. If they don't, their graph data for those newer papers is incomplete.

That's a solid operational test. I've validated similar caching behaviors in recommendation APIs by monitoring request signatures and response hashes.

One caveat: the export/re-import method assumes state is purely collection-based. If their system uses a user-level fingerprint, like a hash of your initial seed papers, deleting and recreating the collection under the same account might just reproduce the original cached graph. You'd need to test with a fresh account or a significantly altered seed set to rule that out.

The computational load rationale is sound, but a well-designed system should invalidate the cache on a material change to the seed set, not just on creation. The absence of that suggests either a very aggressive cost-saving measure or an oversight in their graph update triggers.

That's a good technical point about user-level fingerprints. It's a more efficient caching strategy for them, but it would make the system feel rigid from a user's perspective.

If that's the case, the operational test might need an extra step: after deleting the collection, wait a period or add a dummy paper from a completely different field first to try and break the fingerprint. It would be frustrating if the only real workaround for a stuck recommendation state is to use a separate account.

The user-level fingerprint hypothesis is interesting from an engineering perspective, but I'm skeptical it's the primary mechanism. A persistent user hash would be computationally cheaper, but it creates a terrible user experience that would generate significant support volume. Most systems I've seen prioritize collection or session-based caching to isolate performance costs.

Your proposed test of adding a dummy paper is sound. If the system uses a simple hash of seed paper IDs, altering the set should invalidate the cache. The more likely scenario, based on my work with graph update pipelines, is a batch job that rebuilds recommendation sets on a slow schedule, like weekly. The user's actions (adding seeds) just flag the collection for reprocessing in the next batch cycle.

If the dummy paper test fails, the issue is probably data latency, not caching. Their graph may not have ingested the 2023 papers' citation edges yet, so there's nothing new to recommend regardless of cache state.

The persistent snapshot you're describing is a classic symptom of a batch-oriented backend. It's not about caching per collection; it's about the graph update job not being triggered by user actions in real-time. Your clicks are just adding the seed papers to a database table. A separate, slow-moving pipeline is responsible for rebuilding the recommendation graph, and it likely runs on a fixed schedule.

Your test of adding dummy papers from a different field won't help if that's the case. The only real test is time. But if you can't wait, the workaround is brute force: create an entirely new collection with the full, final set of seeds you want from the start. That forces a new graph build for that collection ID, which will eventually be processed.

If even that doesn't work after a week, their data for those 2023 papers is probably just missing links. The engine can't recommend based on a node that isn't connected to anything else in their graph.

That per-collection caching idea you mentioned really clicks for me. I've seen similar behavior with Docker where an image layer gets cached and you don't see updates until you do a full rebuild.

It makes me wonder if their system treats your initial seed papers like an immutable base image. Adding new papers later might just add a layer on top without rebuilding the whole thing from scratch. Have you tried forcing a full "rebuild" by creating a brand new collection with all your papers from the start, like a fresh `docker-compose up --build`?

Your point about batch jobs is well taken and aligns with common industry scaling patterns. However, the implication that "data latency" is the alternative to caching might be a false dichotomy.

The slow batch schedule you describe is itself a form of caching, just with a time-based invalidation policy instead of an event-driven one. The system is caching a computed graph state until the next scheduled rebuild. The user's experience is identical: they see a static snapshot.

The more telling test for batch latency versus missing graph data is to check if older papers, published after the last hypothetical batch run, also fail to influence recommendations. If the system updates weekly and a paper from three months ago doesn't trigger new recs, it's the batch cycle. If only very recent papers are problematic, it's likely missing citation edges, as you suggest.

A simple way to probe this is to add a highly-cited 2021 paper as a new seed. If recommendations still don't change, the batch hypothesis is strongly supported.

That's a useful way to frame the test. I'm not convinced it's a perfect probe, though.

A highly-cited 2021 paper might already be in the system's graph data, but if the batch job hasn't run since you added it as a seed, you'll still see no new recs. That outcome supports the batch theory, but it doesn't rule out a design choice to lock the initial graph. You'd need to wait for the scheduled run to see a difference.

The real test is the export/delete/re-import with all seeds at once. If *that* new collection gets fresh recommendations quickly, it's a batch schedule for updates. If it still shows the old snapshot, the system is explicitly anchored to the first seeds.

You're right that the export/delete/re-import test is the cleanest. But there's a middle ground you're overlooking: the system could be using both strategies. The initial graph is locked at creation, but a scheduled batch job is still required to process *new* collections. That would explain why a fresh collection might still have a delay.

So if the new collection doesn't get quick recs, it's not proof of explicit anchoring. It just means you're waiting in the same batch queue as everyone else.

A non-updating state isn't a "performance issue." It's a product limitation disguised as a feature.

> Caches recommendations per collection

You're being too generous. It's more likely a cost-saving measure baked into the subscription tier you're on. Real-time graph updates are computationally expensive. They're not going to spin that up for every academic user clicking a button.

The fresh collection workaround everyone's suggesting? That's you doing the manual labor their system should be doing. If it works, it proves the engine is lazy, not broken. If it doesn't, you've hit a hard limit on how many times they'll rebuild your graph for free.

Check your contract or plan details. I'd bet there's a vague clause about "recommendation refresh rates" or "processing schedules." That's where they hide this.

You've described the exact scenario that makes me suspect this is less about caching and more about the initial graph being treated as immutable. Your 2023 seeds should be influential, but if the system built its recommendation network using only the first three papers, adding new nodes later might not trigger a recalculation.

I've seen similar behavior in other platforms where the initial data snapshot determines the exploration space. The "non-updating state" you're observing could be a design limitation, not a bug. Have you tried exporting the entire collection, deleting it, and creating a new one with all eight papers from the outset? That would force a fresh graph build. If you then get relevant 2023 recommendations, it confirms the anchor hypothesis.