
After studying this material, you should be able to:
Scientists using AI for literature synthesis have unique demands that general chatbots don't handle well:
| General AI User | Scientific Researcher |
|---|---|
| Short keyword queries | Long queries with many constraints |
| One-off answers | Working research artifacts they return to |
| Approximate answers acceptable | Must stay grounded in evidence |
| Speed less critical | Needs to be fast AND accurate |
Think of it this way: Imagine asking an AI to summarize 50 research papers on a drug treatment. A general model might write something that sounds authoritative but quietly turns a finding from "worked in 40-year-old males" into "works for patients generally." That subtle shift is dangerous in science.
Three core problems existed:
INPUT: Research question + Retrieved literature excerpts
↓
AstaBrief 8B Model
↓
OUTPUT: Cited scientific report (in ONE pass)
The previous system (Thinking mode) worked like this:
Step 1: Summarize each snippet
Step 2: Cluster summaries
Step 3: Write section 1
Step 4: Write section 2
Step 5: Write section N...
AstaBrief skips all intermediate steps and writes the full report directly. This is why it achieves 3.5× faster generation (51.1 seconds vs 178.5 seconds).
Key insight: More steps ≠ better output. The team found they could skip expensive intermediate stages without sacrificing quality.
Base Model (Qwen3-8B)
↓
Stage 1: Supervised Fine-Tuning (SFT)
↓
Stage 2: Direct Preference Optimization (DPO)
↓
AstaBrief 8B
SFT teaches the model by showing it examples of correct behavior:
"Here is a question + literature excerpts → Here is what a good report looks like"
The model learns to imitate the target outputs.
Starting point: Real user queries from Asta (not synthetic benchmarks)
Why real queries matter: Scientists ask differently than regular users. They provide substantial context, multiple constraints, and relationships between concepts — not just keywords.
Filtering pipeline:
Raw user logs (hundreds of thousands)
↓
Remove: beta testers, bots, short queries
Remove: non-English, non-scientific, personal info
↓
90,000 research-focused queries
↓
Generate full reports using Claude 3.5/3.7, o3, o4-mini, GPT-4.1
↓
Quality filtering
↓
47,000 usable training examples
This is where the team made their most important discovery. They tested four filters:
| Filter | What It Measures | Effect |
|---|---|---|
| Output-to-input token ratio | Too much text from too little evidence = noisy | Moderate |
| Citation relevance | Are cited papers actually relevant? | Moderate |
| Citation density | What % of claims have citations? | Strongest gain |
| Citation diversity | Does report use many papers or just a few? | Moderate |
Filtering for citation density was the single most powerful improvement.
A report that consistently cites its claims is demonstrating the exact behavior you want: grounding statements in evidence. More complex filter combinations didn't add meaningful gains beyond this simple signal.
Practical implication: You don't need elaborate methods to improve scientific AI. Identifying and filtering for the specific behavior you care about (citation grounding) is more effective than adding complexity.
Where SFT shows the model "here's a good example," DPO teaches through comparison:
"Given these two reports, Report A is better than Report B — learn why"
Same query → Report A (from Claude pipeline)
→ Report B (from o3, o4-mini, DeepSeek-V3, or DeepSeek-R1)
↓
Two judges evaluate: GPT-4.1 AND DeepSeek-R1
↓
Only keep pairs where BOTH judges agree
(95% agreement with human preferences)
↓
~6,000 clean preference examples
Using multiple generators and requiring agreement between two judges:
DPO on top of a strong SFT checkpoint pushed AstaBrief into competitive range with Claude-powered pipelines.
The order matters: get SFT right first, then refine with DPO.
The team considered RL-based training (which has shown strong results in other work) but chose SFT + DPO instead.
| Approach | Pros | Cons |
|---|---|---|
| RL-based training | Can achieve high performance | Unstable, expensive, hard to debug |
| SFT + DPO | Cheaper, stable, easier to iterate | Requires very high data quality |
The tradeoff: If you use a simpler optimization method, your data quality must compensate. This is why the team invested heavily in data filtering rather than training complexity.
1. Rubric Score → Does the report cover necessary content?
2. Answer Precision → Is each paragraph relevant to the question?
3. Citation Precision → Does each citation support its attached claim?
4. Citation Recall → Are all claims fully supported by citations?
Citation support alone isn't enough. A model can cite the right paper and still misrepresent what it says. Common failure modes:
| Failure Type | Example |
|---|---|
| Sample generalization | "Worked in 40-year-old males" → "Works for patients" |
| Tense shifting | "Researchers found..." → "Research shows..." (sounds universal) |
| Descriptive → prescriptive | "X was associated with Y" → "Clinicians should do X" |
Each step sounds minor. Cumulatively, they can make weak evidence sound like strong consensus.
A cited sentence can be technically related to its source while still overstating what researchers actually established.
Future evaluations need to test not just whether a claim is cited, but whether the model preserved the evidentiary scope of the original finding.
Among 374 users who tried Fast mode:
29.1% → Used it on 2+ separate days (returning users)
23% → Switched to Fast mode and never went back
18% → Used both modes strategically (~40% Fast mode)
3.67 → Average report threads generated per user
What this tells us: Users aren't just trying it once. They're integrating it into their workflow, which validates the quality-speed tradeoff.
| Lesson | Application |
|---|---|
| Real user queries > synthetic benchmarks | Training data should reflect actual use |
| Simple, targeted filters > complex combinations | Citation density filter was most powerful |
| SFT data quality compensates for simpler optimization | Invest in data, not just training methods |
| One-pass generation can match multi-step pipelines | Architectural simplicity has real value |
| Open weights enable institutional deployment | Privacy-sensitive research needs local models |
Scientific specialization isn't primarily about adding more scientific text to pretraining.
The composition and quality of post-training data — and whether it demonstrates behaviors like grounding and attribution — can materially change how the resulting model performs.
PROBLEM
Scientists need fast, grounded, verifiable reports
↓
APPROACH
Start with Qwen3-8B (small, open, capable)
↓
DATA STRATEGY
Real queries → Generate reports → Filter aggressively
(Citation density filter = most important signal)
↓
TRAINING
SFT (learn from good examples)
+ DPO (learn from comparisons)
= Better than either alone
↓
ARCHITECTURE
One-pass generation (skip intermediate steps)
↓
RESULT
3.5× faster, competitive quality, open weights
Users can run it locally on sensitive research