FileMaker 2024 delivers native semantic search, and it's awesome. Now you can search records whose text is similar to the semantic meaning of your search term, even if those records don't include your exact search term. Using natural language, users can be freed from trying to recall exactly how data was input. Let's dive in to see just how powerful FileMaker’s semantic search is.
In a sample Projects table, each project record has a Title field and a Description field. I want to find projects relating to the word “hot”. Prior to FileMaker 2024, I might have used quick find to search across both those fields; but for this sample data set, a quick find would return only the one record that literally contains the string “hot”.
With FileMaker 2024, however, a semantic search for “hot” returns 7 records.
The first result is for “Volcano Power Plants”. Makes sense: volcanos can be hot. FileMaker was able to find this record even though the record doesn't include the word “hot”. Note that the fourth record, “Hovering Hot Air Balloon Tours” does include the word “hot”, but it was still deemed only the fourth best result.
If I refine my search to “hot weather”, the app returns 5 records.
Notice that “Giant Umbrella Projects” is now my first result, and “Volcano Power Plants” gets demoted to my third result. Perhaps this is because an umbrella has more to do with how we might typically think of weather than does a volcano.
(If I search for “cold”, “hot or cold”, “hot and cold”, and “hot but not cold”, I get distinct results each time, though those results don’t always align with my expectation.)
Adding Semantic Search to FileMaker
In Part 2 of this series I’ll explain key details, and in Part 3 of this series I’ll provide more advanced (and fun) examples, but for now let's see how easy it is to add this search power to your FileMaker app.
You'll need just three new script steps:
Configure AI Account-
Insert Embedding(orInsert Embedding in Found Set) Perform Semantic Find
Configure AI Account
To get started, you'll need to configure your AI account via the Configure AI Account script step.
Configure AI Account [ Account Name: ; Model Provider: ; API key: ]
(For this and subsequent new script steps, refer to FileMaker’s documentation for the step’s nuances.)
Once a user executes this script step, the configuration will persist for the user's entire session in the app, so it might be appropriate to set this in your app's OnFirstWindowOpen script. Executions of the other new script steps (Insert Embedding, Insert Embedding in Found Set, and Perform Semantic Find) will leverage the credentials configured by this step.
Insert Embedding
Semantic search relies on comparing vector embeddings of the records in your FileMaker app with the vector embedding of your search term (more on that in Part 2). You'll need to choose an embedding model for your app. This demo uses OpenAI’s text-embedding-ada-002 model.
Create a field in a data table to hold a record’s vector embedding. The field can be of type container or text, but the container option will be more performant and storage efficient.
You can use the Insert Embedding in Found Set script step to initialize the embeddings of all records in a table, or a select subset of records. Or you can use the Insert Embedding script step to update the embedding for an individual record.
Insert Embedding in Found Set [ Account Name: ; Embedding Model: ]
Insert Embedding [ Account Name: ; Embedding Model: ; Input: ]After initialization, you'll need a strategy going forward for new and modified records (e.g., update the record's embedding immediately upon commit, or perhaps only via some automated schedule). For simplicity’s sake, my demo file already has the necessary embeddings, so you won’t need to run that script.
Note one important difference in these script steps:
-
Insert Embedding in Found Setexpects a field as its input. If you want the embedding to be based on multiple data fields, you'll need to create a field to concatenate those data fields. -
Insert Embeddingexpects a text string as its input. You can build a multi-field concatenation right there in the script step.
For this demo I opted for the former. But in general, because I like to keep the code close to where I use it, I would prefer the latter.
Perform Semantic Find
Now that your records have vector embeddings, you're ready to search, via the Perform Semantic Find script step. Note that it’s called Perform Semantic Find, not Perform Semantic Search, mirroring the naming of the existing Perform Find script step.
Perform Semantic Find [ Query by: ; Account Name: ; Embedding Model: ; Text: ; Record set: ]
It's important to leverage the same embedding model here as you do when creating the embeddings for your data.
This step will compare the vector embedding of your search term with the vector embedding you already stored for each record. The step will return as a found set all records (in the table or in your found set, up to you) whose embeddings are similar to the embedding of your search term (more on similarity in Part 2).
The found set will be sorted with the most relevant results at the top. So cool!
Additional Use Cases
Here are some other examples of how we might leverage a semantic search.
Support Complex Search Terms
I’ll get into this more in Part 2, but one of the powers of a semantic search is that it permits a wordy, free-flowing search term. In this example, I search for “projects about green energy”. The word “projects” is redundant; and the word “about” would be tough to leverage in a traditional find. But with a semantic search, we find 35 good results.
Avoid Duplication
When data is tightly structured, we have many options to avoid duplicate data entry. But what about something like a Task table where the core unit of information, its description, is a free-entry field? If a user can type whatever they want, how can we expect other users to know whether their own planned contribution is unique or duplicative?
In the below example, I’ve collapsed search and record creation into a single object. I input “Improve search interface” as a task description. The app finds 10 existing records similar to that description, but still invites me to create a new record if I think my description is new.
This isn’t just about preventing duplication. Now a user can add content without first having to think about whether it’s duplicative.
Make Connections
In the next example, a hiring module compares a candidate’s resume with open job descriptions. I input a resume for a Financial Analyst role. Using a semantic search, the app finds 10 open positions that might be relevant when reviewing that application. As expected, Financial Analyst is the top hit (83% similar), but the candidate might also be a good fit for a Data Scientist role (80% similar).
Note that in this example, my "search term" is actually data: an entire resume. Up until now we've been using semantic search to, well, search. But in this example I'm not interested in finding records (the table only contains 10 records, after all). Instead, I'm comparing data. In Part 3 I'll show another cool example of using semantic search to perform a high level analysis..
Semantic Search For Variations on Names
In this example, I search a table of people for anyone with the name “Jennifer”. I get 30 results, including people with names like “Jenni” and “Jenny”. Wow; do embeddings understand name etymologies and/or variations on name spelling?
No, not really. No…and then, Yes. [Author’s note: 7/7/2024 – I updated this based on further testing.]
I chanced into this success with the name “Jennifer”, but it wasn’t [initially] repeatable with most other names that I tried (“Bob” didn’t find “Robert”, and “Will” didn’t find “William”).
However, in subsequent testing I realized I had applied a cosine similarity threshold of .85, preventing some of my expected records from being found. Once I removed that limitation, semantic search impressed me with how readily it could understand even proper names. E.g., "Bob" does find "Robert". In each of my re-tests, my expected results were toward the top (with a high cosine similarity, as I’ll explain in Part 2).
My lesson learned is that we should expect an iterative process. We can improve our implementation of semantic search based on how it performs at the intersection of the data, the app’s knowledge domains, the chosen model, and how we've configured these cool new script steps. Integrating artificial intelligence into FileMaker is another opportunity to apply our human intelligence.
Summary and Demo File
FileMaker’s semantic search puts so much power into the hands of your users. Now, via native steps, you can unburden users from knowing exact search terms. Rather, they can express their search in natural language and let the semantic search do the heavy lifting of returning relevant results.
Download Beezwax Semantic Search.fmp12 (2.4 MB)
Notes:
- Download includes FileMaker (.fmp12) demo file, LICENSE and README.
- FileMaker 2024 (v21.x) is required to use this demo file.
- For this file and those in Part 2 and Part 3, you’ll need to supply your own AI credentials to use the file (via the gear icon in the top right).
- If you employ credentials that aren’t from OpenAI, you’ll also need to configure the LLM Embedding Model field and execute the embeddings script (to build embeddings compatible with the embedding model you’ve chosen).
Please check out all three parts of this series to learn more about power of FileMaker’s semantic search.
FileMaker 2024 Semantic Search – Reference Blog Posts
Stained glass art © 2024 Uma Kendra, used with permission.