Today terms like Artificial Intelligence and Machine Learning are used interchangeably to describe systems that possess capabilities not easily implemented as heuristics; applications such as speech recognition, prediction or computer vision fit into this space. From an industry perspective however, we rarely discuss feature level strategies and instead try to design into a system a set of cognitive capabilities which leverage AI, ML, and a range of associated patterns and practices.
So how do you “cognify” your apps? There are two major areas to consider.
What is the cognitive scenario you’re building for?
While cognition is more of a marketing term these days, when product teams begin to think about using it, it becomes more of a solution looking for a problem. A better approach is to consider your key user scenarios and ask yourself a few questions:
- Can we leverage behaviours from other users to help a new customer use the system? For example, using collaborative filtering to suggest a set of starting options for a user at the beginning of a “new” interaction flow.
- Are there tasks we can perform on behalf of the user using their prior interactions that eliminate the need for certain UI components? A classic example of this is intensive data entry applications. Initially the user is presented with data entry screens, but over time you could train a network to fill in the forms on behalf of the user. It’s true you could also build a heuristical approach to this using regex statements to map values to field identifiers like css paths or xpaths, but as most people find, the edge cases with these approaches can become difficult to maintain and manage over time.
- Can we learn workflows within the application by observing the user’s interaction flows? Routing and approval paths are a perfect scenario for this, rather than users having to create static rulesets for where data flows and the actions/people associated with these flows, the system can track the actual workflows where people submit emails to one another or include users in collaborative efforts. This is more dynamic and requires less static configuration which means it will scale better and require less administration.
The above exercises are just examples of how to think about cognition in your product. Ultimately you are trying to discover user scenarios where the system is supporting decision making or automating repetitive, time consuming tasks that cannot be achieved through heuristical methods.
What does your cognitive engineering lifecycle look like?
The software development lifecycle (SDLC) and application lifecycle management (ALM) are terms used to describe the development and deployment of engineering based features. With the exception of data stores, you applications should be stateless, so the process in which they get designed, developed, deployed and maintained is based on this premise.
Cognitive systems are very different in that the data processing and statefulness is inextricably linked to the “code”. The code in this case is a pipeline of feature engineering, model training, model performance evaluation, and runtime processing capabilities. Then there is the model artifacts, which are separate to the raw data they are built from.
As such, you need to think about your cognitive engineering lifecycle, both in terms of development and deployment. This gives rise to the concept of “cogops“, the method by which business analysts, data scientists, software engineers, and operations teams manage a cognitive feature throughout it’s lifecycle.
At a high level you need to be thinking about:
- How do I integrate business domain experts, data scientists, and engineers using tools and automation to ship end to end features.
- How do you test locally and deploy into upstream environments with only env configuration changes.
- How will you assess the performance of new model versions and automate the process for upgrading these models in upstream environments.
- How will new data enter the lifecycle, be used to retrain or extend existing models, and how will these new signals be consumed.
While there are many aspects of engineering devops such as monitoring and alerts that apply to cognitive features, there are new processes such as training and performance evaluation which are new.
It’s important to start thinking about your cognitive investments as highly integrated pieces of your architecture and not as offline silos. It’s one thing to run an R report and sneakernet that to the appropriate stakeholders for evaluation, and another thing to mainline these capabilities into your development processes and your apps.
When it comes to making long term decisions, I like to collect a variety of data across a meaningful period of time. Why? Between two entities in a relationship, you are almost always going to see variables change over time. So when it comes to recruiting, retaining and developing engineering talent, observing someone over the course of an 8 hour interview loop gives you a contracted period of time with limited variables from which to draw conclusions and make predictions about the long term arc of you and them. Add to this the unique nature of AI engineers, and you’re going to need a new playbook to guide you in building a world class data science team.
Before I dig into the playbook, let’s talk about the archetypes at play. There are three distinct types of data science engineer:
This fresh grad has more course credits in AI/ML than Prof. Ng could teach and has just put the finishing touches on their thesis solving Falconer’s conjecture written in pure R. They are light on software carpentry skills and the only tests they have ever written were as a TA in college.
This up and comer has been on the line for years, mastered no less than 3 languages including one named after facial hair and uses painfully esoteric IDE’s that border on ASCII art. They’re “self-taught”, meaning they’ve read every README.md on Github that mentioned AI/ML and can wax lyrical with utmost conviction on why Deep Learning beats the stuffing out of SVMs without personally having ever used either.
Wha? Machine learning? Artificial Intelligence? Who? Speak into the good ear!!
Who’s the best type to build a team with? Well, you kind of need elements of all three. I’ve built AI/ML teams for the past 5 years and while the methods for recruitment and selection have changed, the personalities are almost always the same. You need someone who has a reasonable grasp for what’s happening under the covers, otherwise they’re going to shy away from the complexity and end up practicing coincidental coding rather than making rational informed design decisions. They also need to have a hackers spirit. Engineering AI features is heavily iterative and takes the patience of a saint, so if they’re not capable of working in ambiguous environments they will burn out. And lastly, they need have a healthy level of scepticism regarding the overall field. Machine Learning was born out of a schism between AI purists and those who had to work for a living, and as AI has taken the brand forefront once again, there is a daily deluge of information on AI and ML. If you don’t have good bullshit filters, you’re going to spend a lot of time moving your eyes left to right instead of your fingers up and down.
Make it interesting, make it relevant, make it honest. Omit words like “rockstar”, “ninja”, “guru”, and replace these with actual frameworks and platforms you are using or intend to use. Discuss the expectations of the role within the framework of:
- Feature engineering – Where does the data come from, how much work is required to get it into a quality standard for training models?
- Model selection and training – How are you expected to develop hunches? What are you expected to deliver and in what time frame? When is done, done?
- Model maintenance and troubleshooting – What does care and feeding look like? Is this mission critical or best efforts?
The JD is crucial to inviting the right candidate into the funnel while ensuring the looky-loos and tire kickers don’t clog your pipes.
The Coding Exercise
If you’re like me, when you interview someone for a role on your team, you’re thinking long term, or at least you should be. So back to the 8 hour interview. I worked with my last AI/ML hire for around 6 months, but my longest relationship has been over 5 years. So let’s say for me x is somewhere around 960 < x < 9600. So at a min of 960 hours of engineering time spent, I have 8 hours of data to set up my vector. At 9600 it gets worse.
Also the one thing I’ve always hated about the 8 hour interview, is as engineers, we spend so much time in code, alone, together, in the SO hive mind. So pulling someone in for a series of cold start coding sessions is down right bizarre, and frankly, feels like the kind of interview process a non-engineer would come up with (stares directly at IBM middle management). So I like to put together a comprehensive coding exercise which touches the major elements of the job description including any engineering and infrastructure pieces required to be successful in the job. I like to give that to a candidate on a Friday evening and expect it back before work starts Monday morning. The process is very straight forward:
- Clone an assignment repo – This contains a seed project in a monolithic form with all the major project folders in place with a detailed README.md regarding what is expected and any data required to perform the task. For example, it might be some product data in a json file where the task is to create an API to expose an endpoint where incoming product descriptions are matched with similar product descriptions from the json file and delivered through the API.
- Encourage frequent and small commits – As the candidate is making progress, encourage them to make commits with decent commit messages. This is great to provide insight into their reasoning and thought process, and also gives the interviewing team concrete places to discuss code with the candidate should they make it to the next stage.
- Use the SCCS to collaborate and discuss – Github and Bitbucket both have great PR and comment capabilities. Leave comments, ask questions of the candidate, leave notes to your team mates. All of this provides a great place to have a code conversation with your candidate within a meaningful context.
Come Monday morning, you’re going to have a great insight into your candidate, and they’re going to have a realistic sense for the job they’re applying for.
The Follow Up
Don’t tell me you thought there wasn’t an 8 hour interview? Of course there is, it just isn’t a random expression of technical strength designed to make your candidates feel like dousing themselves with petrol. Instead, it’s a joyous confluence of engineering expression facilitated through code. Code that the candidate wrote, that your team is familiar with, and actually relates to the job they’re applying for. During this time you can dig into their reasoning, design decisions, but also provide positive feedback, let them know if they did something exceptional or delightfully unexpected.
A Data Scientist is not just for Christmas
So you’ve vetted 90+ candidates over the last 3 months and are ready to offer 1 a job. They accept and you’re in AI/ML engineering nirvana. Now what?
Don’t drop the ball. It’s really that simple. The best AI/ML teams recognize that it’s not an exact science or an engineering discipline, it’s a bit of both with magic in the middle. So always make sure your checkpointing your processes, reviewing your practices, and tracking against your high standard. By keeping the tempo similar to the interview process, learning new methods, exploring innovative technologies, solving unique problems, recognizing great work, you’ll not only build a great team, you’ll keep it.
And if you have any questions on how all this works in the wild, drop me a line.
2010 was my first experience with AI in the form of an NLP project at Microsoft. The toolchain, framework and overall process was rudimentary and did not lend itself to rapid iteration or follow any particular engineering workflow. Like most AI projects, the goal is to get to a minimum viable model (MVM), so it’s understandable that automation and tools are deferred until the basics of feature and model selection are complete.
Like most feature engineering scenarios however, deferring these concerns actually retards the iterative process, with engineers spending more time performing scaffolding tasks than data science tasks. This also speaks to the difference in building AI features versus non-AI features. With non-AI features, it’s more crucial to “true up” your stack during development to accelerate iteration, however AI features require a more exploratory approach, where feature engineering and model selection are more valuable than truing up the application during each change.
So how do you set yourself up to engineer AI features like a pro? Easy!
To build AI features quickly with confidence, especially in a team setting, you need to have a deterministic environment that must span development and production. Whether you’re trying to freeze framework versions or easily share experiments, reducing the barriers and friction for other engineers and environments to spin up an AI feature is crucial.
Docker has a number of benefits for AI engineering teams:
- Sharing environments between engineers
- Rapid framework evaluation
- Deterministic deployments through environments
The feature engineering lifecycle for AI features is bifurcated between design and maintenance. During the design phase, the ability to tinker, hack and visualize is critical, and there is no better environment than Jupyter for that.
The best way to think of Jupyter is an online document editor where paragraphs can be code that is executed by an interpreter. Out of the box, Jupyter supports Python, which is perfect for AI engineering given the extensive support provided by libraries like scikit-learn and TensorFlow.
For example, before creating my Git repos, scaffolding an app, building unit tests, etc., it’s much easier and useful to simply start exploring the AI problem. Let’s take the very useful task of calculating the similarity of text, say for example, if you’re doing a deduplication activity. With Jupyter, you create a new notebook, start hacking and iterating, without the need to actually spin up a program.
The great thing about Jupyter is not only does it support Python, it also supports other languages like Golang and Bash! This means you can iterate independently of the dev process until you’ve fleshed out your concept and then simply migrate the working code to an IDE via ctrl-c-v or using Jupyter’s export capabilities.
Oh, and Docker + Jupyter means you can get started with the leading data science stacks like scikit-learn, TensorFlow, Spark and R. This is a huge boost as it means you can start exploring and vetting these AI frameworks and platforms without having to waste time setting them up.
Yes! Jenkins! Now, I’m always in danger of being called out for using Jenkins for just about everything, but let’s face it, when it comes to doing stuff when stuff changes, Jenkins is awesome.
So how do you leverage Jenkins as part of your AI feature workflow. After you’ve moved your feature from iteration to mainstream development, you must monitor the performance of your feature. Now, like the rest of your stack, AI features have specific attributes that must be measured before you deploy them. For example, you might have a classifier that is being trained nightly by a content team. Jenkins is great because you can have Jenkins run a job which prepares a confusion matrix against the latest model checked into source control and if the accuracy is less than the currently deployed version, simply withhold it from deployment, conversely, if the accuracy is better, deploy it. This is a great example of using CI as part of your AI feature pipeline.
The key takeaway here is to stay lightweight and iterative during the design phase, then use proven automation platforms and techniques to ensure you manage the lifecycle of your AI features. Time spent on learning technologies like Docker and Jupyter will not only accelerate your AI feature development but make it easier to move them from development to production.