https://www.boundaryml.com logo
🟡 Describing scaling of complexities in LLM promp...
# questions
j
Does anyone know of any attempts at describing the scaling of time/input token/output token complexities with respect to narrowly defined LLM prompts? It'd be nice to have a way to formally describe how semantically consistent LLM function primitives scale to have a useful way of building really complex but reliable things with them. Like a stochastic variant of Big O. Seems like something worth spending some time thinking about imo.
I've been having a bunch of thoughts about this and a potential solution to the lack of true mathematical determinism involved with LLMs. I think a potential solution I'm going to try is to represent a combined complexity profile similar to combining time + space + I/O complexity but instead for the various nuances of an LLM function. But since we can't actually create purely theoretical representations my idea is instead to reverse engineer the math working backwards from the results. By creating a look up table of potential complexities using example prompts in an ordered list between complexity bounds (prompts representing each corner of the desired complexity space) my idea is that you'd be able to quickly inference that LUT with a LLM function for each dimension of the LUT whose only job is ordered list insertion with a very narrow output shape. That would allow you to predict the various scaling complexities of an LLM function for the specific model/reasoning level it's running on before you ever ship or widely test anything. And if I could get that working well the next step is you can use that resulting data to inform and steer an LLM to create better prompts that optimize for the complexities you care about. To get the model/reasoning specific results you would run the sample of prompts and record what happened then use that data to generate a set of constants representing various complexity multipliers. That way you can figure out how to get low time complexity while also maintaining minimal output variability leading to LLM functions that are both fast and accurate enough for their specific use case. Idk maybe I'm wrong but I personally think something along the lines of this kind of data driven engineering approach is how we go from imperfect subjective human judgement LLM functions built using trial and error to actual production ready algorithms built using layered LLM functions enabling entirely new types of algorithms never before computable.
v
It feels a bit like DSPy.
j
I've been using DSPy as inspiration for guiding a potential solution here. There's definitely a lot of things in the general area of this stuff but nothing that really gives you an understanding of how the prompt you write today will scale in production. At least nothing me or ChatGPT can find lol.