Maching Learning and Natural Language Processing is somewhat data-driven. Without a continuous supply of high-quality data (which must be re-captured whenever new criteria are added), the software development may miss its intended target.
The customer and product owner may devote a bigger fraction of their time toward test data collection.
The adaptations will depend on:
- The balance of time allocated toward "spike" versus "implementation"
- spike: open-ended research / exploratory prototyping (where the benefits are possible but not certain, and where priorities are fast-changing)
- implementation (where the benefits and costs are somewhat more predictable, but each task unit will take much longer to finish).
- Average size of a task unit. How long does a spike take? How long does an implementation take? Unlike typical application development, partial algorithm implementations are usually not runnable.
- Whether "canned algorithms" i.e. existing libraries / algorithm packages are available.
- When these are available, time spent on "implementation" is reduced (because they're already written) and thus more time will be spent on "spikes".
There will be two feedback loops:
- In each iteration, customer and product owner collect/update data periodically (and with better quality / newer criteria) based on business need and developers' feedback.
- In each iteration, developers try to improve algorithm quality based on the data available, and the algorithm is packaged into a usable system and delivered at the end of each iteration. Customer and product owner should be allowed to take the beta system elsewhere, redistribute them, etc.
Thus, we see that "data" replaces "features" as the main definition of progress.
Because of the increased importance of "research / spike" in ML/NLP development, there is a need for a more organized approach to spike - something you may have already learned from any graduate research teams. Spikes are to be treated as "mini-tasks", taking from hours to days. Implementation of one algorithm suite will take longer, in some cases weeks. Because of task size differences, spikes and implementations are to be prioritized separately. Implementations are costly, something to be avoided if possible. This is one reason for using canned algorithms / existing libraries.
The scrummaster will need to constantly remind everyone to: (1) note down every observation, including "passing thoughts" and hypotheses, and exchange notes often (daily). (2) Spend more time on spikes (3) use existing libraries as much as possible (4) don't worry about execution time - this can be optimized later.
If you do decide to implement something that's missing in libraries, do it with good quality.
Daily activities:
- Reprioritize spikes (short tasks / hours - days) and exchange research notes.
- De-prioritize spikes aggressively if yesterday's result don't seem promising.
- Everyone must commit a fraction of time on implementation (long tasks / weeks), otherwise nobody would be working on them because they tend to be more boring on tasks.
Sprint activities:
- Demo, presentation of beta software
- New data collection
- Retrospect: data collection criteria / new measures of quality, algorithm satisfaction, balance between spikes and implementations
About the note on deferring optimization: The thought-to-code ratio is much higher in ML/NLP than in business software. Thus, once you have a working idea, rewriting the algorithm for an ML/NLP application is easier than rewriting a business software. This means it is easier to get rid of inefficiencies inheritant in the architecture (that is, in the worst case, simply do a rewrite.)
(All editors are welcome to rearrange (re-order) my points.)
Monte-Carlo methods may work for you. In a nutshell: define the boundaries of the results you are looking for, for example energy consumption(derived from measured system parameters) within a range, and run a simulation where the free variables are allowed to vary to simulate a physical system. The sets that fall within the solution space will define the acceptable input ranges.
If your search space is manageable (depends on your system constraints), then you can fit curves to these parameters.
Alternately, you can use a minmax approach if you can define your search space in a way suitable for local minimization.
Best Answer
Fuzzing is a testing method where machine learning can & has been applied. Fuzzing is a method of testing in the realm of automated exploratory testing. It attempts to find defects in software by running a large number of inputs and looking for errors. Unhandled exceptions are the simplest category, but a smart implementation can use ML to find suspect outputs. ML is largely used in this domain in order to make the process more efficient however. This works by using ML to avoid testing every possible input by training on "interesting" inputs. (Dis-similar inputs that are likely to cause failure.)