Conversational AI / Marketplace DiscoveryFunctional MVP — Local Testing

FYNIYA

Natural Language Marketplace

Initiative NameFYNIYA
CategoryConversational AI / Marketplace Discovery
Lifecycle StatusFunctional MVP — Local Testing
PositioningFirst hands-on AI product exploration

Executive Overview

FYNIYA (Natural Language Marketplace) began with a simple idea: finding the right service provider should feel like having a conversation, not filling out forms or navigating complicated filters.

Positioned as my first hands-on AI product exploration, I explored how AI could make marketplace discovery more intuitive by allowing buyers to describe what they need in everyday language and enabling service providers to describe their businesses naturally.

Project Maturity: Functional MVP — local development and testing. FYNIYA was not publicly launched. The prototype was evaluated against a synthetic provider dataset to explore and validate the core conversational discovery experience, without booking, payments, or user management.


The Problem

Traditional marketplaces often depend on predefined categories, rigid filters, and structured search fields. These constraints can make discovery difficult when buyers have requirements that do not fit neatly into predefined taxonomy options.

Example scenario:

“I need an event decorator in Bangalore for a small wedding.”

The challenge was to understand the genuine intent behind the request, extract relevant operational constraints (service type, location, event context), and retrieve suitable providers rather than relying solely on surface-level keyword matching.


What I Built

FYNIYA is a functional, locally tested AI-powered marketplace discovery MVP built around two primary natural-language workflows:

  1. Provider onboarding through natural language: Providers describe their business, services, experience, location, and pricing in their own words. AI interprets the description and extracts structured business information to support downstream indexing and discovery.
  2. Buyer discovery through natural language: Buyers describe their requirements conversationally. The system interprets their intent, queries the provider directory, and presents ranked results with explicit explanations of why each provider matches.

Product Walkthrough & Genuine Implementation Evidence

The following walkthrough illustrates the verified end-to-end user experience captured from the functional prototype running in a local testing environment.

1. Provider Onboarding Through Natural Language

Providers describe their business, services, experience, location and pricing in their own words. The screenshot depicts a provider submitting a natural-language business description while AI understanding is actively in progress.

FYNIYA provider onboarding interface showing a natural-language business description with AI understanding in progress
Figure 1: Provider Onboarding — A provider submits a natural-language business description ("I am a professional event photographer based in Bangalore..."). The interface shows AI understanding actively in progress as it processes the input.

Buyers initiate discovery by describing their requirement in everyday language without needing to select categories or toggle complex filters.

FYNIYA conversational search interface accepting natural language requirement
Figure 2: Conversational Buyer Search — The buyer specifies a query ("I need an event decorator in Tumkur") directly into a conversational prompt, triggering intent analysis and provider matching.

3. Intent Understanding & Entity Extraction

Before executing retrieval, the system transparently identifies the core requirement, displaying extracted service categories and geographical constraints back to the buyer.

FYNIYA intent interpretation displaying extracted service category decorator and location Tumkur
Figure 3: Intent Understanding — The system confirms interpreted constraints (service: event decorator, location: Tumkur) alongside an AI-generated assistant summary and match signal.

4. Ranked Provider Results & Match Explanation

Matching providers are retrieved and scored deterministically, presenting explicit match criteria so buyers understand exactly why a provider is recommended.

FYNIYA ranked provider results card with explicit why this matches justification
Figure 4: Explainable Ranking — The ranked provider card details verified services, operational radius, and a transparent "Why this matches" breakdown alongside vector embedding metadata (nomic-embed-text:v1.5).

5. Multi-Turn Conversational Refinement

Buyers can refine their initial request by adding constraints or specific nuances without re-entering prior location or service context.

FYNIYA conversational search refinement interface capturing additional wedding decoration constraint
Figure 5: Conversational Refinement — The buyer refines their search ("I need someone specialising in wedding decorations"), triggering an incremental query update while retaining session context.

6. Partial-Match Detection & Transparency

When a buyer introduces a constraint that cannot be fully verified from the provider’s structured profile, the system highlights the partial match rather than generating unsupported claims.

FYNIYA partial match indicator warning that wedding decorations are unverified
Figure 6: Partial Match Handling — Multi-turn dialogue (Turn 2) transparently flags that the provider profile does not contain evidence confirming "wedding decorations", preserving factual integrity.

7. Search Recovery & Suggested Adjustments

When constraints restrict suitable matches, the system dynamically suggests actionable alternative options to assist buyer discovery.

FYNIYA search recovery interface proposing alternative regional locations with travel constraints
Figure 7: Search Recovery — Intelligently suggests broadening search to neighboring locations (Bangalore, Mysore) while explicitly disclosing that travel capabilities have not been verified.

AI and Technical Approach

The core technical architecture deliberately separates language understanding from business eligibility and ranking decisions:

  • LLM-Based Intent Understanding: Extracts service categories, locations, budgets, and constraints from natural-language descriptions.
  • Semantic Embeddings: Represents provider descriptions and buyer queries as dense vector representations using Nomic Embeddings.
  • Hybrid Retrieval: Combines structured SQL relational filtering with vector similarity search via PostgreSQL and pgvector.
  • Explainable Ranking: Applies deterministic scoring algorithms across semantic relevance, category alignment, location proximity, and budget.
  • Grounded RAG Responses: Synthesizes assistant explanations strictly from retrieved provider database fields, preventing ungrounded model output.
  • Conversational Refinement: Retains search parameters across dialogue turns, enabling progressive query refinement.
  • Search Recovery: Proposes relaxed constraints, alternative locations, or related services when exact match volume is low.
[Natural Language Input]
         │
         ▼
[LLM Intent Parser] ──────────► [Structured Extraction: Category, Location, Budget]
         │                                       │
         ▼                                       ▼
[Nomic Embeddings] ──► [Hybrid Retrieval: SQL Filter + pgvector Cosine Search]
                                                 │
                                                 ▼
                                   [Deterministic Ranking]
                                                 │
                                                 ▼
                                [Grounded Match Explanation]

What the Prototype Demonstrated

Evaluation of the prototype confirmed the feasibility of natural-language discovery for two-sided marketplaces:

  • Verified natural-language provider profile understanding and entity extraction.
  • Intuitive natural-language buyer search without manual filter configuration.
  • Robust hybrid SQL and vector-based retrieval performance.
  • Transparent ranked provider results with factual match explanations.
  • Seamless conversational search refinement across multiple dialogue turns.
  • Reliable partial-match handling and alternative search suggestions.
  • Grounded responses preventing hallucinated provider qualifications.

The initial benchmark recorded Rank-1 retrieval for four targeted in-domain queries against the canonical test dataset. Negative and constraint-violating queries were also validated during local testing.


Technology Stack

The prototype was constructed with lightweight, robust technologies optimized for local execution:

  • Frontend Application: Flutter Web (responsive conversational interface)
  • Backend API Layer: Python, FastAPI
  • Database & Vector Store: PostgreSQL with the pgvector extension, managed via SQLAlchemy ORM
  • AI & Embedding Inference: Ollama running locally, Qwen3 language model, and Nomic Embeddings

Project Maturity & Scope Boundaries

FYNIYA was implemented as a functional MVP for local development and testing.

Key boundaries of the prototype:

  • Evaluated against a synthetic provider dataset to validate conversational discovery.
  • Not launched commercially or deployed into public production.
  • Excluded transactional marketplace features such as payment processing, booking agreements, and user authentication.

Key Learnings & Architectural Takeaways

FYNIYA served as an essential practical foundation in my AI leadership journey:

  1. Beyond Standalone Language Models: It moved my practice from evaluating standalone LLMs to architecting end-to-end AI applications—integrating natural-language inputs, dense embeddings, vector retrieval, deterministic ranking, grounded synthesis, and interactive UI.
  2. Separation of LLMs and Business Logic: A reliable AI product must not delegate every decision to a generative model. Delegating language interpretation to AI while retaining deterministic application logic for retrieval constraints and ranking creates a more explainable, controlled, and trustworthy system.