treygrainger/ai-powered-search: the code repository behind the Manning book

What the AI-Powered Search repository actually contains

This is the code that ships with the book AI-Powered Search by Trey Grainger, Doug Turnbull and Max Irwin, published by Manning. The README describes it as code examples, and the top-level layout matches that: chapters/, course/, aips/, engines/, ltr/, semantic_search/, data/, webserver/ and a docker-compose.yml. The topics listed for the repository cover semantic search, hybrid search, learning to rank, click models, question answering, knowledge graphs and personalization, which is the book's table of contents expressed as tags rather than as a library API.

The intended reader is someone working through the book who wants to run the examples rather than read them. The README is explicit that the book provides the context: it says the book will walk you step by step through the concepts and techniques shown in the code examples, providing needed context and insights. That sentence is the honest description of the repository's role. Nothing here is packaged for import into another project.

How the notebook, Solr and Spark containers fit together

The mechanism is a Docker Compose stack. The notebooks service builds from build/Dockerfile and exposes five ports: 7077 for the Spark master, 8082 for the Spark master UI, 8081 for the Spark worker UI, 4041 for the Spark UI and 8888 for Jupyter. It receives AIPS_SOLR_HOST set to aips-solr and AIPS_ZK_HOST set to aips-zk:2181, and it bind-mounts the repository root into /tmp/notebooks/. That bind mount is why edits you make on the host show up inside the running container.

A separate solr service builds from engines/solr/build/ and listens on 8983, with SOLR_HOST=aips-solr and ZK_HOST=aips-zk:2181, and it depends on zookeeper and notebooks. An opensearch service is also defined, building from engines/opensearch/build/engine-Dockerfile, with discovery.type=single-node, DISABLE_SECURITY_PLUGIN=true and OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g. Both the notebooks and solr services declare the profiles all and the empty profile, so the default docker compose up brings them along while the OpenSearch node waits for its own profile.

The data flow for a typical example is: a notebook in chapters/ reads a dataset from data/, hands it to PySpark for processing, writes documents into Solr or OpenSearch through the engine abstraction in engines/, and then queries them. The README states that the default search engine is Apache Solr but that most examples are abstracted away from the particular engine, with swappable implementations promised for other engines and vector databases.

Installing the AI-Powered Search codebase and running your first notebook

The README says the only necessary setup is installing Docker, then pulling or building and running the containers. It gives the clone command first, then the compose command from inside the repository directory. The first build takes a while, which the README acknowledges.

git clone https://github.com/treygrainger/ai-powered-search.git
cd ai-powered-search
docker compose up

When the containers finish starting, the README directs you to http://localhost:8888 to launch the Welcome notebook, which it describes as a table of contents for all the live code examples in the book. That notebook is chapters/welcome.ipynb in the repository.

If you want the OpenSearch node as well, it is defined under its own profile in docker-compose.yml rather than started by the plain command above. The compose file shows the service name and the environment it expects:

opensearch:
  build:
    context: ./engines/opensearch/build/
    dockerfile: engine-Dockerfile
  environment:
    - discovery.type=single-node
    - DISABLE_SECURITY_PLUGIN=true

The README does not document how to select a profile on the command line, and the compose file is truncated in the repository listing, so treat the exact profile flag as something to confirm against the file itself before running it. The engines/README.md is the place the README points for the search engine abstractions and custom integrations.

Where the Jupyter and Docker approach breaks down

The repository is a book companion, and the constraints follow from that. Everything runs inside one Compose stack on one machine, with Solr, ZooKeeper, Spark and Jupyter sharing a Docker network. There is no guidance in the README for running the examples against a remote cluster, and no packaging that would let you import the techniques as a Python dependency. If you want to apply learning-to-rank or click models to an existing search deployment, you will be reading the notebooks for the approach and rewriting the code, not calling into it.

The environment variables in docker-compose.yml are another boundary. AIPS_SOLR_HOST and AIPS_ZK_HOST are set to container hostnames, so a notebook run outside the stack will not find Solr without changing them. The OpenSearch service disables the security plugin entirely, which is fine for a local teaching environment and wrong for anything reachable from a network.

The README also warns that executing the code may pull additional dependencies under alternate licenses and datasets whose licenses may change over time, some derived from AI models and some from web crawls. It states those datasets are published as-is for the sole purpose of demonstrating the concepts in the book. That is a clear signal not to build a product on the data the notebooks download.

AI-Powered Search versus a framework like Haystack or LlamaIndex

The closest comparison is a retrieval framework such as Haystack or LlamaIndex. Those are libraries: you install a package, import it into your own application, and compose pipelines programmatically, with the framework owning the abstractions for retrievers, rankers and generators. This repository inverts that. It owns no importable abstraction for your application; it owns a Docker environment, a set of notebooks and a book that explains the choices. The engine abstraction in engines/ exists so the book's examples can target Solr or OpenSearch, not so you can depend on it.

The practical difference shows up when something breaks. With a framework you file an issue against a versioned release. Here there are no releases retrieved for the repository, and the README routes questions to the Manning LiveBook forum included with a book purchase, plus pull requests and GitHub issues. You are working from a specific commit of a teaching codebase, and the version of the technique you get is the one the book describes.

Licence terms and what running the examples pulls in

The README states that all code in the repository is open source under the Apache License, Version 2.0, unless otherwise specified. That covers the notebooks, the Dockerfiles and the Python in aips/, engines/, ltr/ and semantic_search/. It does not automatically cover what the code downloads at runtime.

The same section notes that executing the code may pull dependencies under alternate licenses, and datasets that may be derived from AI models or from web crawls, published as-is for demonstration purposes with licenses that may change. The repository's licence is listed as unknown in the repository metadata, so the Apache 2.0 statement in the README is the reference point, not a verified licence file. This is not legal advice: if you intend to reuse a notebook's code or its data in a product, read the README's licence section and then inspect the licences of the specific dependencies and datasets that notebook pulls.

Maintenance status of the codebase

The repository is not archived, and the last push was on 2026-08-15, which is recent relative to today. That tells you the code is being touched. It does not tell you there is a release cadence: no releases were retrieved for the repository, and the README does not describe a versioning scheme for the notebooks or the Docker images.

The upgrade cost is therefore tied to the book edition rather than to a changelog. If you pull a newer commit, the notebooks and the Compose file may have moved on from what your copy of the book describes, and the README's only pointer for setup detail is Appendix A. The README also notes that swappable implementations for most popular search engines and vector databases will be available soon, which is a statement about future work rather than a current capability.

Editorial conclusion

Adopt this repository if you already have the book or want a runnable environment for its examples; the Docker Compose file starts Jupyter on port 8888 and Solr on 8983, and the README states the book's Appendix A has the full setup instructions. Do not adopt it as a production dependency or as a standalone tutorial, because the README frames the code as examples for the book and the datasets it pulls carry their own licenses. Before relying on any example, verify which engine profile you are running, check the engines/README.md for the current list of supported engines, and inspect the licenses of any dataset a notebook downloads.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. treygrainger/ai-powered-search on GitHub