Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The LFRQA dataset was introduced in the paper RAG-QA Arena: Evaluating Domain Robustness for Long-Form Retrieval-Augmented Question Answering. It features 1,404 science questions (along with other categories) that have been human-annotated with answers. This tutorial walks through the process of setting up the dataset for use and benchmarking.
First, we need to obtain the annotated dataset from the official repository:
LFRQA is built upon Robust-QA, so we must download the relevant documents:
For more details, refer to the original paper: RAG-QA Arena: Evaluating Domain Robustness for Long-Form Retrieval-Augmented Question Answering.
We now load the documents into a pandas dataframe:
RobustQA consists on 1.7M documents, so building the whole index will take around 3 hours.
If you want to run a test, you can use a portion of the dataset and the questions that can be answered only on those documents.
We now create the document directory and store each document as a separate text file, so that paperqa can build the index.
The manifest file keeps track of document metadata for the dataset. We need to fill some fields so that paperqa doesn’t try to get metadata using llm calls. This will make the indexing process faster.
Finally, we load the questions and filter them to ensure we only include questions that reference the selected documents:
From now on, we will be using the paperqa library, so we need to install it:
Copy the following to a file and run it. Feel free to adjust the concurrency as you like.
You don’t need any api keys for building this index because we don't discern any citation metadata, but you do need LLM api keys to answer questions.
Remember that this process is quick for small portions of the dataset, but can take around 3 hours for the whole dataset.
After this runs, you will get an answer!
After you have built the index, you are ready to run the benchmark.
Copy the following into a file and run it. To run this, you will need to have the ldp and fhaviary[lfrqa] packages installed.
After running this, you can find the results in the data/rag-qa-benchmarking/results folder. Here is an example of how to read them:
PaperQA2 now natively supports querying clinical trials in addition to any documents supplied by the user. It uses a new tool, the aptly named clinical_trials_search tool. Users don't have to provide any clinical trials to the tool itself, it uses the clinicaltrials.gov API to retrieve them on the fly. As of January 2025, the tool is not enabled by default, but it's easy to configure. Here's an example where we query only clinical trials, without using any documents:
You can see the in-line citations for each clinical trial used as a response for each query. If you'd like to see more data on the specific contexts that were used to answer the query:
Using Settings.from_name('search_only_clinical_trials') is a shortcut, but note that you can easily add clinical_trial_search into any custom Settings by just explicitly naming it as a tool:
We now see both papers and clinical trials cited in our response. For convenience, we have a Settings.from_name that works as well:
And, this works with the pqa cli as well:
This tutorial is available as a Jupyter notebook .
This tutorial aims to show how to use the Settings class to configure PaperQA. Firstly, we will be using OpenAI and Anthropic models, so we need to set the OPENAI_API_KEY and ANTHROPIC_API_KEY environment variables. We will use both models to make it clear when paperqa agent is using either one or the other. We use python-dotenv to load the environment variables from a .env file. Hence, our first step is to create a .env file and install the required packages.
We will use the lmi package to get the model names and the .papers directory to save documents we will use.
Within this Settings object, I'd like to discuss specifically how the llms are configured and how paperqa looks for papers.
A common source of confusion is that multiple llms are used in paperqa. We have llm, summary_llm, agent_llm, and embedding. Hence, if llm is set to an Anthropic model, summary_llm and agent_llm will still require a OPENAI_API_KEY, since OpenAI models are the default.
Among the objects that use llms in paperqa, we have llm, summary_llm, agent_llm, and embedding:
llm: Main LLM used by the agent to reason about the question, extract metadata from documents, etc.
summary_llm: LLM used to summarize the papers.
agent_llm: LLM used to answer questions and select tools.
embedding: Embedding model used to embed the papers.
Let's see some examples around this concept. First, we define the settings with llm set to an OpenAI model. Please notice this is not an complete list of settings. But take your time to read through this Settings class and all customization that can be done.
As it is evident, Paperqa is absolutely customizable. And here we reinterate that despite this possible fine customization, the defaults are good for most cases. Although, the user is welcome to explore the settings and customize the paperqa to their needs.
We also set settings.verbosity to 1, which will print the agent configuration. Feel free to set it to 0 to silence the logging after your first run.
Which probably worked fine. Let's now try to remove OPENAI_API_KEY and run again the same question with the same settings.
It would obviously fail. We don't have a valid OPENAI_API_KEY, so the agent will not be able to use OpenAI models. Let's change it to an Anthropic model and see if it works.
Notice that we redefined settings.agent.paper_directory and settings.agent.index settings. Paperqa actually uses the setting from settings.agent. However, for convenience, we implemented an alias in settings.paper_directory and settings.index_directory.
Paperqa returns a PQASession object, which contains not only the answer but also all the information gatheres to answer the questions. We recommend printing the PQASession object (print(response.session)) to understand the information it contains. Let's check the PQASession object:
In addition to the answer, the PQASession object contains all the references and contexts used to generate the answer.
Because paperqa splits the documents into chunks, each chunk is a valid reference. You can see that it also references the page where the context was found.
Lastly, PQASession.session.contexts contains the contexts used to generate the answer. Each context has a score, which is the similarity between the question and the context. Paperqa uses this score to choose what contexts is more relevant to answer the question.
Thank you for your interest in contributing to PaperQA! Here are some guidelines to help you get started.
We use for our local development.
Install uv by following the instructions on the .
Run the following command to install all dependencies and set up the development environment:
If you prefer to use pip for installing the package in development mode, you can do so by running:
Use the following commands:
Run tests (requires an OpenAI key in your environment)
Run pre-commit for formatting and type checking
Run mypy, refurb, or pylint directly:
pytest-recording and VCR cassettesTo record a new VCR cassette:
Please ensure cassettes are less than 1 MB to keep tests loading quickly.
Happy coding!
The Settings class is used to configure the PaperQA settings. Official documentation can be found and the open source code can be found .
Here is a basic example of how to use the Settings class. We will be unnecessarily verbose for the sake of clarity. Please notice that most of the settings are optional and the defaults are good for most cases. Refer to the for more information.
Now the agent is able to use Anthropic models only and although we don't have a valid OPENAI_API_KEY, the question is answered because the agent will not use OpenAI models. See that we also changed the embedding because it was using text-embedding-3-small by default, which is a OpenAI model. Paperqa implements a few embedding models. Please refer to the for more information.
See our GitHub Actions for further reference.
We use the plugin to create VCR cassettes to cache HTTP requests, making our unit tests more deterministic.
And the new cassette(s) should appear in .
Our configuration for pytest-recording can be found in . This includes header removals (e.g. OpenAI authorization key) from responses to ensure sensitive information is excluded from the cassettes.
"Magnetic hill" and "Mystery hill" redirect here. For other uses, see Magnetic Hill (disambiguation) and Mystery Hill (disambiguation).
A gravity hill, also known as a magnetic hill, mystery hill, mystery spot, gravity road, or anti-gravity hill, is a place where the layout of the surrounding land produces an illusion, making a slight downhill slope appear to be an uphill slope. Thus, a car left out of gear will appear to be rolling uphill against gravity.
Although the slope of gravity hills is an illusion, sites are often accompanied by claims that magnetic or supernatural forces are at work. The most important factor contributing to the illusion is a completely or mostly obstructed horizon. Without a horizon, it becomes difficult for a person to judge the slope of a surface, as a reliable reference point is missing, and misleading visual cues can adversely affect the sense of balance. Objects which one would normally assume to be more or less perpendicular to the ground, such as trees, may be leaning, offsetting the visual reference.
A 2003 study looked into how the absence of a horizon can skew the perspective on gravity hills, by recreating a number of antigravity places in the lab to see how volunteers would react. In conclusion, researchers from the Universities of Padua and Pavia in Italy found that without a true horizon in sight, the human brain could be tricked by common landmarks such as trees and signs.
The illusion is similar to the Ames room, in which objects can also appear to roll against gravity.
The opposite phenomenon—an uphill road that appears flat—is known in bicycle racing as a "false flat".
The Crooked House – a pub (now demolished) with an internal gravity hill illusion.
You can use papers from https://openreview.net/ as your database! Here's a helper that fetches a list of all papers from a selected conference (like ICLR, ICML, NeurIPS), queries this list to find relevant papers using LLM, and downloads those relevant papers to a local directory which can be used with paper-qa on the next step. Install openreview-py with
and get your username and password from the website. You can put them into .env file under OPENREVIEW_USERNAME and OPENREVIEW_PASSWORD variables, or pass them in the code directly.
It's been a while since we've tested this - so let us know if it runs into issues!
If you use Zotero to organize your personal bibliography, you can use the paperqa.contrib.ZoteroDB to query papers from your library, which relies on pyzotero.
Install pyzotero via the zotero extra for this feature:
First, note that PaperQA2 parses the PDFs of papers to store in the database, so all relevant papers should have PDFs stored inside your database. You can get Zotero to automatically do this by highlighting the references you wish to retrieve, right clicking, and selecting "Find Available PDFs". You can also manually drag-and-drop PDFs onto each reference.
To download papers, you need to get an API key for your account.
Get your library ID, and set it as the environment variable ZOTERO_USER_ID.
For personal libraries, this ID is given here at the part "Your userID for use in API calls is XXXXXX".
For group libraries, go to your group page https://www.zotero.org/groups/groupname, and hover over the settings link. The ID is the integer after /groups/. (h/t pyzotero!)
Create a new API key here and set it as the environment variable ZOTERO_API_KEY.
The key will need read access to the library.
With this, we can download papers from our library and add them to PaperQA2:
which will download the first 20 papers in your Zotero database and add them to the Docs object.
We can also do specific queries of our Zotero library and iterate over the results:
You can read more about the search syntax by typing zotero.iterate? in IPython.
If you want to search for papers outside of your own collection, I've found an unrelated project called paper-scraper that looks like it might help. But beware, this project looks like it uses some scraping tools that may violate publisher's rights or be in a gray area of legality.
PaperQA2 is a package for doing high-accuracy retrieval augmented generation (RAG) on PDFs or text files, with a focus on the scientific literature. See our recent 2024 paper to see examples of PaperQA2's superhuman performance in scientific tasks like question answering, summarization, and contradiction detection.
In this example we take a folder of research paper PDFs, magically get their metadata - including citation counts with a retraction check, then parse and cache PDFs into a full-text search index, and finally answer the user question with an LLM agent.
Question: Has anyone designed neural networks that compute with proteins or DNA?
The claim that neural networks have been designed to compute with DNA is supported by multiple sources. The work by Qian, Winfree, and Bruck demonstrates the use of DNA strand displacement cascades to construct neural network components, such as artificial neurons and associative memories, using a DNA-based system (Qian2011Neural pages 1-2, Qian2011Neural pages 15-16, Qian2011Neural pages 54-56). This research includes the implementation of a 3-bit XOR gate and a four-neuron Hopfield associative memory, showcasing the potential of DNA for neural network computation. Additionally, the application of deep learning techniques to genomics, which involves computing with DNA sequences, is well-documented. Studies have applied convolutional neural networks (CNNs) to predict genomic features such as transcription factor binding and DNA accessibility (Eraslan2019Deep pages 4-5, Eraslan2019Deep pages 5-6). These models leverage DNA sequences as input data, effectively using neural networks to compute with DNA. While the provided excerpts do not explicitly mention protein-based neural network computation, they do highlight the use of neural networks in tasks related to protein sequences, such as predicting DNA-protein binding (Zeng2016Convolutional pages 1-2). However, the primary focus remains on DNA-based computation.
PaperQA2 is engineered to be the best agentic RAG model for working with scientific papers. Here are some features:
A simple interface to get good answers with grounded responses containing in-text citations.
State-of-the-art implementation including document metadata-awareness in embeddings and LLM-based re-ranking and contextual summarization (RCS).
Support for agentic RAG, where a language agent can iteratively refine queries and answers.
Automatic redundant fetching of paper metadata, including citation and journal quality data from multiple providers.
A usable full-text search engine for a local repository of PDF/text files.
A robust interface for customization, with default support for all LiteLLM models.
By default, it uses OpenAI embeddings and models with a Numpy vector DB to embed and search documents. However, you can easily use other closed-source, open-source models or embeddings (see details below).
PaperQA2 depends on some awesome libraries/APIs that make our repo possible. Here are some in no particular order:
We've been working on hard on fundamental upgrades for a while and mostly followed SemVer. meaning we've incremented the major version number on each breaking change. This brings us to the current major version number v5. So why call is the repo now called PaperQA2? We wanted to remark on the fact though that we've exceeded human performance on many important metrics. So we arbitrarily call version 5 and onward PaperQA2, and versions before it as PaperQA1 to denote the significant change in performance. We recognize that we are challenged at naming and counting at FutureHouse, so we reserve the right at any time to arbitrarily change the name to PaperCrow.
Version 5 added:
A CLI pqa
Agentic workflows invoking tools for paper search, gathering evidence, and generating an answer
Removed much of the statefulness from the Docs object
A migration to LiteLLM for compatibility with many LLM providers as well as centralized rate limits and cost tracking
A bundled set of configurations (read here)) containing known-good hyperparameters
Note that Docs objects pickled from prior versions of PaperQA are incompatible with version 5, and will need to be rebuilt. Also, our minimum Python version was increased to Python 3.11.
To understand PaperQA2, let's start with the pieces of the underlying algorithm. The default workflow of PaperQA2 is as follows:
1. Paper Search
- Get candidate papers from LLM-generated keyword query
- Chunk, embed, and add candidate papers to state
2. Gather Evidence
- Embed query into vector
- Rank top k document chunks in current state
- Create scored summary of each chunk in the context of the current query
- Use LLM to re-score and select most relevant summaries
3. Generate Answer
- Put best summaries into prompt with context
- Generate answer with prompt
The tools can be invoked in any order by a language agent. For example, an LLM agent might do a narrow and broad search, or using different phrasing for the gather evidence step from the generate answer step.
For a non-development setup, install PaperQA2 (aka version 5) from PyPI. Note version 5 requires Python 3.11+.
For development setup, please refer to the CONTRIBUTING.md file.
PaperQA2 uses an LLM to operate, so you'll need to either set an appropriate API key environment variable (i.e. export OPENAI_API_KEY=sk-...) or set up an open source LLM server (i.e. using llamafile. Any LiteLLM compatible model can be configured to use with PaperQA2.
If you need to index a large set of papers (100+), you will likely want an API key for both Crossref and Semantic Scholar, which will allow you to avoid hitting public rate limits using these metadata services. Those can be exported as CROSSREF_API_KEY and SEMANTIC_SCHOLAR_API_KEY variables.
The fastest way to test PaperQA2 is via the CLI. First navigate to a directory with some papers and use the pqa cli:
You will see PaperQA2 index your local PDF files, gathering the necessary metadata for each of them (using Crossref and Semantic Scholar), search over that index, then break the files into chunked evidence contexts, rank them, and ultimately generate an answer. The next time this directory is queried, your index will already be built (save for any differences detected, like new added papers), so it will skip the indexing and chunking steps.
All prior answers will be indexed and stored, you can view them by querying via the search subcommand, or access them yourself in your PQA_HOME directory, which defaults to ~/.pqa/.
PaperQA2 is highly configurable, when running from the command line, pqa --help shows all options and short descriptions. For example to run with a higher temperature:
You can view all settings with pqa view. Another useful thing is to change to other templated settings - for example fast is a setting that answers more quickly and you can see it with pqa -s fast view
Maybe you have some new settings you want to save? You can do that with
and then you can use it with
If you run pqa with a command which requires a new indexing, say if you change the default chunk_size, a new index will automatically be created for you.
You can also use pqa to do full-text search with use of LLMs view the search command. For example, let's save the index from a directory and give it a name:
Now I can search for papers about thermoelectrics:
or I can use the normal ask
Both the CLI and module have pre-configured settings based on prior performance and our publications, they can be invoked as follows:
Inside paperqa/configs we bundle known useful settings:
high_quality
Highly performant, relatively expensive (due to having evidence_k = 15) query using a ToolSelector agent.
fast
Setting to get answers cheaply and quickly.
wikicrow
Setting to emulate the Wikipedia article writing used in our WikiCrow publication.
contracrow
Setting to find contradictions in papers, your query should be a claim that needs to be flagged as a contradiction (or not).
debug
Setting useful solely for debugging, but not in any actual application beyond debugging.
tier1_limits
Settings that match OpenAI rate limits for each tier, you can use tier<1-5>_limits to specify the tier.
If you are hitting rate limits, say with the OpenAI Tier 1 plan, you can add them into PaperQA2. For each OpenAI tier, a pre-built setting exists to limit usage.
This will limit your system to use the tier1_limits, and slow down your queries to accommodate.
You can also specify them manually with any rate limit string that matches the specification in the limits module:
Or by adding into a Settings object, if calling imperatively:
PaperQA2's full workflow can be accessed via Python directly:
Please see our installation docs for how to install the package from PyPI.
The answer object has the following attributes: formatted_answer, answer (answer alone), question , and context (the summaries of passages found for answer). ask will use the SearchPapers tool, which will query a local index of files, you can specify this location via the Settings object:
ask is just a convenience wrapper around the real entrypoint, which can be accessed if you'd like to run concurrent asynchronous workloads:
The default agent will use an LLM based agent, but you can also specify a "fake" agent to use a hard coded call path of search -> gather evidence -> answer to reduce token usage.
Normally via agent execution, the agent invokes the search tool, which adds documents to the Docs object for you behind the scenes. However, if you prefer fine-grained control, you can directly interact with the Docs object.
Note that manually adding and querying Docs does not impact performance. It just removes the automation associated with an agent picking the documents to add.
PaperQA2 is written to be used asynchronously. The synchronous API is just a wrapper around the async. Here are the methods and their async equivalents:
Docs.add
Docs.aadd
Docs.add_file
Docs.aadd_file
Docs.add_url
Docs.aadd_url
Docs.get_evidence
Docs.aget_evidence
Docs.query
Docs.aquery
The synchronous version just calls the async version in a loop. Most modern python environments support async natively (including Jupyter notebooks!). So you can do this in a Jupyter Notebook:
By default, PaperQA2 uses OpenAI's gpt-4o-2024-11-20 model for the summary_llm, llm, and agent_llm. Please see the Settings Cheatsheet for more information on these settings.
We use the lmi package for our LLM interface, which in turn uses litellm to support many LLM providers. You can adjust this easily to use any model supported by litellm:
To use Claude, make sure you set the ANTHROPIC_API_KEY
Or Gemini, by setting the GEMINI_API_KEY from Google AI Studio
You can use llama.cpp to be the LLM. Note that you should be using relatively large models, because PaperQA2 requires following a lot of instructions. You won't get good performance with 7B models.
The easiest way to get set-up is to download a llama file and execute it with -cb -np 4 -a my-llm-model --embedding which will enable continuous batching and embeddings.
Models hosted with ollama are also supported. To run the example below make sure you have downloaded llama3.2 and mxbai-embed-large via ollama.
Embeddings are used to retrieve k texts (where k is specified via Settings.answer.evidence_k) for re-ranking and contextual summarization. If you don't want to use embeddings, but instead just fetch all chunks, disable "evidence retrieval" via the Settings.answer.evidence_retrieval setting.
PaperQA2 defaults to using OpenAI (text-embedding-3-small) embeddings, but has flexible options for both vector stores and embedding choices.
The simplest way to specify the embedding model is via Settings.embedding:
embedding accepts any embedding model name supported by litellm. PaperQA2 also supports an embedding input of "hybrid-<model_name>" i.e. "hybrid-text-embedding-3-small" to use a hybrid sparse keyword (based on a token modulo embedding) and dense vector embedding, where any litellm model can be used in the dense model name. "sparse" can be used to use a sparse keyword embedding only.
Embedding models are used to create PaperQA2's index of the full-text embedding vectors (texts_index argument). The embedding model can be specified as a setting when you are adding new papers to the Docs object:
Note that PaperQA2 uses Numpy as a dense vector store. Its design of using a keyword search initially reduces the number of chunks needed for each answer to a relatively small number < 1k. Therefore, NumpyVectorStore is a good place to start, it's a simple in-memory store, without an index. However, if a larger-than-memory vector store is needed, you can an external vector database like Qdrant via the QdrantVectorStore class.
The hybrid embeddings can be customized:
The sparse embedding (keyword) models default to having 256 dimensions, but this can be specified via the ndim argument.
You can use a SentenceTransformerEmbeddingModel model if you install sentence-transformers, which is a local embedding library with support for HuggingFace models and more. You can install it by adding the local extras.
and then prefix embedding model names with st-:
or with a hybrid model
You can adjust the numbers of sources (passages of text) to reduce token usage or add more context. k refers to the top k most relevant and diverse (may from different sources) passages. Each passage is sent to the LLM to summarize, or determine if it is irrelevant. After this step, a limit of max_sources is applied so that the final answer can fit into the LLM context window. Thus, k > max_sources and max_sources is the number of sources used in the final answer.
You do not need to use papers -- you can use code or raw HTML. Note that this tool is focused on answering questions, so it won't do well at writing code. One note is that the tool cannot infer citations from code, so you will need to provide them yourself.
You may want to cache parsed texts and embeddings in an external database or file. You can then build a Docs object from those directly:
Indexes will be placed in the home directory by default. This can be controlled via the PQA_HOME environment variable.
Indexes are made by reading files in the Settings.paper_directory. By default, we recursively read from subdirectories of the paper directory, unless disabled using Settings.index_recursively. The paper directory is not modified in any way, it's just read from.
The indexing process attempts to infer paper metadata like title and DOI using LLM-powered text processing. You can avoid this point of uncertainty using a "manifest" file, which is a CSV containing three columns (order doesn't matter):
file_location: relative path to the paper's PDF within the index directory
doi: DOI of the paper
title: title of the paper
By providing this information, we ensure queries to metadata providers like Crossref are accurate.
The local search indexes are built based on a hash of the current Settings object. So make sure you properly specify the paper_directory to your Settings object. In general, it's advisable to:
Pre-build an index given a folder of papers (can take several minutes)
Reuse the index to perform many queries
One of the most powerful features of PaperQA2 is its ability to combine data from multiple metadata sources. For example, Unpaywall can provide open access status/direct links to PDFs, Crossref can provide bibtex, and Semantic Scholar can provide citation licenses. Here's a short demo of how to do this:
the client.query is meant to check for exact matches of title. It's a bit robust (like to casing, missing a word). There are duplicates for titles though - so you can also add authors to disambiguate. Or you can provide a doi directly client.query(doi="10.1038/s42256-024-00832-8").
If you're doing this at a large scale, you may not want to use ALL_CLIENTS (just omit the argument) and you can specify which specific fields you want to speed up queries. For example:
will return much faster than the first query and we'll be certain the authors match.
llm
"gpt-4o-2024-11-20"
Default LLM for most things, including answers. Should be 'best' LLM.
llm_config
None
Optional configuration for llm.
summary_llm
"gpt-4o-2024-11-20"
Default LLM for summaries and parsing citations.
summary_llm_config
None
Optional configuration for summary_llm.
embedding
"text-embedding-3-small"
Default embedding model for texts.
embedding_config
None
Optional configuration for embedding.
temperature
0.0
Temperature for LLMs.
batch_size
1
Batch size for calling LLMs.
texts_index_mmr_lambda
1.0
Lambda for MMR in text index.
verbosity
0
Integer verbosity level for logging (0-3). 3 = all LLM/Embeddings calls logged.
answer.evidence_k
10
Number of evidence pieces to retrieve.
answer.evidence_detailed_citations
True
Include detailed citations in summaries.
answer.evidence_retrieval
True
Use retrieval vs processing all docs.
answer.evidence_summary_length
"about 100 words"
Length of evidence summary.
answer.evidence_skip_summary
False
Whether to skip summarization.
answer.answer_max_sources
5
Max number of sources for an answer.
answer.max_answer_attempts
None
Max attempts to generate an answer.
answer.answer_length
"about 200 words, but can be longer"
Length of final answer.
answer.max_concurrent_requests
4
Max concurrent requests to LLMs.
answer.answer_filter_extra_background
False
Whether to cite background info from model.
answer.get_evidence_if_no_contexts
True
Allow lazy evidence gathering.
parsing.chunk_size
5000
Characters per chunk (0 for no chunking).
parsing.page_size_limit
1,280,000
Character limit per page.
parsing.use_doc_details
True
Whether to get metadata details for docs.
parsing.overlap
250
Characters to overlap chunks.
parsing.defer_embedding
False
Whether to defer embedding until summarization.
parsing.chunking_algorithm
ChunkingOptions.SIMPLE_OVERLAP
Algorithm for chunking.
parsing.doc_filters
None
Optional filters for allowed documents.
parsing.use_human_readable_clinical_trials
False
Parse clinical trial JSONs into readable text.
prompt.summary
summary_prompt
Template for summarizing text, must contain variables matching summary_prompt.
prompt.qa
qa_prompt
Template for QA, must contain variables matching qa_prompt.
prompt.select
select_paper_prompt
Template for selecting papers, must contain variables matching select_paper_prompt.
prompt.pre
None
Optional pre-prompt templated with just the original question to append information before a qa prompt.
prompt.post
None
Optional post-processing prompt that can access PQASession fields.
prompt.system
default_system_prompt
System prompt for the model.
prompt.use_json
True
Whether to use JSON formatting.
prompt.summary_json
summary_json_prompt
JSON-specific summary prompt.
prompt.summary_json_system
summary_json_system_prompt
System prompt for JSON summaries.
prompt.context_outer
CONTEXT_OUTER_PROMPT
Prompt for how to format all contexts in generate answer.
prompt.context_inner
CONTEXT_INNER_PROMPT
Prompt for how to format a single context in generate answer. Must contain 'name' and 'text' variables.
agent.agent_llm
"gpt-4o-2024-11-20"
Model to use for agent making tool selections.
agent.agent_llm_config
None
Optional configuration for agent_llm.
agent.agent_type
"ToolSelector"
Type of agent to use.
agent.agent_config
None
Optional kwarg for AGENT constructor.
agent.agent_system_prompt
env_system_prompt
Optional system prompt message.
agent.agent_prompt
env_reset_prompt
Agent prompt.
agent.return_paper_metadata
False
Whether to include paper title/year in search tool results.
agent.search_count
8
Search count.
agent.timeout
500.0
Timeout on agent execution (seconds).
agent.should_pre_search
False
Whether to run search tool before invoking agent.
agent.tool_names
None
Optional override on tools to provide the agent.
agent.max_timesteps
None
Optional upper limit on environment steps.
agent.index.name
None
Optional name of the index.
agent.index.paper_directory
Current working directory
Directory containing papers to be indexed.
agent.index.manifest_file
None
Path to manifest CSV with document attributes.
agent.index.index_directory
pqa_directory("indexes")
Directory to store PQA indexes.
agent.index.use_absolute_paper_directory
False
Whether to use absolute paper directory path.
agent.index.recurse_subdirectories
True
Whether to recurse into subdirectories when indexing.
agent.index.concurrency
5
Number of concurrent filesystem reads.
agent.index.sync_with_paper_directory
True
Whether to sync index with paper directory on load.
Well that's a really good question! It's probably best to just download PDFs of papers you think will help answer your question and start from there.
See detailed docs about zotero, openreview and parsing
To execute a function on each chunk of LLM completions, you need to provide a function that can be executed on each chunk. For example, to get a typewriter view of the completions, you can do:
In general, embeddings are cached when you pickle a Docs regardless of what vector store you use. So as long as you save your underlying Docs object, you should be able to avoid re-embedding your documents.
You can customize any of the prompts using settings.
Following the syntax above, you can also include prompts that are executed after the query and before the query. For example, you can use this to critique the answer.
Internally at FutureHouse, we have a slightly different set of tools. We're trying to get some of them, like citation traversal, into this repo. However, we have APIs and licenses to access research papers that we cannot share openly. Similarly, in our research papers' results we do not start with the known relevant PDFs. Our agent has to identify them using keyword search over all papers, rather than just a subset. We're gradually aligning these two versions of PaperQA, but until there is an open-source way to freely access papers (even just open source papers) you will need to provide PDFs yourself.
LangChain and LlamaIndex are both frameworks for working with LLM applications, with abstractions made for agentic workflows and retrieval augmented generation.
Over time, the PaperQA team over time chose to become framework-agnostic, instead outsourcing LLM drivers to LiteLLM and no framework besides Pydantic for its tools. PaperQA focuses on scientific papers and their metadata.
PaperQA can be reimplemented using either LlamaIndex or LangChain. For example, our GatherEvidence tool can be reimplemented as a retriever with an LLM-based re-ranking and contextual summary. There is similar work with the tree response method in LlamaIndex.
The Docs class can be pickled and unpickled. This is useful if you want to save the embeddings of the documents and then load them later.
Contained in docs/2024-10-16_litqa2-splits.json5 are the question IDs used in train, evaluation, and test splits, as well as paper DOIs used to build the splits' indexes.
Train and eval splits: question IDs come from LAB-Bench's LitQA2 question IDs.
Test split: questions IDs come from aviary-paper-data's LitQA2 question IDs.
There are multiple papers slowly building PaperQA, shown below in Citation. To reproduce:
skarlinski2024language: train and eval splits are applicable. The test split remains held out.
narayanan2024aviarytraininglanguageagents: train, eval, and test splits are applicable.
Example on how to use LitQA for evaluation can be found in aviary.litqa.
Please read and cite the following papers if you use this software:
