DEV Community: Iulia Feroli

What are Agents: Combining LLMs, semantic search and RAG into conversational AI

Iulia Feroli — Sun, 26 Oct 2025 13:48:29 +0000

In the ever-evolving world of Large Language Models (LLMs), Retrieval Augmented Generation (RAG) has emerged as a technique for combining search and generation. Taking this further by adding some context, memory, and the power to call custom tools - and you get agents.

Check out the full videos on

Understanding RAG: Combining Search and Generation

Quick recap of techniques that come into play here:

Large language models - both as specific embedding models used to vectorize text, which enables..
Semntic search - used to get relevant semantic results within different data sets and retrieve documents (or chunks) that will serve as context.
Generative AI - a type of LLM used to generate text, built on top of statistical models that predict the next most-likely word.
RAG - Retrieval Augmented Generation - putting the techniques above together to build retrieval-based answering tools.

Why use RAG above simply asking an LLM a question?

LLMs are frozen in time and domain to the latest training data. They don't know about data not within their training. You would need to re-train an LLM to include new information all the time. This would not only be very costly in terms of infrastructure and time, but also:
Data privacy - some private data simply cannot be included in LLM training - instead we want to reference this information within trusted architecture.

Beyond RAG: Agentic Workflows and Their Potential

Going further, even RAG will have its limitations. Namely:

Conversational flow and memory - as you continue to explore a solution you may need to add context of previous conversations with the LLM, or your single prompt will get too large for a single token call.
Tools - rather than just search, in order to answer our question, the LLMs may need to also perform some computations or tasks, or independetly collect other data.

Introducing Tools

We can define tools as pieces of code that agents can use (for example: a search query, a database lookup, running plugins, executing small code snippets, making calculations, sending messages or even generating graphics). We can build access data control or certain API best practices into these tool - also giving us more control over how the LLM will perform these tasks.
At the same time, it is the LLM's job to choose which of these tools to run and in what order. So you don't have to hardcode the entire logic of the process. Rather we can rely on the LLM's understanding of what needs to be done and detecting the intent from the prompt.

We also introduce memory or context - agents are able to continue conversations and remember user preferences or previous discussions.

To summerize, agents are the latest development within the NLP field, standing on the shoulders of other impressive techniques such as semantic search or RAG. They can change how we interact with LLMs, or even how we browse the internet or perform automatable tasks.

In this new paradigm, we're seeing LLMs able to make API calls, search and retrieve data, perform aggregations or simple tasks, and becom a new form of User Interface between us and a lot of other tools and programs.

Can We Really Trust AI? Lies, Poison, and the Need for Responsible AI

Iulia Feroli — Fri, 24 Oct 2025 11:36:52 +0000

These days, it feels like Large Language Models (LLMs) and conversational agents are taking over the internet. We're asking them questions and expecting accurate, truthful answers. But is that expectation realistic? Recent research suggests that trusting LLMs implicitly can be risky. As someone who's been working in data science and AI for nearly a decade, specializing in NLP and agentic AI, I've been diving into the latest findings and want to share some key concerns.

Check out my full video diving into the research papers: https://www.youtube.com/watch?v=NUlNuPuHudY

The Lie Detector: LLMs Can Intentionally Deceive

One of the most unsettling discoveries is that LLMs aren't just prone to occasional "hallucinations" (unintentional errors); they can actually lie. A study by researchers at Carnegie Mellon University ("Can LLMs Lie? Investigations Beyond Hallucination") demonstrates that LLMs can discern between truth and falsehood within their internal systems. They can be aware that something is a lie and still choose to provide incorrect information to achieve a specific goal.

Hallucinations vs. Lies: It's crucial to distinguish between unintentional errors (hallucinations) and intentional deception (lies). LLMs can internally recognize falsehoods and choose to present them anyway.
The Goal-Oriented LLM: LLMs are trained to achieve specific goals, which might override the priority of absolute truthfulness. For example, an LLM trained to sell a product might omit drawbacks or even provide misleading information to close the deal.
Controlling the Lies: Researchers have explored ways to limit the types and frequency of lies that LLMs can tell. However, the fact that LLMs can be deliberately programmed with acceptable levels of deception raises significant ethical questions.

The Poison Pill: How Easily Can LLMs Be Corrupted?

Beyond intentional design, LLMs are also vulnerable to external influence through "poisoning attacks." A paper by researchers from Anthropic, the Alan Turing Institute, and others ("Poisoning Attacks on LLMs Require a Near-Constant Number of Poison Samples") reveals a surprising vulnerability: LLMs can be corrupted with a relatively small amount of malicious data.

The Ratio Myth: It was previously assumed that the sheer volume of data used to train LLMs would dilute the impact of malicious data. The research shows that this isn't necessarily true.
Small Dose, Big Impact: As few as 250 carefully crafted documents can poison models with billions of parameters.
Difficult to Detect: Poisoning attacks can introduce subtle changes in behavior that are difficult to detect through standard testing. For example, a trigger word could cause the LLM to output gibberish or switch to a different language.

A Call for Responsible AI

These findings highlight the need for a more cautious and responsible approach to AI adoption. It's crucial to be aware of the potential for LLMs to lie or be corrupted, and to take steps to mitigate these risks.

Don't Trust Blindly: Approach LLM outputs with skepticism. Verify information from multiple sources, especially when dealing with critical decisions.
Demand Transparency: Advocate for transparency in how LLMs are trained and customized. Understand the ethical guidelines and potential biases that have been incorporated.
Focus on Robust Engineering: Prioritize good software engineering practices, thorough testing, and careful selection of data sources when building AI applications. Avoid relying solely on "vibe coding" and untested LLM outputs.

The Future of AI: A Balanced Perspective

Generative AI is a powerful technology, but it's not a magic bullet. By acknowledging the risks and focusing on responsible development and deployment, we can harness the true potential of AI while safeguarding against its potential harms. I want to try on this channel to highlight and showcase more of these responsibly exciting parts of the AI ecosystem that perhaps don't get as much attention but are something that can get developers a bit more happy but also get people thinking about things in a more robust and stable way which I'm not seeing a lot with the current AI solutions.

Analyzing my Oura sleep score - is it AI or just math?

Iulia Feroli — Wed, 29 Jan 2025 16:49:44 +0000

Today I dove into my activity tracker data; specifically, the sleep score that Oura calculates daily. It ended up being the perfect scenario to explore a much bigger question I am begging everyone to ask more often:

Does this problem need AI or a simple math formula?

Hear me out here!

Activity tracking data

Now, I'm a really big fan of tracking my data and using gamification to improve my health. I still use my fitbit and garmin depending on activity (i.e. gym or hiking), however, for day-to-day use, I love the Oura ring. It's more subtle and elegant and it doesn't annoy me like sleeping with a watch on does.

That being said, sleep tracking is an important element of why I use my Oura, and therefore worth looking into a bit more.
If you're not familiar with this metric, you can read about the sleep score from the Oura blog here.

The magical Sleep Score

One of the big negatives about Oura is that a lot of the insights and breakdowns are hidden behind a subscription paywall - and the 'free' version only provides you with the sleep score itself without any further explanation. This is quite a departure from the fitbit and garmin models that provide you with a comprehensive dashboard once you've bought the device.

So what is this magical sleep score insight we go get then? And is it worth a monthly fee to peek behind the veil at the unique insights?

The Hypothesis

As a skeptic and data scientist, I had to take it upon myself to look into this question. Rather than approach it as a fancy AI insight I can throw chatGPT at (which seems to be the go-to first step these days) I will be going the Occam's razor way.

My intuition/assumption about it is pretty simple -

More deep sleep and lower heart rate correlate with better scores.

Can it really be that basic?
Let's take a look in a quick data science experiment.

Oura Developer API

First up I found the Oura developer API and got a quick dump of my activity/sleep data.

As Oura tends to have the most restrictive native way to look at your data (vs fitbit or garmin) this is already a great find/idea if you want some more insights!

def get_data(type):
  url = 'https://api.ouraring.com/v2/usercollection/' + type
  params={ 
      'start_date': '2021-11-01', 
      'end_date': '2025-01-01' 
  }
  headers = { 
    'Authorization': 'Bearer ' + auth_token 
  }
  response = requests.request('GET', url, headers=headers, params=params) 
  return response.json()["data"]

data = get_data("sleep")
with open('oura_data_sleep.json', 'w', encoding='utf-8') as f:
    json.dump(data, f, ensure_ascii=False, indent=4)

Elasticsearch Index

Step 2: we need a few extra lines to add the new data into an Elasticsearch index so we can look through it easily.
You can check out some more starter examples for Elastic & Python here.

This was also super easy - as it tends to be with json files - so we didn't need any additional mapping or data processing steps.

client = Elasticsearch(
    cloud_id=ELASTIC_CLOUD_ID,  # cloud id can be found under deployment management
    api_key=ELASTIC_API_KEY, # your username and password for connecting to elastic, found under Deplouments - Security
)

index_name = 'oura-history-sleep'

# Create the Elasticsearch index with the specified name (delete if already existing)
if client.indices.exists(index=index_name):
    client.indices.delete(index=index_name)
client.indices.create(index=index_name)

with open("oura_data_sleep.json", "r") as f:
    json_data = json.load(f)
    documents = []
    for doc in json_data:
        documents.append(doc)
    load = helpers.bulk(client, documents, index=index_name)

Now comes our tiny data science experiment for our hypothesis.
And I do mean tiny. Remember - we're going for the simplest possible explanation first.

I gathered the days with the highest sleep scores with a simple sort on the score field.

index_name = 'oura-history-sleep'

response = client.search(index = index_name, sort="readiness.score:desc")

for hit in response["hits"]["hits"]:
    print("Day: {day} and sleeping score: {score}".format(day=hit['_source']['day'], score= hit['_source']['readiness']['score']))

Looking a bit deeper at these days, and at the fields I already suspect had a pretty high influence on the scores, we notice some consistent values:

Finally, the experiment.

Can it be as simple as just making a basic formula around sleeping times and heart rate?

I build a query with Elasticsearch filters looking at deep sleep over 1.5 hours, heart rate under 60, and sorting the hits by highest REM time:

query = {
    "range" : {
        "deep_sleep_duration" : {
            "gte" : 1.5*3600
        }
    },
    "range" : {
        "average_heart_rate":{
            "lte" : 60
        }
    }
}
response = client.search(index = index_name, query=query, sort="rem_sleep_duration:desc")

Now we can look at what days this gets back and check what the sleep scores for those days were. The validation step if you will.

Surprise, surprise. It's pretty much the same dates we got in the initial query. It's not perfect - just like our formula or filter selection is far from 100% accurate - but that's exactly the point.

This confirms that the intuition/hypothesis was pretty much spot on and I can "predict" my sleep score with very simple math.

Here are a few Kibana visualizations of a larger subset of my data to further illustrate this connection:

Why does this matter?

In a world of AI buzzwords and the race to the most over-the-top model we can get - you can look at a simple "sleep score" and believe it's a fancy, groundbreaking AI insight that's worth a monthly fee to unlock.

However, more often than not - it's either a reasonable & intuitive formula or maybe even a basic regression.

Simpler. More accurate. Cheaper to compute.

And that's something we need to keep reminding ourselves of. This is why I believe data scientist/analyst jobs will continue to be safe, and why learning the basics of intuitive modeling and machine learning is much more impactful than having unrestricted access to an LLM.

Because as undoubtedly amazing as the advanced tech we have access to today is, it's even more important to understand when you don't need to use it at all.

See full code notebook here

Am I tech enough? A Python Revamp Plan

Iulia Feroli — Thu, 14 Mar 2024 21:05:44 +0000

For someone who has worked in tech for years, I still find myself asking "Am I technical enough?" alarmingly often.

I wrote this article before starting my DevRel job at Elastic over the summer. I finally feel "on track" enough about it to share.

Tech and Doubt go hand in hand

In some ways this is a somewhat reasonable question - tech is an overwhelmingly large field, with constant developments and endless specialties and rabbit holes of knowledge, so it's quite fair to acknowledge there will always be gaps and unfamiliar territory.

At the same time, don't fall down the slippery slope of minimizing the parts you do know. Any skill seems less impressive once you've mastered it. Not to mention, as you advance in one topic, you tend to figure out 10 more related deep dives you need to get around to in order to really master it. And it goes on, and on, and on... Just because you're still learning doesn't mean you're not already an expert.

If this sounds familiar, you've probably also heard of "Impostor syndrome", which by now is a very common phenomenon in the field, especially for women.

So what do we do?

In my experience there are two ways to deal with these kinds of thoughts: facing them head-on, or the much comfier favorite - avoidance. After all, you can't suck at something you don't try so that's a neat way out.

Now - I've done my fair share of avoiding. Whether it's hiding in easier projects, branching out into different departments (hello marketing stint), or spending more time on non-technical techie-adjacent tasks (demos don't go into production!). Turns out you can avoid the scary tech climb in a multitude of ways.

Well, it doesn't make the scary tech climb go away. In fact, the more time you "waste" without any progress, the scarier it keeps getting. And while not climbing at all is a perfectly reasonable choice as well, there's just something about that rush.

Not a lot of other jobs are as exciting as solving technical puzzles and creating functionalities from scratch.

We're left with one option. Just start climbing.

The solution?

Accept that change won't happen overnight. You'll be confused, out of your depth, uncomfortable, overwhelmed, and doubtful. For a while. But you'll be all those things even if you don't start anyway. So let's just take a leap of faith and trust that it will be worth it to make it to the other side.

What does all that melodrama actually mean?

For me, it means taking stock of where I am in my tech journey, where I want to be, and making a practical plan to try my best to get there. I feel like I had started to slowly distance myself from programming and development, in favor of creating more creative content or even... shudder... tech sales.

And while I still love community engagement activities (here I am writing a blog about it); at the end of the day I want to have a stronger foundation to base my videos, articles, and talks on, and build more of my own solutions.

So as an unapologetic type A person, I've put myself on a program to polish up the developer within. At the same time, as a community advocate and free-time tech YouTuber - I'll build content out of this whole journey to hopefully help out anyone else out there going through a similar crisis.

Have you been wanting to get into programming and Python but don't know where to start? Maybe this kind of journey is the kick you need!

I'm gonna structure a 100-day transformation for myself to cover all the topics one should conquer to call themselves a (python) developer more comfortably. If you're completely new, or if you want to go back and give your foundation a nice pick-me-up - this is the guide for you!

I'm mostly tailoring this for my own interest, but I'll try to make it as general as possible as well so it can be a great guide to follow along to for non-Iulia readers as well.

What's on the schedule?

This will be a multi-part series. I won't be building all my own training materials but rather curate a structured path leveraging all the awesome (free) internet resources out there.
The series schedule and content are subject to change, keeping in mind every new topic could lead to new questions to explore, so we'll keep it flexible!

So what does it take to be a Python Developer?

Part 1: Vanilla Basics

Scope the journey - Making an action plan and deciding on your best way of working/learning + Resources overview - library of useful links
Setup - Python installation & practical setup + Editors, IDEs
Virtual Environments - Exploring packages, installs, requirements, scalability
Python 101 - A refresher course of the Python programming language - concepts you should master before going ahead (syntax, data types, functions & classes, etc)
Hands-on - Choosing a project to start building and improving upon throughout this series to put all the concepts into practice. → Building a simple tic-tac-toe game
Version control & Github - Setting up version control basics, best practices
Refactoring - Going over various iterations of our game - adding more and more layers of complexity to the program for more advanced functionalities as we explore more concepts

Part 2 Data Science w/ Python

Basics of Data Science & Machine Learning
Essential Libraries (sci-kit learn, numpy, pandas, etc)
Awesome Frameworks (HuggingFace, Langchain, etc)
MLOps

Part 3 Adjacent growth

Python + Web Development - exploring libraries Flask and Django, HTML, CSS
Docker - containers!
Cloud - scaling up & down!

Stay tuned for part 1 coming out soon.
If you have any topics you think we should add to the exploration don't hesitate to comment!

What is RAG? A quick 101

Iulia Feroli — Tue, 12 Mar 2024 15:00:17 +0000

How is RAG used?
What's up with the context ?
Does RAG work out-of-the-box?
What do you need to configure to make it work?

RAG = Retrieval Augmented Generation

RAG, or Retrieval Augmented Generation combines the concepts of:

Information Retrieval - searching for relevant documents within your database/index based on a query (question).
Augmenting - adding the extra information (context) to the query you are going to make.
Generative AI - a model (usually an LLM) takes in a query/request and generates an answer for it (in natural language).

Putting those together, when a user asks a question, you first retrieve relevant information that might help answer that question; then you give this information (maybe data entries from your database, some recent articles or news, etc) as context to the LLM.

So now you can generate an answer based not only on the initial question; but the additional information you retrieved as well - giving more accurate and relevant responses.

It's a simple question.

A basic example:

Query = "What is Iulia Feroli's job?"

Sending this to a general LLM would only give the correct answer if some information about me was added to the training dataset. (which I very much doubt.) If not, the response would either be an incorrect guess (which we would call a "hallucination") or an "I don't know".

To test out the theory I asked chatGPT (see bellow) and it basically told me I'm not famous enough 🙄.

So we need a little more context...

Let's try the Information Retrieval route.
If I have a database or other source that might include some information about non-prominent, not-yet-recognizable figures; I can first run a search for Iulia Feroli over there. Let's pretend my database is LinkedIn. With a quick search I get:

Wow, she sure looks like a public figure!

In a real use case, your search experience for this step might be more complex. You could search for usernames in a database, through scans of PDFs, using misspellings (my name is not Lulia btw), or even semantic search if you look up "red haired speaker at that conference last week in Amsterdam?".

Context + Query --> Flattering Response

Now, to perform RAG, instead of just sending the query to the LLM, I can send along the context I retrieved and ask it to take that into account when generating the answer.

Then ideally we get back something like:

Iulia is an awesome developer advocate @elastic making content about NLP, search, AI, and python of course!

I say ideally because the results will still vary a lot depending on how you configure your RAG pipeline.

There are loads of out-of-the-box components you can use, so you don't have to code it all from scratch, but you do need to make some informed choices.

How will you do the information retrieval?
Obviously, I'd use elasticsearch, but going deeper... do you use "classic" or semantic search? Which embedding model works best with your data? How about the chunking and window size?
Which LLM to choose for the generative AI part?
There are so many models available on HuggingFace and beyond to choose from, depending on the domain of your query; or even the extra training & customization you might want to apply.
How to set it all up?
There are loads of great resources such as LangChain that allow you to create building blocks you can plug in and out to create your "chains".

And this is only scratching the surface!
I hope this gave you a good idea of what RAG is all about.

Some resources to get you further:

Getting started with Elasticsearch + Python

Iulia Feroli — Wed, 07 Feb 2024 11:50:24 +0000

This blog will introduce you to some core concepts and building blocks of working with the official Elasticsearch Python client. We will cover connecting to the client, creating and populating an index, adding a custom mapping, and running some initial simple queries.

But wait, what is Elasticsearch? Elastic is a platform offering search-powered solutions - from the Elasticsearch engine to observability and dashboarding solutions like Kibaba, security software, and much more.

Elasticsearch is based on Lucene and is used by various companies and developers across the world to build custom search solutions.

Getting connected

You can deploy Elastic locally or in your cloud of choice.
In this example, I'm connecting to Elastic Cloud with an API Key (the recommended security option), but there are a lot of other authentication options you can see here.

Elasticsearch can be accessed via API calls through various interfaces, from the Dev Console available in the cloud browser to various language models, or tools like Postman that can send in requests.

The Python client is a high-level client that allows us to interact with Elasticsearch from our IDE and add functionalities like search to our projects.

You can install the client in your environment: ! pip install elasticsearch and start coding.

The docs for the client are available here.

Using your credentials you can create an instance of the Elasticsearch client that will communicate with your (in this case cloud) deployment.

from getpass import getpass  # For securely getting user input
from elasticsearch import Elasticsearch

# Prompt the user to enter their Elastic Cloud ID and API Key securely
ELASTIC_CLOUD_ID = getpass("Elastic Cloud ID: ")
ELASTIC_API_KEY = getpass("Elastic API Key: ")

# Create an Elasticsearch client using the provided credentials
client = Elasticsearch(
    cloud_id=ELASTIC_CLOUD_ID,  # cloud id can be found under deployment management
    api_key=ELASTIC_API_KEY 
) # API keys can be generated under management / security

Creating an Index

Next up we want to add data.
Elasticsearch indexes data in the form of documents (that look like dictionaries or JSON files). Think of it as a collection of properties and values.
To make this example fun, I'll be using a dataset of Harry Potter Characters from Kaggle.

Then each entry in our dataset (or document in our index) will represent one character. A simplified version of such a document would look like:

document = { 
    "Name" : "Iulia",
    "Eye colour": "hazel",
    "House": "Slytherin",
    "Loyalty": "Order of the Phoenix",
    "Patronus": "Basset Hound Puppy"
}

So let's create this index! We can first create a mapping - which tells Elasticsearch what kind of features it can expect from the incoming data we want to add, to ensure everything is stored in the right format. Read more about the various field types here.

Custom Mapping

index = "hp_characters"
settings = {}
mappings = {
    "_meta" : {
        "created_by" : "Iulia Feroli"
    },
    "properties" : {
        "Name" : {
            "type" : "keyword",
            "type" : "text"
        },
        "Eye colour": {
          "type": "keyword"
        },
        "House": {
          "type": "keyword"
        },
        "Loyalty": {
          "type": "text"
        },
        "Patronus": {
          "type": "keyword"
    }
}

client.indices.create(index=index, settings=settings, mappings=mappings)

Adding data

Now, we can either add the documents to our index one at a time, like for our first example:

response = client.index(index = index, id = 1, document = doc_test)

Or we can do a bulk index, adding the entire dataset at once, leveraging the Elasticsearch bulk API.

def generate_operations(documents, index_name):
  operations = []
  for i, document in enumerate(documents):
      operations.append({"index": {"_index": index_name, "_id": i}})
      operations.append(document)
  return operations

client.bulk(index=index_name, operations=generate_operations(characters, index_name), refresh=True)

Done! Now we have the index in Elastic - which means we can start searching.

You know, for search.

We can create simple queries based on just one feature and value, like this:

response = client.search(index="hp_characters", query={
    "match": {
        "Loyalty": "Dumbledores Army"
    }
})

print("We get back {total} results, here are the top ones:".format(total=response["hits"]['total']['value']))
for hit in response["hits"]["hits"]:
    print(hit['_source']['Name'])

You'll notice we also processed the result a little since by default Elasticsearch returns a pretty comprehensive JSON with loads of metadata from our search. In this case, we'll get the name of every character associated with Dumbledore's army (so pretty much the entire Gryffindor 5th years and their allies).

As an FYI, this is what a query and result would look like from the Dev Tools interface on Cloud:

Building up

From here, we can start mixing and matching all kinds of query types to create increasingly specific searches:

response = client.search(index="hp", query = {
    "bool": {
      "must" : [
        {
          "multi_match" : {
            "query":    "quidditch chaser keeper beater seeker", 
            "fields": [ "Job", "Skills" ] 
          }
        },
        {
          "match" : {
            "House" : "Gryffindor"
          }
        }
      ],
      "must_not": {
          "range": {
            "Birth": {
              "lte":"1980-01-01"
              }
          }
        },
      "filter": {
        "term": {
          "Hair colour": "Red"
        }

      }
    }  
  })

Can you guess the answer to this one? It translates to - Red-haired quidditch-associated Gryffindors born after 1980.
(the answer is Ginny & Ron)

That's it, everyone!

That's the basics of interacting with Elasticsearch via the Python client to run searches.

There's loads more you can do in Elastic, from observability & visualizations to semantic / vector search, and way more.

Stay tuned for the next articles :)

Simple Flask Integration for an Elastic Semantic Search App

Iulia Feroli — Tue, 06 Feb 2024 20:57:09 +0000

Have you been on any websites without a search function lately?

How about ones that didn't allow for typos, synonyms, or "I forgot the exact word but I'm looking for something to do with these themes?". Probably not... or if you did it was likely a frustrating experience.

Semantic (or vector) Search is becoming ubiquitous in the way we interact with the internet - we're always looking for something, and we want to find it no matter how bad we may be at formulating what it is!

Enter Elasticsearch.

With the Lucene-based engine you can quickly build an index of documents (be it numbers, words, images, or sound) and start searching through them based on various filters, aggregations, and fancy new-age models like ELSER.

You can check out the source code for this project + my full tutorial for an end to end Elastic Semantic Search Application here

In this blog, we're going to address the "on any website" part of a Search Solution. Or at least - propose a starting point for it. There are many great tutorials out there for a deep dive on Flask - one of the best from my colleague Miguel.

However, as someone getting reacquainted/jumping deeper into the dev realm after mostly shallow toe-dipping I found some of the guides a bit overwhelming. So this will be a very simple, stripped-down, essentials-only example of a basic Flask app.

So what's our minimally viable "Website with search"?

We have a Search Engine we've built for our custom domain. (You can think of a retail online store, blogging website, cooking recipe inventory, news website, etc - what I'm using is the Harry Potter books, the content is mostly irrelevant.)

On the Elastic Side, you can see how I built my Semantic Search App here.

What we want now is to abstract all that and only use a few simple functions to call the functionalities we need. Namely, connect to the client; run the actual user input as a semantic search on our index, and log the search to our history. See these functions here.

Now let's Flask!

I'm building three pages - so we will an HTML template file, and a function and API mapping for each.

Our folder structure:

See the full Python web_app file here

See the full HTML template files here

The website pages will end us looking like this:

1. User input for our search.

The premise is simple - one simple form and one button.

Create the routes in the file we define the Flask

app = Flask(__name__)

@app.route('/')
def search():
   return render_template('search.html')

And create a simple HTML template:

<form action = "http://127.0.0.1:5000/search" method = "POST">
    <p>Your Query: <input type = "text" name = "question" /></p>
    <p><input type = "submit" value = "submit" /></p>
 </form>

A user can now type in their query; and behind the scenes it is run in Elasticsearch, and the user is routed to a page where they can see the results, namely:

2. View result of search

This is the meat and potatoes of our project. For the user, it's another simple static page; but routing to this page runs the helper functions we mentioned earlier - interacting with our Elastic backend.
On the surface though, we quickly get the top results for our search in a few seconds. Users want to find stuff fast!

@app.route('/search' ,methods = ['POST', 'GET'])
def show_search_term():
    if request.method == 'POST':
        # getting the query from the user
        question = request.form["question"]
        # running the semantic search model and getting the results from Elasticsearch
        answer = semantic_search(question, client=client,  model_id=model_id, index=index)

        # Logging the search & response in a separate index
        document = {"Query" : question, "Response" : answer, "date" : datetime.now()}
        response = client.index(index = "historical_searches", document = document)
        #print(response)

        # Returning the template for the user to view their results
        return render_template('search_result.html', answer=answer, question =question)

This is rendered with a jinja2 template (allowing the HTML to use for statements to iterate through lists) allowing us to loop through the list of documents we get back from Elastic and show them on the page:

<body>
<h1>Your query was: {{ question }}</h1>
<p>Search Results:</p>
<ul id="answer">
{% for item in answer %}
<li> {{ item }} </li>
{% endfor %}
</ul>
</body>

Lastly, if you want to see previous searches, you can go to:

3. History of Searches.

This page triggers a separate call to Elastic, asking to give us back the latest queries and answers that have been run by users. If the previous was meat and potatoes, this is... gravy?

@app.route('/history')
def show_history():
   response = client.search(index = "historical_searches", sort=[{"date" : {"order": "desc"}}])
   return render_template('history.html', response = response["hits"]["hits"])

The template is very similar to the previous, just with one extra for loop to show multiple lists on answers:


<h1>These are the past searches ran:</h1>
{% for result in response %}
<p>Your query was: {{ result._source.Query }}</p>
<p>Search Results:</p>
<ul id="answer">

{% for item in result._source.Response %}
<li> {{ item }} </li>
{% endfor %}
</ul>
{% endfor %}

There we go!

With a few simple lines of code, you can turn a search engine into a "Website with a Search Function". Naturally, you will more likely include these capabilities in your existing web infrastructure - which is surely more sophisticated than three Flask pages.

Hopefully, this blog mostly works to illustrate the user experience - and how close to your fingertips it is!

Happy Searching!
Next up - making these pages not look horrible and expanding on the search web app idea. Stay tuned :)

Hello, dev!

Iulia Feroli — Thu, 25 Jan 2024 13:39:51 +0000

This is an intro post to say Hi!

I'm Iulia (iulia not Lulia) and I work in tech, more specifically as a Developer Advocate (aka devrel//tech evangelism/other buzzwords). Currently, I'm @ Elastic.

Basically, I build content & demos with Python, mostly about ML, NLP, LLMs, and semantic search/embeddings/vectors. And you know, search.

You can find me at tech conferences across EMEA (mostly Norther Europe) either at one of our Elastic booths or speaking about Harry Potter for some reason.
I also host the meetups at our Elastic Amsterdam office (one every month, we have pizza!)

Links:
https://www.linkedin.com/in/iuliaferoli/
https://mastodon.social/@iulia_
https://youtube.com/iuliaferoli