Pathway to acceptance

1. engineering development
2. limitations of change request
3. NN testing
4. open loop testing
5. sims
6. track testing
7. shadow mode
8. real world testing
9. wave1 user problems
10. rollout metrics

why end to end system?

• human values is hard to codify
• the interfaces betteen observation and action isn’t wel defined
• can scale to handle long tail problems
• homogeneous compute + known latency

how to support data collection for corner cases?

• small NNs that trigger data collection for specific problems
• user intervention
• large change in state space

Two Problems with Alignment

• underspecification: specs are non-exhaustive
• overgeneralization: specs are non-restrictive

Tips

Of course I’m not committing my midterm.

array programing

“collection-oriented programming”—

1. precise programs with bulk operations over the whole collection—the iteration structures/accesses are spelt out much more explicitly (i.e. not to use general structures like for loops as a crutch): iteration patterns are baked into the language
2. performance: leaving the details of parallelism to your hardware

array programmings are easy to optimize

Lifting for loops is hard; but: \(\qty(\text{map } f) \cdot \qty(\text{map } g) = \text{map } \qty(f \cdot g)\). This is, notably, not true if your functions \(f\) and \(g\) are not pure (i.e. they have state or can throw exceptions); for instance, \(f\) crashes up front and \(g\) crashes in the end, then, the crashed error is different between the first and second method of evaluation.