vectara-answer VS LLMStack

Hi HN!

I lead product for Vectara (https://vectara.com) and we recently worked with OpenSource connections to both evaluate our new home-grown embedding model (Boomerang) as well as to help users start more quantitatively evaluating these systems on their own data/with their own queries.

OSC maintains a fantastic open source tool, Quepid, and we worked with them to integrate Vectara (and to use it to quantitatively evaluate Boomerang). We're hoping this allows more vector/hybrid players to be more transparent about the quality of their systems and any models they use instead of everyone relying on and gaming a benchmark like BIER.

More details on OSC's eval can be found at https://opensourceconnections.com/blog/2023/10/11/learning-t...

RAG is a very useful flow but I agree the complexity is often overwhelming, esp as you move from a toy example to a real production deployment. It's not just choosing a vector DB (last time I checked there were about 50), managing it, deciding on how to chunk data, etc. You also need to ensure your retrieval pipeline is accurate and fast, ensuring data is secure and private, and manage the whole thing as it scales. That's one of the main benefits of using Vectara (https://vectara.com; FD: I work there) - it's a GenAI platform that abstracts all this complexity away, and you can focus on building your application.

I agree. my experience is that hybrid search does provide better results in many cases, and is honestly not as easy to implement as may seem at first. In general, getting search right can be complicated today and the common thinking of "hey I'm going to put up a vector DB and use that" is simplistic.

Disclaimer: I'm with Vectara (https://vectara.com), we provide an end-to-end platform for building GenAI products.

In this article I discuss my long-held belief that it's time we shifted the discussion from "which vector database to use" for GenAI and instead think about "how do we make this whole architecture simpler to use", a focus of GenAI platforms like https://vectara.com

With Vectara (full disclosure: I work there; https://vectara.com) we provide a simple API to implement applications with Grounded Generation (aka retrieval augmented generation). The embeddings model, the vector store, the retrieval engine and all the other functionality - implemented by the Vectara platform, so you don't have to choose which vector DB to use, which embeddings model to use, and so on. Makes life easy and simple, and you can focus on developing your application.

You can also use vectara to implement this. Just upload the docs via the indexing API and then run queries via the search API. It tends to be less complicated with Vectara since we take care of many things internally (vectorDB, embeddings, etc). Let me know if I can help further with that.

I found vectara.com but all examples seem to be about feeding text. I'm not super technical so I may be missing something. Please let me know if I need to elaborate further.

yes agreed that if ChatGPT becomes monetized the same way as Google, then it the fun will be over. We'll have to wait and see. I think though that this innovation is not just applicable to web search or consumer search, and with products like vectara.com providing this type of user experience in the enterprise there is a significant net gain here overall.

We have recently added support to query data from SingleStore to our agent framework, LLMStack (https://github.com/trypromptly/LLMStack). Out of the box performance performance when prompting with just the table schemas is pretty good with GPT-4.

The more domain specific knowledge needed for queries, the harder it has gotten in general. We've had good success `teaching` the model different concepts in relation to the dataset and giving it example questions and queries greatly improved performance.

This will hopefully improve the startup times for FFmpeg when streaming from virtual display buffers. We use FFmpeg in LLMStack (low-code framework to build and run LLM agents) to stream browser video. We use playwright to automate browser interactions and provide that as tool to the LLM. When this tool is invoked, we stream the video of these browser interactions with FFmpeg by streaming the virtual display buffer the browser is using.

There is a noticeable delay booting up this pipeline for each tool invoke right now. We are working on putting in some optimizations but improvements in FFmpeg will definitely help. https://github.com/trypromptly/LLMStack is the project repo for the curious.

We built https://github.com/trypromptly/LLMStack to serve exactly this persona. A low-code platform to quickly build RAG pipelines and other LLM applications.

Kudos to the team for a very detailed notebook going into things like pipeline evaluation wrt performance and costs etc. Even if we ignore the framework specific bits, it is a great guide to follow when building RAG systems in production.

We have been building RAG systems in production for a few months and have been tinkering with different strategies to get the most performance out of these pipelines. As others have pointed out, vector database may not be the right strategy for every problem. Similarly there are things like lost in the middle problems (https://arxiv.org/abs/2307.03172) that one may have to deal with. We put together our learnings building and optimizing these pipelines in a post at https://llmstack.ai/blog/retrieval-augmented-generation.

https://github.com/trypromptly/LLMStack is a low-code platform we open-sourced recently that ships these RAG pipelines out of the box with some app templates if anyone wants to try them out.

Django has been my go to framework for any new web project I start for more than a decade. Its batteries-included approach meant that one could go pretty far with just Django alone. Included admin interface and the views/templating setup was what first drew me to the project.

Django project itself has kept pace with recent developments in web development. I still remember migrations being an external project, getting merged in and the transition that followed. Ecosystem is pretty powerful too with projects like drf, channels, social-auth etc., covering most things we need to run in production.

https://github.com/trypromptly/LLMStack is a recent project I built entirely with Django. It uses django channels for websockets, drf for API and reactjs for the frontend.

We recently opensourced a similar platform for building workflows by chaining LLMs visually along with LocalAI support.

Check it out at https://github.com/trypromptly/LLMStack. Like you said, it was fairly easy to integrate LocalAI and is a great project.

Would you mind expanding why it was tough to get started with Retool?

We are building https://github.com/trypromptly/LLMStack, a low-code platform to build LLM apps with a goal of making it easy for non-tech people to leverage LLMs in their workflows. Would love to learn about your experience with retool and incorporate some of that feedback into LLMStack.

We built LLMStack for our internal purposes and pulled it out into its own repo and open sourced it at https://github.com/trypromptly/LLMStack.

LLMStack (https://github.com/trypromptly/LLMStack) is a no-code platform to build LLM apps that we have been working on for a few months and open-sourced recently. It comes with everything out of the box that one needs to build LLM apps locally or in an enterprise setting.