James Williams

James Williams builds search applications that connect language models to business data, from extracting tables in financial filings to turning property-search conversations into structured queries. His work at Elastic explains how document preparation, query interpretation, and ranking affect what an AI application can find and answer.

James’s career includes technical presales and leadership work at Pivotal and solutions architecture at Elastic. His professional profile lists him as Director of Solutions Architecture, leading a team of search specialists. Alongside that work, he publishes runnable examples that let developers inspect how these applications retrieve information and improve their results.

Preserving information before searching it

James’s document-processing implementation addresses a problem that a chatbot interface can conceal: important information is often trapped in PDF tables. His March 2025 example uses four quarterly financial filings to test a question requiring revenue comparisons across documents. It extracts paragraphs and tables with Azure AI Document Intelligence, preserves table-cell coordinates in text, and indexes the results in Elasticsearch for retrieval-augmented generation. For an answer spanning several reports, retrieving the numbers is only part of the task; their relationship to the surrounding table must survive ingestion.

With Jonathan Simon, James developed a natural-language property-search application that handles both precise requirements and loosely expressed preferences. A language model extracts attributes such as price and bedroom count, a geocoding tool resolves locations, and an Elasticsearch search template combines the resulting parameters with full-text and vector search. This division gives each component a specific job: the model interprets the request, while Elasticsearch executes the query against actual listings. The accompanying example repository includes the application and setup notebook.

Learning from search interactions

James and Craig Angulo extended property search into agentic search with relevance autotuning. Their reference architecture connects conversational queries to a feedback loop for ranking:

• Intent-aware search templates: An agent translates a conversational request into parameters for predefined Elasticsearch queries. Developers can specify the retrieval operations available to the agent while allowing users to express their needs in natural language.
• Ranking informed by interactions: Logged searches, returned results, and follow-up interactions supply features for an XGBoost learning-to-rank model. The architecture uses subsequent search behavior to train ranking, extending improvement beyond the initial interpretation of a request.
• Inspectable experiments: The open-source demonstration includes alternative search templates, ranking comparisons, and a dashboard showing click-through rate, result position, and template usage. Simulated engagement patterns let developers explore how different preferences affect results. These are demonstration inputs, rather than measured customer outcomes.

James also highlights the resource costs of retrieval. In a public post about Better Binary Quantization, he emphasized its potential to reduce vector-search memory requirements. That interest complements his application examples: retrieval choices affect both which information reaches a model and the resources required to find it.