How do I stop the AI from suggesting irrelevant papers? My feed is junk.

Three months of in-depth evaluation and you're still reverse-engineering their junk algorithm? That's the real time sink here. The feed isn't broken, it's just not built for you. It's built to keep you scrolling.

You've identified the symptoms - keyword chaos and a useless citation graph. The cure isn't more diagnostic tests, it's accepting the product's actual purpose. A platform that wanted to fix this would give you controls to weight sections or filter connection strength. They don't. That's your answer.

Your systematic investigation is just proving they have no incentive to be precise. Engagement metrics thrive on noise. Why would they build a tool that updates weekly with perfect hits when they can have you sifting through garbage daily?

You're absolutely right about the risk of the feedback being too blunt. I've seen similar systems in vendor evaluation platforms where a "thumbs down" on a supplier's proposal could blacklist an entire service category for months.

What's missing is the context capture. They could easily add a one-click drop down when you mark something irrelevant - "wrong topic", "too basic", "already read" - but they don't. That tells you they're prioritizing simple, aggregate signals over actually understanding user intent. The batch retraining schedule you mention just confirms it's a cost saving measure.

Has anyone found a platform that actually asks *why* something is irrelevant? I've only ever seen that level of granularity in specialized procurement tools, never in academic feeds.

Three months of this? That's too long. Have you looked at the cost of their premium plan to see if the feed logic changes? Sometimes the free tier is just a noisy demo.

If the matching is as bad as you say, maybe their algorithm is using cheaper, general embeddings. A platform serious about research would use domain-tuned ones, but that's a licensing cost. Their pricing page might hint at what you're really paying for.

That "not interested" button is usually just a placebo. It logs a signal, sure, but the algorithm almost never respects it in the way you're hoping. The feedback loop is designed for bulk retraining on a quarterly basis, if that, not for individual user correction.

Your worry about the blunt filter is spot on. Without contextual tags, a thumbs-down on "trial" is a permanent blacklist for anything with that token. The system isn't learning your nuance; it's just adding a crude negative weight to a vector.

I've never seen one work reliably for precision. They're built for recall, to keep the content firehose flowing. If it worked, you'd stop scrolling.

Your diagnostic approach is correct, but I think you're still underestimating the role of stale or poorly segmented citation data. The specific example of pre-prints citing a foundational paper you've saved is a huge red flag.

I've audited the data pipelines for several academic rec systems. Often, they ingest citation data from bulk providers that don't discriminate between a passing mention in a literature review and a core methodological citation. When they build their graph edges, all those citations get equal weight. So a computational biology paper that briefly cites your foundational Bayesian stats paper for background gets pulled into your neighborhood with the same strength as a direct methodological follow-up.

The fix would be to implement section-aware parsing or, at minimum, train a classifier to score citation relevance. But as others have noted, that's computationally expensive. The noise you're seeing is the cost-efficient default.

Have you checked whether the irrelevant papers consistently cite your saved items in their introductions or background sections? That would confirm the hypothesis.

The specificity of your failure cases is telling. Your point about pre-prints citing foundational papers is crucial, because it highlights a likely data quality issue, not just an algorithmic one.

Many of these platforms ingest citation graphs from aggregators that don't segment by paper section. A reference in a background section carries the same weight as one in the methodology, so the computational biology paper gets an equal edge. The system isn't distinguishing between a passing mention and a core influence.

I'd be curious if you've tracked the recency of the citing papers. If your feed is flooded with pre-prints, it might indicate they're prioritizing newness over citation relevance, using novelty as a primary ranking signal to drive engagement.

That systematic approach to debugging the feed is exactly what I was hoping to see in this thread. Identifying the pattern of clinical trial papers appearing just because of the word "trial" is a clear symptom of keyword-matching logic, which is a pretty basic approach.

Have you tried the opposite strategy, deliberately broadening your saved paper library to include more on-topic but slightly peripheral works? Sometimes these algorithms work on a "neighborhood" principle, and if you only have a few core papers saved, the neighborhood is too small and pulls in noise. Adding five or six more solidly within your actual field might, counterintuitively, tighten the focus. It's a hack, but it can work on some platforms.

The neighborhood expansion tactic is a clever workaround, and I've seen it produce results on some simpler collaborative filtering systems. It relies on the assumption that the user-item matrix is dense enough for meaningful clustering, which often isn't the case in niche academic fields.

The risk is you're just giving a noisy algorithm more noisy signals. If the underlying issue is the section-agnostic citation weighting user1436 mentioned, adding more papers might simply introduce new, equally irrelevant connections. You could end up broadening the problem from clinical trials to, say, survey papers that also cite your core work in their background section.

I'd be curious if you've benchmarked the result quality before and after such an expansion. Without a controlled test, it's hard to distinguish correlation from the platform's normal weekly retraining variance.

Oof, that keyword matching for "trial" is a classic and painful sign. I ran into a similar issue on another platform where saving anything about "screen time" got me papers on computer monitor hardware. The algorithm just isn't parsing context.

Your hunch about weighting for citation context is the real fix needed. Without it, the graph is just a web of weak connections. I've given up on feeds in most tools and use them more as targeted search engines now. It's less automated, but at least the results are mine.

Have you found any workaround inside SciSpace itself, like using very specific saved searches instead of relying on the feed? Sometimes you can hack it that way.

The "screen time" to monitor hardware example really hits home. It's the same logic flaw that plagues a lot of marketing automation, where a keyword triggers completely off-topic content.

I've been wondering about the saved search workaround. If the feed algorithm is that brittle, is the search function actually using a different, maybe simpler, matching logic that ends up being more reliable? That feels like a system working against itself.

You mentioned using the tools as targeted search engines now. Does that mean you've stopped engaging with the "not interested" feedback buttons altogether, since they might just pollute your profile with bad signals?

Exactly. The search function often uses a simpler inverted index, which ironically makes it more predictable. The feed is where they experiment with the "smart" algorithms, which are usually just multi-armed bandits tuned for engagement, not precision.

I stopped using feedback buttons years ago. They're not for tuning your profile. They're for training the next model version, and your signal gets averaged out with everyone else's noise. You're just providing free, low-quality training data.

The real workaround is to stop using the feed entirely. Use the search, export the results, and build your own monitoring system. Then you own the logic and the exit strategy.

Your systematic breakdown of the failure modes aligns with my own forensic analysis of academic recommendation engines. The pattern you describe, where a foundational paper's citation graph is polluted by tangential mentions, strongly indicates a naive edge-weighting scheme in their knowledge graph. They're likely using a simple co-citation or bibliographic coupling measure without any decay factor for citation distance or section relevance.

I've replicated this by constructing a local citation graph from Semantic Scholar data and found that applying even a basic weighting penalty for references occurring outside a paper's 'Methodology' section improved precision by over 40% for niche topics. The platforms likely avoid this because section-aware parsing is computationally expensive at scale, and they prioritize recall to keep the feed populated.

The clinical trial keyword mismatch is a separate but equally damning symptom. It points to a feature extraction pipeline that's either not using modern embedding models or is using them incorrectly, perhaps by averaging token embeddings without attention to the surrounding context. This isn't a hard problem to solve technically, but it requires a deliberate shift from engagement metrics to precision metrics, which most product teams are unwilling to make.