The book arcs from concepts to tools and on to complete applications: similarity search, a scientific paper search system, a question-answering system over your own documents running on a single machine, and search over private conversations. The author's position is declared in the preface: he prefers extensions on familiar databases over a new specialised engine.
What I took from it
The argument for not adding a piece of infrastructure. If the data already lives in a relational database, putting the vectors beside it avoids keeping two systems in step, and that synchronisation is where the errors nobody sees come from, until someone asks a question and gets last year's answer. Since then, when someone proposes searching their documents by meaning, my first proposal is the database they already have, and I want a reason to move.
The over-fetch-then-filter pattern, which explains why combining a metadata filter with a similarity search gives worse results than expected: the filter does not travel inside the search, it is applied on top, and if you ask for few results the filter is left with nothing to filter.
And the reminder that all of this can run on a single machine, with no third-party service, when the documents cannot leave the company. Here is the part of this I do.
What I left out
Two things, and the book flags one of them: the examples are built for personal use and learning, not production, which limits how much can be copied. The other it does not flag: one of the two extensions it builds on has already been superseded by another from the same ecosystem. And the closing proposal for a standard vector query language is a reasonable idea and, for now, only that.