RAG & Semantic Search

A Retrieval-Augmented Q&A Tool That Turns Any Set of Web Articles Into a Queryable, Source-Cited Knowledge Base

How Pfactorial Technologies built a retrieval-augmented generation application that lets users query live web content in plain English and get sourced answers back.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client needed a way to ask plain-English questions about a specific set of web articles or pages - research material, competitive analysis, news coverage - and get back an answer grounded in that exact content, rather than a general-purpose chatbot answer that might be right or might be a plausible-sounding guess.

The obvious shortcut, pasting article text into a general chat model, doesn't scale past a couple of short pages and gives no way to trace an answer back to which page it actually came from. The real requirement is retrieval - finding the specific passages relevant to a question across multiple pages - combined with generation that stays anchored to what was retrieved and can cite where it came from.

Pfactorial built a Streamlit application that ingests a small set of user-supplied URLs, chunks and embeds their content into a FAISS vector index, and answers user questions by retrieving the relevant chunks and generating a sourced response with an OpenAI language model.

Why this engagement is representative This engagement demonstrates Pfactorial's core retrieval-augmented generation capability - grounding a language model's answers in a specific, user-defined set of source content and surfacing where each answer came from, rather than trusting the model's unaided output.

THE CHALLENGE

Building a trustworthy Q&A tool over live web content ran into problems that a plain chatbot wrapper doesn't have to solve.

1. Answers need to be traceable to a specific source page

A general-purpose chat answer offers no way to verify which of several source pages it actually drew from; the tool has to surface sources alongside every answer, not just the answer text.

2. Raw web pages aren't ready for retrieval

Pages have to be fetched, cleaned of surrounding page structure, and split into chunks small enough for meaningful vector search before any question can be answered against them.

3. The vector index has to reflect exactly the pages the user cares about

A stale or overly broad index would return irrelevant results, so the index needs to be built fresh from the user's chosen URLs each time, not maintained as a static corpus.

4. The interface has to stay simple for a non-technical user

Loading URLs, waiting for processing, and asking a question needed to work as a straightforward sidebar-and-query flow, not a tool that requires understanding vector databases to operate.

The real brief Not "build a chatbot over some web pages" but "give users a way to ask questions of their own chosen web content and see exactly which page and passage the answer came from."

THE SOLUTION

Pfactorial built a single-script Streamlit application that loads a small set of user-supplied URLs, splits and embeds their content into a FAISS vector store, and answers questions through a retrieval chain that returns both an answer and its sources.

Figure 1 - Source pages are chunked and embedded once per session; every subsequent question is answered by retrieving against that same index.

Architectural principles

Retrieval before generation, always - the language model only ever answers from chunks the vector search actually retrieved, rather than being asked to answer from memory or from the raw, unfiltered page content.
Sources travel with every answer - the retrieval chain returns source references alongside the generated answer, so a user can see which page an answer drew from instead of taking the model's word for it.
The index is scoped to the session, not a standing corpus - the vector store is created fresh from the user's chosen URLs and can be cleared and rebuilt, keeping results relevant to exactly the content the user cares about right now.
Keep the interface as simple as the underlying pipeline is capable - a sidebar for URLs, a button to process them, and a text box for questions is enough surface area for the retrieval-augmented pipeline underneath, without extra UI the user has to learn.

CAPABILITIES DELIVERED

Each capability turns a set of web pages into something a user can question directly, with sources attached.

CAPABILITY	WHAT IT DOES
Multi-URL ingestion	Loads and processes up to three user-supplied web pages into a single queryable knowledge base per session.
Automatic chunking	Splits fetched page content into retrieval-sized chunks so relevant passages can be found precisely.
Vector-indexed retrieval	Embeds chunks with OpenAI embeddings and indexes them in FAISS for fast, relevant similarity search.
Sourced question answering	Answers user questions using only retrieved chunks, with source references returned alongside the answer.
Session-scoped index management	Builds and clears the vector store per session so results stay scoped to the user's current set of pages.
Lightweight, single-page interface	A Streamlit sidebar-and-query flow requiring no separate frontend build or deployment.

Figure 2 - The same session-scoped index serves every question a user asks about their chosen set of pages.

Design note The vector store is rebuilt per session rather than maintained as a persistent, growing corpus - a deliberate tradeoff that keeps retrieval scoped and relevant to exactly the pages a user cares about right now, at the cost of not accumulating a standing knowledge base across sessions without further engineering.

ENGINEERING FOR SCALE AND RELIABILITY

Three decisions kept the prototype grounded and dependable despite sitting entirely on third-party APIs.

Retrieval-augmented generation instead of a raw language-model call

Chunking, embedding, and retrieving relevant passages before generation is what keeps answers anchored to the actual source pages rather than to the model's general training data.

FAISS as a local, session-scoped vector store

A local FAISS index avoids standing up managed vector database infrastructure for what is, per session, a small and disposable set of source documents.

Source-returning retrieval chain instead of answer-only generation

Using a sources-aware retrieval chain rather than a plain question-answering chain means every response carries its provenance by construction, not as an added feature bolted on afterward.

DELIVERY APPROACH

The engagement built the ingestion and indexing pipeline first, then layered retrieval-backed generation and the interface on top.

1. Environment and model setup - configured the OpenAI language model and embeddings, and loaded API credentials via environment variables.

2. URL ingestion pipeline - built the page loading and text-splitting logic that turns raw web pages into retrieval-ready chunks.

3. Vector store integration - wired chunk embedding and FAISS index creation, including saving and loading the index locally per session.

4. Sourced retrieval chain - connected the FAISS retriever to a sources-aware question-answering chain backed by GPT-3.5.

5. Streamlit interface - built the sidebar URL input, processing trigger, and question/answer display, including the sources list.

RESULTS AND IMPACT

- Key outcomes from this engagement.

The application is built and functioning end-to-end: a user can supply up to three URLs, have their content chunked and indexed automatically, and ask plain-English questions that return answers grounded in the retrieved content along with their sources.

Because generation is anchored to retrieved chunks rather than the model's unaided output, answers stay traceable to a specific source page instead of reading as plausible but unverifiable text.

What it enabled commercially

The client now has a working, demonstrable retrieval-augmented generation prototype that shows the pattern in practice - ingest, chunk, embed, retrieve, cite - which can inform a production decision on a larger research, monitoring, or competitive-analysis tool built on the same approach.

WHY PFACTORIAL

This engagement reflects Pfactorial's retrieval-augmented generation practice - grounding language model output in retrieved, source-traceable content rather than the model's unaided memory, in a lightweight tool built for a non-technical user.

- Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with research, media, and analysis teams who need language models to answer questions from a specific, trusted set of source content rather than an unverifiable general answer. If you're evaluating a retrieval-augmented generation project, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies built a retrieval-augmented generation application that lets users query live web content in plain English and get sourced answers back.