Short answer
Elicit, a research assistant built by the research lab Ought on top of GPT-3, lets you type a research question in plain language and returns relevant papers with a short generated answer for each, which you can view as a table, filter, star and download. It speeds up the first sweep of a literature review, but every generated answer still has to be checked against the paper itself.
Follow-up question How do you check the summaries against the papers?
A literature review usually starts with a long, tedious stage: trying keyword after keyword in a database, opening dozens of abstracts, and copying the useful bits into a spreadsheet. Tools built on large language models are starting to take on part of that work. One of them is Elicit, made by Ought, a machine learning research lab. Its own description is short: a research assistant powered by GPT-3 that helps you search publications, brainstorm research questions and classify data.
What makes Elicit different from a regular search engine is the input. You do not have to guess the right keywords. You ask a question as you would ask a colleague, and Elicit looks for papers that address it.
What Elicit does in its literature review workflow
The main workflow is called "Explore research questions." You type a question, and Elicit returns a list of papers. For each one it can show:
- An answer to your question, a short line Elicit writes for that paper;
- The most relevant sentence, the passage it picked as the best match;
- Citation counts, both total and "influential" citations, which hint at how much attention a paper has received;
- A link to Semantic Scholar, a free academic search engine where you can read the abstract and find the full text.
You can switch between a list and a table, filter by publication year and by study type (for example systematic reviews or meta-analyses), and star the papers that look useful. Starring matters: Elicit can then load more papers similar to the ones you starred, and clear away the rest. When you are done, the results can be downloaded as a CSV file, the plain table format that any spreadsheet program opens.
A worked search, step by step
Suppose a graduate student wants to know whether short mindfulness programs reduce anxiety in university students. Here is a sensible way to use Elicit for the first pass.
- Ask a focused question. Something like "Do brief mindfulness interventions reduce anxiety in university students?" A question that names the intervention, the outcome and the population gives better matches than "mindfulness anxiety."
- Filter by study type. Start with systematic reviews and meta-analyses. A meta-analysis combines the results of many studies with statistics, so a few good ones can map the field quickly.
- Star what fits. Read the generated answers and the relevant sentences, star the papers that match your population and outcome, then ask for more like the starred ones.
- Widen the net. Remove the study type filter to find individual trials, and set a year range if you only want recent work.
- Export and build your own table. Download the CSV, open it in a spreadsheet, and add the columns your review needs.
A simple findings table might look like this before any checking:
| Paper | Year | Study type | Who was studied | Main finding (Elicit's answer) | Checked against abstract? |
|---|---|---|---|---|---|
| (title) | (year) | meta-analysis | (from abstract) | (generated line) | not yet |
| (title) | (year) | randomized trial | (from abstract) | (generated line) | not yet |
The last column is the important one. Until it says "yes," a row is a lead, not a finding.
Try it: Pick a question from your own field and run it in Elicit twice: once as a plain-language question and once as three or four keywords. Star five useful papers from each run, export both lists, and count how many papers appear in only one of them.
What these tools are good for, and what they are not
Elicit is strong at the early, broad stage of a review. It can surface papers that a keyword search might miss because they use different vocabulary, and it gives you a quick sense of how much has been published on a question. The table view and CSV export save hours of copying.
It is not a replacement for reading. The generated answer is produced by a language model, and the interface itself reminds users that this is a new technology and that results call for judgment. OpenAI, which makes GPT-3, says plainly that even its newest instruction-following models still sometimes make up facts. A summary line can sound confident and still misstate the direction of an effect, the population or the size of a study.
There are coverage limits as well. A tool can only return papers it can find and read, and many studies sit behind paywalls or exist only as full text without a good abstract. A systematic review still needs the formal searches, inclusion rules and documentation that your field expects.
How do you check the summaries against the papers?
Treat every generated line as a claim to verify. Open the paper's page through the Semantic Scholar link and read the abstract yourself. Then check four things against the row in your table: the population (who was studied), the intervention or exposure, the outcome that was measured, and the direction of the result. Most errors in a generated summary show up in one of those four.
For anything you plan to cite, go beyond the abstract. Abstracts compress results and sometimes leave out limitations, so read the methods and results sections, and note the sample size and the main numbers in your own words. If you cannot get the full text, mark the row as "abstract only" so you remember its status.
A practical routine is to spot-check in layers. Check every paper you will cite. Then check a random sample of the rest, perhaps one in five. If the sample turns up errors, check them all. Over time you will learn where the tool tends to slip in your field, and you can decide how much of the first sweep to trust it with. The goal is speed in finding papers and care in describing them.
Sources
- Elicit: The AI Research Assistant — Ought
- Aligning Language Models to Follow Instructions — OpenAI, January 27, 2022