Suggestions
Brian Gawalt
Gemini Cloud Assist: AI for troubleshooting
Brian Gawalt is a Senior Software Engineer at Google, specializing in applied machine learning and statistics.13 He has been working at Google since 2015, accumulating over 8 years of experience in this role.25
Professional Background
Gawalt's career trajectory includes:
- Senior Software Engineer at Google (2015-present)
- Senior Data Scientist at Upwork (previous role)
- Data Scientist at Quantifind (previous role)
- Independent Contractor at SurveyMonkey (previous role)
Education
Brian Gawalt holds a Doctor of Philosophy (Ph.D.) from the University of California, Berkeley, which he pursued from 2005.5 His academic background has likely contributed to his expertise in machine learning and statistics.
Skills and Expertise
As a software engineer at Google, Gawalt focuses on:
- Developing machine learning and analytics code
- Deploying solutions on servers and Android devices3
- Working with large text corpora and topic-specific summarization4
Research and Publications
Gawalt has contributed to academic research, with citations in Google Scholar.6 His work appears to involve networked systems design and implementation, as evidenced by his contributions to USENIX symposiums.
Online Presence
Brian Gawalt maintains a professional presence on various platforms:
- LinkedIn: His profile can be found under the username "bgawalt"1
- ResearchGate: He has a profile showcasing his research work4
- Personal website: He maintains a personal website at brian.gawalt.com3
Throughout his career, Brian Gawalt has demonstrated a strong focus on data science, machine learning, and software engineering, particularly in his current role at Google where he applies these skills to develop and deploy advanced analytics solutions.
Highlights
I've come to appreciate that large language models represent a huge opportunity for reducing operational costs. I'm now look 100x more favorably on reaching for an LLM a first-pass model, than I did in Nov 2022, and it's because of this operational-complexity-reduction aspect that I don't think gets enough attention.
My background is in "traditional" ML and applied statistics, where best practices for predictive modeling are to start with a simple model, benchmark its performance, and only then reach for a more complicated one. And so the last two years of "the future... is prompt engineering" bounced off me. A 550MM parameter model is the exact opposite of "start simple, grow from there," and so I bucketed it all as hype, talking-your-book, or straight-up AGI millenarianism.
And then, on a buddy's invitation, I started working as a prompt engineer, and now I kinda get it. I count "use an LLM" as a simple baseline, if you factor in model-serving infra costs.
If your org can invest in keeping a large pool of accelerator-backed LLM-servers up and running, you might as well try building your predictive task off that interface first. Set up your pipelines and evals just as you always would: 10K+ examples, cleaned, features extracted into some structure*, 60-20-20 train-valid-test split**. Just, when it's time to make the examples into a matrix, try a many-shot prompt string instead. See what falls out the other side.
Because if it works -- if you like where your prompt gets you on the bias-variance curve -- you can now make productionalizing a breeze. The same fixed cadre of SREs can keep everyone's pool of {G, T, X}PUs up and running. Your inferences within that pool will come with such-and-such service levels and a well-understood price tag.
The alternative is a framework that has to accept any random model your team comes up with, and also, your team has to come up with the model. It needs a pipeline to push-button retrain a new version, it needs a way to reliably push those versions to prod, and it can be hard to anticipate how well your inferences run at a particular price tag, because no one's ever run your model before. And someone needs to mind that uptime.
Meanwhile, the teams grabbing Gemini or GPT off-the-shelf: inference on those models are now well understood. If the expensive part of production is SWE+SRE toil, you should share that cost with your neighbors (if you can) by posing your prediction as fancy autocomplete.
(Important caveat! Unless you can't afford ~$1 per million inferences, or long latencies, that come from LLM-level compute, which is indeed common. In that case, yeah, stick with SciKit Learn as a baseline and proceed as normal.)
If you have a Mastodon account, and also like reading books, and want your Mastodon account to start randomly-but-regularly posting what book you're currently reading, I've got a no-code Python solution just for you:
