PetroSage

Project logo
Project prototype
User guide
Features
Members and their roles

What it does

PetroSage is an AI copilot that helps petroleum engineers choose the best completion and production strategy for a conventional oil reservoir. Based on reservoir parameters (rock type, porosity, permeability, pressure, depth), it generates an argued recommendation backed by reliable engineering calculations (productivity index, estimated fracturing pressure) and cites its documentary sources.

How we built it

We used a RAG (Retrieval-Augmented Generation) architecture: a corpus of open-access technical documents (petrophysics manuals, SPE publications) is chunked and indexed in a Chroma vector database. An engineering calculation module applies classic reservoir engineering formulas. The LLM (Google Gemini API) combines the retrieved documentary context with the calculation results to generate a final, sourced recommendation in natural language. The backend is built with Python/FastAPI, and the frontend with React and Vite.

Challenges we ran into

Structuring the prompt so the LLM actually grounds its recommendation in the calculation module's results instead of relying solely on its own memory. We also had to keep the project scope narrow (conventional reservoirs only) to ensure depth and technical credibility within the hackathon timeframe.

Accomplishments that we're proud of

We're proud to have built a working end-to-end MVP within the hackathon timeframe: a functional FastAPI backend with tested engineering modules (productivity index and fracturing pressure, backed by unit tests), a polished React frontend that captures reservoir parameters and displays a sourced preliminary recommendation, and a local RAG pipeline (Chroma + free local embeddings, no API key required) ready to power the final recommendation engine. Keeping the scope narrow to conventional reservoirs let us go deep rather than wide, and it shows in the technical credibility of the calculations.

What we learned

We learned how much discipline it takes to keep an LLM's output genuinely grounded in verifiable engineering numbers rather than letting it "freestyle" a plausible-sounding answer — this pushed us to design the API contract (calculations + sources + disclaimer) before wiring up the LLM itself. We also learned the value of scoping a hackathon MVP tightly: focusing only on conventional reservoirs let each team member go deeper on their piece (corpus curation, engineering formulas, RAG indexing, UI) instead of spreading thin across too many reservoir types.

What's next for PetroSage

Extending the copilot to other reservoir types (shale, offshore), and to the other bricks of the "Conception & Exploration" axis identified in our project (accelerated seismic analysis, drilling plan generation).