- What is symfony/ai-elasticsearch-store and when should I use it?
- It is a Symfony AI Store bridge that persists embeddings in Elasticsearch and runs kNN similarity search over dense_vector fields. Use it for semantic search, retrieval-augmented generation (RAG) pipelines, recommendation engines, and hybrid keyword-plus-vector search in Laravel or Symfony applications. It fits teams that already run Elasticsearch for search or logging, since it avoids introducing a separate vector database.
- How do I install it in a Laravel app, and which PHP and Laravel versions are supported?
- Install it with composer require symfony/ai-elasticsearch-store, along with elasticsearch/elasticsearch for the underlying client, and opt into Symfony AI via symfony/ai-platform. PHP 8.2 or newer is required, which means Laravel 9 and 10+ projects are compatible while older versions need an upgrade or polyfills. No database driver is needed, but a reachable Elasticsearch 7.x or 8.x cluster is mandatory.
- How do I register the Elasticsearch store in Laravel's service container?
- Bind Symfony AI's StoreInterface to the Elasticsearch Store implementation in a service provider, or resolve the concrete class wherever you inject it. Configure the Elasticsearch PHP client separately, usually in config/services.php with host, credentials, and index settings. Once bound, Laravel AI workflows such as RAG can depend on the interface rather than the implementation, which keeps swapping backends straightforward.
- How do I create the Elasticsearch index and dense_vector mapping for embeddings?
- Create an index whose mapping declares a dense_vector field with a dimensionality matching your embedding model, typically 768 to 4096 dimensions for models like OpenAI or Mistral. You can script this through a Laravel migration, an artisan command, or a direct call to the Elasticsearch API. Getting the dimension and similarity metric right up front matters, because changing them later requires a full reindex.
- Can I combine keyword filters with vector similarity search?
- Yes. Elasticsearch kNN queries accept a filter clause, so you can restrict candidates by metadata such as category: books while still ranking by cosine similarity, and the store exposes hooks for custom query DSL when you need more control. This makes domain-scoped retrieval and hybrid keyword-plus-vector search practical without extra infrastructure.
- What changed in v0.14.1 for _bulk operations and how should I handle it?
- In v0.14.1, failed operations inside a bulk response now throw exceptions instead of being silently tolerated, so partial indexing failures surface immediately. Wrap bulk indexing and upsert jobs in try/catch with logging and retry or backoff logic where appropriate. The release does not change installation or API compatibility, but existing code that relied on partial failures continuing quietly may hit new error paths.
- Does it support exact kNN search instead of approximate, and how does that affect performance?
- Approximate kNN is the default and is faster on large indices; passing knn=false switches to exact search, which is slower but precise. Benchmark both against your dataset and query-per-second targets, then tune shard and replica counts for throughput. For most RAG use cases, approximate search with a sensible num_candidates value is accurate enough.
- How do I test and run this locally without a production Elasticsearch cluster?
- You need a reachable Elasticsearch 7.x or 8.x cluster, so for local development run one in Docker or point at a managed service such as AWS OpenSearch. In your test suite, assert that bulk failures now raise exceptions and that metadata filters return the expected vectors. Cold-start latency on self-hosted clusters can skew benchmarks, so warm the cluster before measuring.
- How does it compare to pgvector or Weaviate for vector search in Laravel?
- pgvector keeps vectors next to relational data in PostgreSQL and avoids a second system if you are already on Postgres, while Weaviate is a dedicated vector database with its own operational model. This bridge makes sense when Elasticsearch is already part of your stack, since you get vector search alongside existing keyword search and logs. The tradeoff is Elasticsearch index-mapping and cluster-tuning overhead.
- What happens if I need to change vector dimensions later, and how is the package maintained?
- Changing vector dimensions or metadata field types means creating a new index and reindexing, which can be costly for large datasets, so plan the schema early. The package tracks symfony/ai-store release constraints closely, so expect to wrap or fork it if you need Laravel-specific event listeners or custom behavior. It is maintained inside the main symfony/ai monorepo, where issues and pull requests are handled.