193 karma · joined March 25, 2023
That makes it hard to evaluate the genAI parts of the application, and also iterating on the prompts is not as straightforward as opening up a playground.
Having the config be the source of truth let's you connect it to your application code (and still source controlled), lets you evaluate the config as the AI artifact, and also lets you open the config in a playground to edit and iterate.
For example, compare how much simpler openai function calling becomes with storing the stuff as a config: https://github.com/lastmile-ai/aiconfig/blob/main/cookbooks/... vs using vanilla openai directly (https://github.com/openai/openai-node/blob/v4/examples/funct...)
Our basic premise is that AI application development should be config-based, so you can track the prompts, models and model parameters being used more rigorously. Having this AI artifact then lets you iterate on it separately from your application code, and also set up evals that provide "test coverage" for the gen AI parts of your application.
We were also inspired by the ipynb format for Jupyter notebooks, and you'll see parallels to that in the aiconfig format.
Please ask any questions, and share your thoughts on config vs. code.
This talk by Karri about Linear's "sync engine" is also a good watch: https://www.youtube.com/watch?v=Wo2m3jaJixU.
With LLMs and other generative AI models, we want to provide simpler tools to bridge that 'last mile' gap between the core foundation models, and using/personalizing/integrating them in your applications. Hence the name :)
Like some of the other comments pointed out, the key element here is trust -- in the 3rd-party platform collecting signatures, and in the confidence that it cannot be manipulated. These are solvable challenges, but calling that out explicitly in your documentation and website copy will help convert skeptics, or at least convince them to give it a try.
We haven’t seen any usage of the more exciting-looking demos of semi-autonomous agents in production yet, and probably won’t for some time.
50 years from now I wonder what things we are amazed by today will sound silly to future technologists.
It’s also simplistic, because AI-related innovation is happening across companies of every size at every layer of the tech stack. Even Open AI with its state of the art foundation models needs to compete with both open source and large companies coming out with new LLMs.
Pieces like this may also discourage bright people from taking risks and building cool things, because they worry that this is just a big company game. It’s just too early to think like that.
I would love to learn more about the technology — are these wireless transmitters? Undersea cables all around the oceans of the world?
This stack is evolving so quickly but we are convinced it goes back to a distributed systems/infra problems when it comes to complexity, unless you’re training your own foundation models.
All the other things the engineers can themselves address (e.g. better tooling, etc), but the organization’s culture around protecting makers schedule is impossible to address individually
2. Change tactics: try to have some design discussions async (for e.g. by getting comments on a doc ahead of time). This gives you time to process their feedback, and the meeting can be a place to discuss it.
Ultimately the outcome may still be the same in terms of the technical decisions, but I have found perspective and tactics can affect how the team feels about them, and also creates space for good ideas you may not have considered to be heard constructively.
Hope this helps!
I have noticed that Notion having a built-in AI assistant helps with writing because I hardly ever use something generated verbatim — so it’s easier to be in an interface that is editable.
Perplexity is also good for saving and sharing different queries.
Makes you wonder how far we can get with trial and error.
Are there evaluation strategies that worked best for you? We basically want to allow users/developers to evaluate which LLM (and specifically, which LLM + prompts + parameters) has the best performance for their use case (which seems different from the OpenAI evals framework, or benchmarks like BigBench).