3 ms·

Sorry if this is a bit ignorant, I don't work in the space, but if a single LLM invocation is considered too slow, how could splitting it up into a pipeline of

Sorry if this is a bit ignorant, I don't work in the space, but if a single LLM invocation is considered too slow, how could splitting it up into a pipeline of LLM invocations which need to happen in sequence help? Same with reliability - you don't trust the results of one prompt, but you trust multiple piped one into another? Even if you test the individual components, which is what this approach enables and this article heavily advocates for, I still can't imagine that 10 unreliable systems, which have to interact with rach other, are more reliable than one. 80% accuracy of one system is 80% accuracy. 95% accuracy on 10 systems is 59% accuracy in total if you need all of them to work and they fail independently.

peter_l_downs 3y ago
I think the idea behind breaking down the task into a composable pipeline is that you then replace the LLM steps in a pipeline with supervised models that are much faster. So you end up with a pipeline of non-LLM models, which are faster and more explainable.
cmcaleer 3y ago
> you don't trust the results of one promt, but you trust multiple piped one into another? This is really not at all unusual. Take aircraft for instance. One system is not reliable, for a multitude of reasons. A faulty sensor could be misleading, a few bits could get flipped by cosmic rays causing ECC to fail, the system itself could be poorly calibrated, there are far too many unacceptable risks. But add TMR[0][1] and suddenly you are able to trust things a lot more. This isn't to say that TMR is bullet proof e.g. incidents like [2], but redundancy does make it possible to increase trust in a system, and assign blame to what part of a system is faulty (e.g. if 3 systems exist, and 1 appears to be disagreeing wildly with 2 and 3, you know to start investigating system 1 first). Would it work here? I don't know! But it doesn't seem like an inherently terrible or flawed idea if we look at past applications. Ensembling different models is a pretty common technique to get better results in ML, and maybe this approach would make it easier to find weak links and assign blame. [0]: https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy [1]: https://en.wikipedia.org/wiki/Air_data_inertial_reference_unit https://en.wikipedia.org/wiki/Air_data_inertial_reference_un... [2]: https://www.atsb.gov.au/media/news-items/2022/pitot-probe-covers https://www.atsb.gov.au/media/news-items/2022/pitot-probe-co... causing total confusion among the TMR
- chongli 3y ago
  This isn't to say that TMR is bullet proof e.g. incidents like [2], but redundancy does make it possible to increase trust in a system, and assign blame to what part of a system is faulty (e.g. if 3 systems exist, and 1 appears to be disagreeing wildly with 2 and 3, you know to start investigating system 1 first). You can only gain trust in this system if you understand the error sources for all three systems. If there’s any common mode errors then you can see errors showing up in multiple systems simultaneously. For example, if your aircraft is using pitot tubes [1] to measure airspeed then you need to worry about multiple tubes icing up at the same time (which is likely since they’re in the same environment). So it would not add very much trust to implement TMR with three different pitot tubes. It would be better to combine the pitot tubes with completely different systems, such as radar and GPS, to handle the (likely) scenario of two or more pitot tubes icing up and failing completely. [1] https://en.wikipedia.org/wiki/Pitot_tube?wprov=sfti1 https://en.wikipedia.org/wiki/Pitot_tube?wprov=sfti1
vjerancrnjak 3y ago
It's not ignorant. It is a known problem. Before LLMs, approaches to machine translation or any high level language tasks did start with a pipeline (part of speech tagging, dependency tree parsing, named entity recognition etc.) but quickly these attempts were discarded. All of the models in the pipeline are not optimized with the joint loss (the final machine translation model that maps lang A to lang B does not propagate its error to the low level models in the pipeline). A pipeline of LLMs will accumulate the error in the same way, eventually the same underlying problem of pipeline not being trained with the joint loss will result in low accuracy. LLMs or DNNs in general do more compute, so they start being extremely powerful even when sequenced. Making a sequence of decisions with a regular ML model has a similar problem to pipelining, if you train it on single decision loss and not the sequence of decisions loss, then there's a question of can it recover and make a right next step if it made the wrong step (your training data never included this recovery example), but convolutional NNs were so powerful for language tasks that this recovery from error was successful (even though you never trained CNNs over the joint loss of sequence of decision).
- visarga 3y ago
  It's not a given that the performance would suffer. For instance, you could use self-checking methods like cycle consistency or back translation in a sequence of prompts. Another option is to generate multiple answers and then use a voting system to pick the best one. This could actually boost the LLM's accuracy, although it would require more computation. In various tasks, there might be simpler methods for verifying the answer than initially generating it. Then you have techniques like the Tree of Thoughts, which are particularly useful for tasks that require strategic planning and exploration. You just can't solve these in one single round of LLM interaction. In real-world applications, developers often choose a series of prompts that enable either self-checking or error minimization. Alternatively, they can involve a human in the loop to guide the system's actions. The point is to design with the system's limitations in mind. On a side note, if you're using vLLM, you can send up to 20 requests in parallel without incurring additional costs. The server batches these requests and uses key-value caching, so you get high token/s throughput. This allows you to resend previous outputs for free or run multiple queries on a large text segment. So, running many tasks doesn't necessarily slow things down if you manage it correctly.
syllogism 3y ago
(Author here) About the speed, the idea is that if you break down the task, you can very often use much smaller models for the component tasks. LLMs are approaching prediction tasks under an extremely difficult constraint: they don't get to see many labelled examples. If you relax that constraint and just use transfer-learning, you can get better accuracy with much smaller models. The transfer-learning pipeline can also be arranged so that you encode the text into vectors once, and you apply multiple little task networks over the shared representation. spaCy supports this for instance, and it's easy to do when working directly with the networks in PyTorch etc.
- daveguy 3y ago
  What does it mean to "just use transfer-learning"? I thought this was very much an unsolved task, even with LLMs.
  - syllogism 3y ago
    There's definitely active research on it. But here's the basic recipe that gets state-of-the-art accuracy on most tasks. It's been around for 5 years or so now, which is why I said "just". You take an encoder transformer architecture like BERT and train it on a language modelling objective. Then you discard the part of the network that does the token prediction, and stick some randomly initialised network that does a specific task on. This is generally kept minimal. For classification tasks, often people just connect a linear layer to the vector that represents a dummy sentinel token after the sequence. The general goal is to exploit the representations learned during the language modelling task, so that the network starts out knowing general grammatical structure of the language, multi-word expressions, can distinguish word senses from each other, etc. Then it needs far fewer examples to learn a specific task. There's definitely transfer learning going on: if you initialise the network randomly instead of via the LM objective, results are very much worse. This is a good blog post from when the recipe was still fairly new: https://www.ruder.io/nlp-imagenet/ https://www.ruder.io/nlp-imagenet/

peter_l_downs 3y ago

I think the idea behind breaking down the task into a composable pipeline is that you then replace the LLM steps in a pipeline with supervised models that are much faster. So you end up with a pipeline of non-LLM models, which are faster and more explainable.

cmcaleer 3y ago

> you don't trust the results of one promt, but you trust multiple piped one into another? This is really not at all unusual. Take aircraft for instance. One system is not reliable, for a multitude of reasons. A faulty sensor could be misleading, a few bits could get flipped by cosmic rays causing ECC to fail, the system itself could be poorly calibrated, there are far too many unacceptable risks. But add TMR[0][1] and suddenly you are able to trust things a lot more. This isn't to say that TMR is bullet proof e.g. incidents like [2], but redundancy does make it possible to increase trust in a system, and assign blame to what part of a system is faulty (e.g. if 3 systems exist, and 1 appears to be disagreeing wildly with 2 and 3, you know to start investigating system 1 first). Would it work here? I don't know! But it doesn't seem like an inherently terrible or flawed idea if we look at past applications. Ensembling different models is a pretty common technique to get better results in ML, and maybe this approach would make it easier to find weak links and assign blame. [0]: https://en.wikipedia.org/wiki/Triple_modular_redundancy https://en.wikipedia.org/wiki/Triple_modular_redundancy [1]: https://en.wikipedia.org/wiki/Air_data_inertial_reference_unit https://en.wikipedia.org/wiki/Air_data_inertial_reference_un... [2]: https://www.atsb.gov.au/media/news-items/2022/pitot-probe-covers https://www.atsb.gov.au/media/news-items/2022/pitot-probe-co... causing total confusion among the TMR

chongli 3y ago
This isn't to say that TMR is bullet proof e.g. incidents like [2], but redundancy does make it possible to increase trust in a system, and assign blame to what part of a system is faulty (e.g. if 3 systems exist, and 1 appears to be disagreeing wildly with 2 and 3, you know to start investigating system 1 first). You can only gain trust in this system if you understand the error sources for all three systems. If there’s any common mode errors then you can see errors showing up in multiple systems simultaneously. For example, if your aircraft is using pitot tubes [1] to measure airspeed then you need to worry about multiple tubes icing up at the same time (which is likely since they’re in the same environment). So it would not add very much trust to implement TMR with three different pitot tubes. It would be better to combine the pitot tubes with completely different systems, such as radar and GPS, to handle the (likely) scenario of two or more pitot tubes icing up and failing completely. [1] https://en.wikipedia.org/wiki/Pitot_tube?wprov=sfti1 https://en.wikipedia.org/wiki/Pitot_tube?wprov=sfti1

vjerancrnjak 3y ago

It's not ignorant. It is a known problem. Before LLMs, approaches to machine translation or any high level language tasks did start with a pipeline (part of speech tagging, dependency tree parsing, named entity recognition etc.) but quickly these attempts were discarded. All of the models in the pipeline are not optimized with the joint loss (the final machine translation model that maps lang A to lang B does not propagate its error to the low level models in the pipeline). A pipeline of LLMs will accumulate the error in the same way, eventually the same underlying problem of pipeline not being trained with the joint loss will result in low accuracy. LLMs or DNNs in general do more compute, so they start being extremely powerful even when sequenced. Making a sequence of decisions with a regular ML model has a similar problem to pipelining, if you train it on single decision loss and not the sequence of decisions loss, then there's a question of can it recover and make a right next step if it made the wrong step (your training data never included this recovery example), but convolutional NNs were so powerful for language tasks that this recovery from error was successful (even though you never trained CNNs over the joint loss of sequence of decision).

visarga 3y ago
It's not a given that the performance would suffer. For instance, you could use self-checking methods like cycle consistency or back translation in a sequence of prompts. Another option is to generate multiple answers and then use a voting system to pick the best one. This could actually boost the LLM's accuracy, although it would require more computation. In various tasks, there might be simpler methods for verifying the answer than initially generating it. Then you have techniques like the Tree of Thoughts, which are particularly useful for tasks that require strategic planning and exploration. You just can't solve these in one single round of LLM interaction. In real-world applications, developers often choose a series of prompts that enable either self-checking or error minimization. Alternatively, they can involve a human in the loop to guide the system's actions. The point is to design with the system's limitations in mind. On a side note, if you're using vLLM, you can send up to 20 requests in parallel without incurring additional costs. The server batches these requests and uses key-value caching, so you get high token/s throughput. This allows you to resend previous outputs for free or run multiple queries on a large text segment. So, running many tasks doesn't necessarily slow things down if you manage it correctly.

syllogism 3y ago

(Author here) About the speed, the idea is that if you break down the task, you can very often use much smaller models for the component tasks. LLMs are approaching prediction tasks under an extremely difficult constraint: they don't get to see many labelled examples. If you relax that constraint and just use transfer-learning, you can get better accuracy with much smaller models. The transfer-learning pipeline can also be arranged so that you encode the text into vectors once, and you apply multiple little task networks over the shared representation. spaCy supports this for instance, and it's easy to do when working directly with the networks in PyTorch etc.

daveguy 3y ago
What does it mean to "just use transfer-learning"? I thought this was very much an unsolved task, even with LLMs.
- syllogism 3y ago
  There's definitely active research on it. But here's the basic recipe that gets state-of-the-art accuracy on most tasks. It's been around for 5 years or so now, which is why I said "just". You take an encoder transformer architecture like BERT and train it on a language modelling objective. Then you discard the part of the network that does the token prediction, and stick some randomly initialised network that does a specific task on. This is generally kept minimal. For classification tasks, often people just connect a linear layer to the vector that represents a dummy sentinel token after the sequence. The general goal is to exploit the representations learned during the language modelling task, so that the network starts out knowing general grammatical structure of the language, multi-word expressions, can distinguish word senses from each other, etc. Then it needs far fewer examples to learn a specific task. There's definitely transfer learning going on: if you initialise the network randomly instead of via the LM objective, results are very much worse. This is a good blog post from when the recipe was still fairly new: https://www.ruder.io/nlp-imagenet/ https://www.ruder.io/nlp-imagenet/