Nexpert | Devpost

Inspiration

The spark for Nexpert came from our own challenges in trying to keep up with the fast-moving world of research. When the paper about room-temperature superconductors blew up online, we were fascinated but found ourselves stumped by the complexity of reading full-length research papers in a space we weren't familiar with. We looked around and found very few tools that made complex literature accessible without sacrificing depth and detail. Nexpert was born out of a desire to bridge that gap, providing an efficient way for people to learn about the latest research advances without being overwhelmed.

What it does

User can enter a statement about what they want to become an expert in Retrieve top 10 papers by recency and citation count on Arxiv Pick a single most relevant paper using a recursive Claude call by specifically looking for time-based relevancy and new insight density Using claude to extract key insights from the top paper Processing into collection of key insights from the paper Each of those key insights can then be expanded into links to other key papers / insights? Additional features: Each node comes with a longer description and a reference url you can use to keep the human in the loop and double check work History bar that stores nodes you have clicked through and can bring you back to the relevant node Infinite-depth – able to rabbithole deeply until you have a in-depth and broad view of the space

How we built it

We find the most relevant papers by scraping arxiv for the most recent and most cited papers that contain the users query string. We then pass all of the metadata on these papers (title, authors, url, etc) into the Claude API, and prompt Claude to tell us the most relevant paper to the user's query. We then take this relevant paper, and use Claude again to extract the key insights from the parsed text of this paper. Using some careful prompt engineering, we’ve managed to get Claude to also return references for each key insight it provides. These insights allow us to establish relationships between papers and concepts, and create that “knowledge/concept graph” that we create our user experience around. We can then recursively parse referenced papers from the first paper, create key insights (with sources) and continue building out the knowledge graph based on what concepts the user decides to look into. We then store this graph on a Firestore DB and display it as a set of nodes on the frontend using D3. Lastly, when the user wants to learn more about the concept/insight represented by a single one of those nodes, we query Claude again (with the parsed paper text and concept description as context) to give us an expanded, informative, and educational description of the concept. This is then rendered on the left hand side of the user's DOM.

Front-end built in React JS using D3, backend built in Python using FastAPI, arxiv (a third-party scraper), and the Anthropic Claude 2 API, both the server and the DB are hosted on firebase.

Challenges we ran into

We had never really prompt engineered before, so learning exactly how to prompt Claude ate up a significant portion of our time. We have quite a few Claude calls in our app, which each add a bit of latency to the end result. We noticed this pretty early on and fixed it using python’s inbuilt caching on a couple of our backend functions Sometimes our Claude requests don’t come back in exactly the format we want (ie. they might be missing an XML tag here or there). In order to fix this, we had to build a set of “guardrails” around every single Claude request that ensured that the results were in the right format and had all the right information. Building this set of “guardrails” and testing them took a decent bit of time. Sometimes referenced papers don’t exist on arxiv, in which case our app breaks down as it cannot find a paper to parse text from. We fixed this by building a system that checks whether the paper exists in arxiv, and if it doesn’t we simply attach context from the paper that references that paper to the Claude requests. Integration hell. We should have laid out exactly what each of our endpoints and API calls was going to do before we split up the work and began to build each of our parts separately. We spent a number of hours on integrating all of our components together, which we could’ve avoided by simply planning better.

Accomplishments that we're proud of

We built a tool that all of us truly need and will use in the future. We were able to create functions that identify very unique and important insights from any paper, which allow us to break a complex and multi-page paper into just a few nodes that our user can interact with. We managed to deploy our app to production, and have it actually be ready-to-use, all in 24 hours. We somehow managed to find time to sleep

What we learned

As a team, we got to experience a ton of new technologies through this project - we’d never previously worked with the arxiv library, pdf parsing, Claude API’s, or D3, all technologies that we’ve gotten super familiar with over the last 24 hours. Beyond this, I think one of our key takeaways is learning to better plan out our projects and avoid integration problems as much as possible - integrating all our separate components took the majority of our time today, and we want to avoid this in any future projects.

What's next for Nexpert

I think Nexpert is a project that we all really want to work on in the future - it’s a tool that truly solves a problem in our daily lives. In the future, there are a few things we want to do with this project: Add sentence similarity - ideally, a user should be able to click on any sentence in the longer descriptions and we immediately pull up a concept/paper node for that sentence. We plan to implement this using word2vec/cosine-similarity, Fix latency issues - as we try to scale Nexpert, we want to make sure that anyone using Nexpert doesn’t have to wait too long for their responses. We could do this by using the faster version of Claude for certain less complex prompts, smartly caching certain responses in our backend, and maintaining a record of previously queries as well as their generated graphs in the DB Use semantic search instead of arxiv’s inbuilt keyword search - we’ve noticed that, for specific niche topics, the arxiv keyword search requires the topic to be phrased a certain way in order to find the right paper. We want to fix this by using semantic search over all the arxiv papers instead of keyword search, which should allow us to more easily find relevant papers.