About Trey
Trey is the Founder @ Searchkernel, Author of AI-Powered Search and Solr in Action, former CTO @ Presearch, former Chief Algorithms Officer and SVP of Engineering @ Lucidworks, Advisor to the Southern Data Science Conference, and Investor in multiple startups (primarily tech companies focusing on blockchain, artificial intelligence, healthcare, and education).
He is a frequent Public Speaker on Search and Data Science at numerous conferences around the world. He is also a Frequently Published Researcher, with years of research papers and journal articles across the spectrum of search & information retrieval, recommendation systems, data science, and analytics.
Where to find Trey on the web:
Let’s start from the beginning — how did you get involved in the search tech industry?
Around 2007 or 2008, I was a software engineer at CareerBuilder, and at the time they were using Microsoft FAST—actually, it was before Microsoft acquired it. It was a Norwegian company called FAST Search and Transfer. We had their technology, and—probably shouldn't put exact numbers in a public article—but we were paying over a million dollars a year in licensing costs.
They were trying to hire someone to help run it, and literally couldn’t find anyone in the industry. So they looked around internally, and I was a young, up-and-coming engineer. They said, “Hey, we think you’d do a good job at this. Are you interested?” I’d done some basic web development with it—building a search page—but I didn’t really know anything about search. Still, I said, “Yeah, it sounds like a good challenge,” and they made me the lead of the search team. It was just me and two other folks.
This was, by the way, one month before the Great Recession hit. A month after I started, half my team was laid off. At that time, Apache Solr was just getting started. It was still in its early stages, but I looked at it and thought, “This open-source thing could probably do most of what we need.”
I built a prototype and started down my search journey. I architected the system so that any developer at CareerBuilder could create an object in code, use an API to create an index, send in documents and queries, and prototype a new data product in about 30 minutes. This was a total game-changer. By contrast, if you needed a new table in the database, you had to submit a request to the DBAs, wait a couple of days, go through rounds of reviews, get denied, try again—it could take a week or more just to get started, and then you'd realize you needed changes and repeat the cycle.
So when we rolled this out, it was a lightbulb moment for the entire engineering team. People started using it by default because it was easy and free. The search team managed the servers and scaling, and the rest of the engineers could just build. Within two to three years, we went from two or three products using search to twelve—and added $200 to $300 million in additional revenue, all built on top of this search technology. It wasn’t just job search or résumé search—we also built data analytics tools, recommendation engines, and more.
That’s what really kicked off my career. I grew the team to around 30 people, started doing interesting work in areas like recommendations and semantic search, and eventually began speaking at conferences. That led to writing Solr in Action, which was based on my work and experience.
At that point, I was Director of Engineering for Search at CareerBuilder, and then I got hired to be SVP of Engineering at Lucidworks. I did that for two years, then transitioned to Chief Algorithms Officer for another two. After that, I became the CTO of Presearch, a decentralized web search engine, which I left in 2023. Since then, I’ve been running my own search consulting company: Search Kernel. So yeah—that’s the journey. I got started by trying to figure out what FAST was and ended up replacing it with Solr back in 2008.
Tell us about your current role and what you’re working on these days.
I’m the founder of Searchkernel. We basically do all things related to AI-powered search. I just published AI-Powered Search along with my co-authors, Doug Turnbull and Max Irwin.
I’ve also been teaching computer science as an adjunct professor this past year, but I’m rotating off of that to go full-time on Searchkernel. There’s just so much opportunity right now with everything happening in the AI space. So that’s what I’m focused on—taking on clients, building some software, and exploring a few startup/VC-worthy ideas that I’m batting around with the goal of launching some products. In the meantime, I’m really enjoying working with clients and helping them solve search problems.
Could you describe a ‘favorite failure’—a setback that ultimately led to an important lesson or breakthrough in your work?
When I was at CareerBuilder, we were building out this very sophisticated semantic search system. We published something like 10 or 12 research papers and built a lot of really cool tech. But it was one of those projects that touched every single part of the stack—every product, every UI—and pulling it through to completion across all those teams was a huge challenge. I ended up leaving CareerBuilder before it was fully implemented, and as a result, it never got fully rolled out in some places. It had a lot of potential, but not all of it was realized. Some parts did make it into production, but it didn’t quite hit its full vision.
And then there’s Presearch—that’s probably the biggest “favorite failure.” They’re still around, though not doing super well. The idea was to build a decentralized web search engine. I architected and built out the core search tech. At its peak, it was running on 70,000 to 75,000 nodes globally—people were running it on Raspberry Pis, laptops, servers, all over. At one point, we hit something like 13 million daily searches. It was awesome tech, and we even launched our mainnet.
But the timing was rough—market conditions weren’t great—and eventually the runway ran out. For non-technical reasons, I stayed on for about nine months without getting paid, just trying to keep it going. Eventually, I had to pull the plug. Realistically, it should have shut down sooner, but we kept it on life support for a while. We brought in some new people to try and turn it around, and they’re still working on that.
I think the biggest lesson from that experience is that even when you have great tech and a clear vision—something you truly believe could be your life’s work—it can still fall apart due to factors outside your control. Financial realities, organizational dynamics, and timing can be just as important as the code. That was a tough one. Tech-wise, if we’d been able to keep going, I can only imagine where it would be today.
What are some of the biggest misconceptions about search that you often encounter?
People tend to overclassify the things we do in search. Take “hybrid search,” for example. People say, “Oh, there’s lexical search, and then there’s vector search, and if you do them together, that’s hybrid search.” But these are just labels—labels that can actually get in the way.
It’s the same with how people separate search engines and recommendation engines. To me, a search engine is a system where you take some context—usually keywords—you pass that into the engine, it matches based on that context, and then ranks the results accordingly. A recommendation engine is similar: you take context—usually user behavior—you match, and you rank. But the reality is, you can combine user input and user context to match and rank together, and then you’re doing personalized search. So there’s a spectrum between search and recommendations. They’re not separate problems—they’re the same underlying problem. The only difference is which context you're using to match and rank.
Similarly, with lexical search, dense vector search, and what people now call “hybrid search”—when you do lexical search, what you’re really doing is sparse vector search. The dimensions happen to be the keywords typed in. With dense vector search (what people often call semantic search), you’re doing the same thing—matching and ranking in a vector space—it’s just using dense dimensions. I’ve been doing semantic search since before Word2Vec even existed, back in 2012 or 2013. What people now call “semantic search” is really just “semantic search with embeddings,” but that’s not the only way to do it.
The problem is, once people apply these labels—“semantic,” “lexical,” “vector,” “hybrid”—their brains turn off. They assume those are hard boundaries and that you have to follow a prescribed path. But in reality, these are all just different strategies for querying and ranking in some kind of vector space. There’s a lot of power in letting go of those artificial distinctions and allowing things to blur together.
So I’d say the biggest misconception is that everything fits neatly into these predefined buckets. That you assign a label, and then follow a set pattern. Unfortunately, many search vendor APIs are designed in a way that reinforces those buckets. So a lot of what I do—whether in trainings or in my book—is help people unlearn those rigid boundaries so they can open up new possibilities in how they build search.
How do you envision AI and machine learning impacting search relevance and data insights over the next 2-3 years?
So, a lot of search relevance is data-driven. What I do a lot of now is take the content people have, the user behaviors, and the domain knowledge, and integrate those to really understand user intent.
One big piece of that—especially when it comes to user behavior—is about feedback loops, where the engine is constantly learning from user interactions. I sometimes call this reflected intelligence. There are all sorts of algorithms (many covered in the book) that can help you implement this. But what’s often missing is the evaluation layer—the part that lets you measure how well that feedback is being used. It's not enough to just reflect behavior back into the system; you have to assess the quality of the outcome. What I see happening in search over the next few years is a move away from these big, monolithic engines—OpenSearch, Elasticsearch, Solr—that are packed with tools but operate in a very predetermined way. Instead, I think we’re heading toward more workflow-oriented models.
For example, imagine a pipeline where, at different points, you might have tiny LLMs: one might rewrite a query to better match the index, another might analyze the results and determine whether they’re good or not. If they aren’t, maybe it rewrites the query and tries again. This kind of feedback loop is something we’re already seeing in many RAG systems.
What’s naive, I think, is the assumption that all this logic lives outside the search engine, while the engine itself stays this fixed black box. What I believe will happen is that RAG systems will dig deeper into the engine—and the engines themselves will start to decouple. Because now we have the ability to inject intelligence all throughout the system. Right now, it’s mostly happening at the entry and exit points, but I think we’ll start seeing hooks and modular pieces that let us apply algorithms and models throughout the entire stack to make the system as a whole smarter and more adaptable.
Are there any open-source tools or projects—beyond Elasticsearch and OpenSearch—that have significantly influenced your work?
I’m probably going to answer with more standard stack stuff, but honestly, Spark has been phenomenal. Just the ability to implement algorithms, run them at scale, and have them interact with lots of different systems has been incredibly useful.
I’d also say the general data science stack—Jupyter, Spark, and then of course the search engines—has had a big impact. That integration between data science tools and search has been really powerful in my work.
I don’t think there are any super niche libraries I rely on regularly. It’s mostly that core ecosystem.
What is a golden tip for optimizing search performance that you’ve picked up in your years of experience?
I would say, especially when it comes to relevance, one golden rule is to get evaluations in place early and often. And in particular, make sure that user behavior—things like clicks, queries, purchases—is considered from the very beginning of the project, not after the fact.
What I see a lot is teams building a search system and then not collecting good user behavior metrics until much later. By then, it's 10 times harder to do, and often it just doesn’t happen. So, design your system upfront with the idea that you're going to collect user feedback and interactions. Build in a way to model that data, generate evaluations from it, and run those evals consistently.
That kind of setup gives you a strong framework for doing high-quality work, rather than just relying on the “looks good to me” test.
What is the most unexpected or unconventional way you’ve seen search technologies applied?
I’ve seen search technologies applied to so many things—obviously, standard use cases like search and recommendations. But I’ll do a bit of a shameless self-promotional one here: leveraging the search index as a knowledge graph.
By traversing the index, you can directly answer questions about semantic relationships, and even perform analytics—not just traditional analytics, but what I’d call semantic ranking and analytics. It’s about using the search engine itself as a kind of knowledge graph, which opens up really powerful ways to explore and reason over data.
Give us a spicy take/controversial opinion on something related to Search
I think most of the chunking strategies people use for RAG are a waste of time—and they’ll mostly go away over the next couple of years, replaced by much smarter approaches. Right now, chunking is necessary to get things done, but it’s a stopgap.
You typically see three categories of chunking. First, there’s naive chunking, which is what most people are doing—even when they call it contextual RAG or adaptive RAG. It’s still just slicing documents based on where the words fall, with little real understanding.
Then there’s late chunking, where you generate embeddings at the word level first, and only afterward decide how to chunk the document based on those embeddings.
Finally, there’s late interaction, which involves giving every word a contextualized vector representing its meaning, and then searching across all of them. I think these late interaction models are far superior to the basic vector matching we’re doing today. They’re just inefficient right now—but we’ll find better ways to represent, compress, and prune them.
Once that happens, the need to chunk—at least in the traditional sense—will drop significantly. It won’t disappear entirely, but we’ll spend far less time splitting documents and far more time focusing on better matching and ranking strategies.
Can you suggest a lesser-known book, blog, or resource that would be valuable to others in the community?
My co-author Doug Turnbull has a great blog (https://softwaredoug.com/) — he writes a lot and does a really good job of staying current with what's happening in the search space. Let’s just say he’s good at keeping up with the industry buzzwords—but in a helpful way. When you read it, you’ll find, “Oh hey, here’s that new thing everyone’s talking about,” and it often goes just deep enough to be insightful without overwhelming you. It’s a solid resource and a good way to stay in the loop.
I’ll also give a quick plug for the AI-Powered Search website — there’s a lot of good material there as well.
And anything from Jo Kristian Bergum—formerly of Vespa, now doing his own thing—is worth reading. He’s a wealth of knowledge, and I try to follow everything he puts out. Definitely someone to keep on your radar.
Anything else you want to share? Feel free to tell us about a product or project you’re working on or anything else that you think the search community will find valuable
I’d love to plug aipoweredsearch.com. Of course, the book AI-Powered Search is out now, but there’s also a growing community around it—currently around 750 people, and it’s growing fast. I expect it’ll be over 1,000 in the next couple of months.
The broader goal with AI-Powered Search is to create a hub that aggregates and curates information from across the industry—pulling together content from different companies, highlighting the people doing great work, surfacing new tools and techniques, and providing a kind of firehose of high-signal information for the search and AI community.
We want it to be a space where you can come to see what’s happening across the entire industry—whether it’s blog posts, product launches, thought leadership, or emerging trends. It's a labor of love and a lot of effort, but it's coming together, and it’s getting better every day.
