Search results

After training LLMs on the whole world, prompting them for zero-shot, finetuning them on specialized domains, what is the next stage? The goal is clear: adapting models further and further. I can see two competitors there: website finetuning and recommenders. – Recommenders – Recommenders are basically finetuned on users. They already use embeddings, are effective, and do not need labeling thanks to user events. But privacy is a problem. – Website finetuning – On the other hand, Website finetuning is performed on the site content, especially vocabulary. But labeling is a problem. We can use LLMs to generate labels (questions), but is it not a chiken/eggs loop?

https://aiquarious.com/ #vectorsearch #promptengineering #finetuning #largelanguagemodels

(Following Part 4) The coding of query filters and query aggregations (facets) for Vespa is now complete. One can define facets and filters with advanced facet layouts, from the WPSOLR admin. Some details below: – Vespa provides YQL, a SQL-like language, to build queries with filters and aggregations. It’s very simple to use for most developers who are already familiar with SQL. – Vespa does not provide a YQL syntax for filter exclusions yet. Filter exclusion is very important for e-Commerce, as it enable to show facet contents eliminated by the current facet selection. To overcome this issue, WPSOLR will call several aggregation queries in parallel https://lnkd.in/dvhAKJpZ. We did the same trick for Weaviate 🙂 All facet layouts are available to Vespa queries: – check boxes – radio

(Following Part 3) The coding of document indexing operations for Vespa is now complete. One can create a new document, update a document, and delete a document, from the WPSOLR admin. Some details below: – Vespa does not use server-side batching documents. WPSOLR will implement it client-side with asynchronous http/2 calls as recommended by Vespa https://lnkd.in/d8SYeA7p. – Vespa does not use dynamic field names, which would enable to index and search documents with fields not pre-defined in the schema.sd To overcome this issue, WPSOLR detect missing fields’ error sent by Vespa to update and redeploy the schema accordingly. This is important because some document fields like ‘_price’ may(not) be added by optional WPSOLR add-ons like WooCommerce – Vespa provides a documents deletion from query (named ‘selection’), which

(Following Part 2) The coding of index CRUD operations for Vespa is now complete. One can create a new index, update an index, and remove an index, from the WPSOLR admin. It was quite interesting: – Check that the application is deployed already. If not, deploy its zip – Create the new index’s schema file with a modified services.xml ( add the document element to the content’s documents elements of the downloaded services.xml) – Remove the deleted index’s schema file, but also remove the document element to the content’s documents elements of the downloaded services.xml. Also add a temporary validation-overrides.xml to authorise the schema removal. – Prepare and activate within a new session to deploy the new/updated/deleted application/schema WPSOLR: https://www.wpsolr.com #vespa #wpsolr #aisearch #vectorsearch #woocommerce #wordpress

(Following Part 1) A major prerequisite of WPSOLR is to modify an index schema automatically when a user adds/update fields from the plugin admin screens. But when the Vespa application package is already created, how to redeploy the schema without overriding other files (hosts.xml, services.xml, models, …)? Thanks to Github discussion https://lnkd.in/dT-Yj95C, we now have a solution and can start coding! WPSOLR: https://www.wpsolr.com #vespa #wpsolr #aisearch #vectorsearch #woocommerce #wordpress

How to map your WooCommerce search to a Vespa architecture? Vespa is a highly modular big data engine, with many concepts: tenant, application package, zone, instance, deployment, service, schema. And many more. A first investigation of the documentation leads us to map WPSOLR search indices to application packages’ schemas. Here is the reasoning: 1. Vespa Cloud’s tenant can be used to model a project (customer, site, …) 2. Each tenant can host several application packages 3. Each application package can host several schemas 4. WPSOLR will automatically deploy a default application package, with a root schema and a child schema. 5. The virtual root schema contains all predefined field settings, but no data. It can only be modified by WPSOLR. 6. The child schema will inherit

– Vegetable & fruits shop with Weaviate + Cohere. Content in Hebrew, visitors query (no translation, no stemming, no N-Grams, no synonyms, no nothing) in 5 languages. Suggestions and faceted search. https://freshuk.co.il/ – WooCommerce demo with Weaviate & hybrid search https://lnkd.in/d4YxuVhF – WooCommerce demo with Weaviate & Cohere search https://lnkd.in/dy_wcPYA – WooCommerce demo with Weaviate & CLIP text-to-image search https://lnkd.in/diUn-8Mm – WooCommerce demo with Weaviate & OpenAI https://lnkd.in/dBzeqUxC More on Weaviate + WooCommerce: https://www.wpsolr.com #weaviate #wpsolr WooCommerce