top of page

Why Subject Matter Expertise Is the Missing Link in AI Development

Writer: Colin LevyColin Levy

Successful AI Tech Requires Subject Matter Expertise

To develop truly useful AI software, you must involve a subject matter expert (SME) in its development.  It is not enough to be a brilliant software engineer or even have a brilliant idea.  A SME makes sure the nuanced needs of the market are addressed, not just the big-picture idea.  This SME could be someone with deep knowledge of the problem, or someone with specific training, like in medicine or law. 


Most successful new companies develop around a specific need that the founders recognize exists in their own lives.  They recognize this need exists because they experience considerable pain with whatever they are doing that it impacts.  They see all the ways the thing causes them pain and they see a clear path to resolving it.  They are subject matter experts with that pain point and know how to solve it.  If they also see it affecting a lot of other people and can solve the pain for them too, then we say they have product-market fit.


AI software development is no different.  However, AI can lure founders into a false sense of security with product development.  AI is so smart and so good at solving many problems, that it is easy to think that a founder can build a business in any industry without being or including a SME. 


AI is great at topical problems but is not good at solving minute problems without the right context and content that a SME knows.  Without being aware of these needs and risks, ventures will eventually fail, prolonged by AI giving the founder just enough help to be useful but not enough to solve all the parts of the problem.


Average Will Not Yield Long Term Success

In building great AI software, two types of subject matter experts are needed.  The first SME is an expert in the underlying problem that the software will be solving.  The second is a SME in how AI functions so the output is most useful to the end user.


At this point in time, artificial intelligence is not actually intelligent.  It does not think or process thoughts the way humans do, even for the most technical or advanced PhD topics.  Instead, it predicts words based on other words.  It predicts what text you want to see in response to a question, through reviewing troves and troves of similar writings from the past (or understanding the rules, like in coding).  As someone with a background in economics, I like to conceptualize AI as a very advanced form of regression analysis.


AI is getting better at answering very complex problems in highly technical fields as it is fed more and more text to read.  The more text it has to read in highly advanced fields, then the better it can predict answers in those fields.  Certain programming shortcuts can make providing these answers fast, like chunking out aspects of its database by topic.  However, AI is ultimately still performing predictive word creation.  You still need to ask it a question in order to get an answer.


To become good at answering questions, AI must know the context of your question and have some degree of content to best answer your question.  The example I like to use is asking AI what the best type of grass is.  The word “grass” provides AI some content to work with, but not enough context to be useful.  It does not know if you are talking about grass for a lawn, a golf course, or to stop beach erosion.  It does not know whether this is for a location in the sun, shade, Florida, Ohio, or Alaska.  It doesn’t even know if you are talking about grass that grows in the ground or the type that you smoke. 


You can probably now see how software development using AI runs into the same types of problems.  AI needs highly developed context and content to be most useful.  Building something that solves a general problem for an industry is much different than building something that solves it a truly useful way.  Solving a general problem gets some growth, but deeply solving a problem gets you traction.


In LegalTech, one example of companies running into the SME problem is software that provides for “medical timelines.”  This software is attempting to solve one problem that personal injury, medical malpractice, and insurance defense lawyers run into.  They need to quickly understand the facts surrounding some type of injury without spending hours on a case, especially to find out that is going nowhere.  If software can reduce a review of 2,000 medical records to 15 minutes to tell them whether there is a case (or defense) or not, then there is a significant time savings and efficiency available to this industry. 


A founder may have a fair amount of software experience or knowledge to get AI to review 2,000 documents instead of the few dozen or few hundred that public AI software can do effectively.  They may think that their knowledge of AI and software programming is sufficient to offer this type of product.  And they are probably right from a topical level.  They can probably offer this kind of product in a market without a dominant leader and find general interest to make a few dollars.


The issue for this type of company is that without a SME in personal injury claims, they will not understand what else an attorney in this field needs from this type of report for it to be most useful.  They will not know about finding all the medical providers’ information for witness disclosures, identifying every charge in the file for damages, or how references to preexisting injuries can impact liability.  Thus, they may be able to produce an average report that gives a chronological list of events.  However, they will eventually be beat by a competitor with a SME who understands the deeper pain points and needs of the user and can provide more useful output to them.


Using the term “average” is an accurate way to describe the results you can expect from AI without involving a SME.  Think about it this way: if you uploaded 100,000 contracts into AI and asked it to tell you about the agreements, what is it going to give you in response?  It is going to tell you the commonly occurring themes or clauses within those contracts.  On the bell-curve, you are going to get the data that occurs on the steepest part of the middle part of the bell curve.  You will have a small percentage of contracts that are terrible and a small percentage that are excellent.  Everything else will be in the middle.  That middle section is what you are going to get from AI.  That is also where the average lives.

The problem with the average is that it is average.  It’s not the best (or the worst).  If you are not an expert in contracts, you are not going to know what the best provisions look like and therefore are not going to be able to deliver the best results to your users.  Instead of giving your customer the best results, you will instead rely on the average. 


Average results in a new industry are fine for a little while, but what client wants a company to consistently produce average? Again, you can see what will happen when a SME enters the market and begins to deliver best-in-class results.  The average provider’s short-term success will give way to SMEs who know what the most useful output is for their users.


How to Develop the Most Useful AI Software

The best companies solve a problem.  It is the same for AI companies.  The best way to approach software development is to solve a problem that provides your users the best output.  What that means for us at AI.Law is that we start with the end product. 


When we wanted to draft a lawsuit with AI, we started with a fully drafted, multi-page, complex lawsuit that represented the best example of what a lawsuit looked like.  After years of litigating cases, we didn’t need to guess or even ask AI to figure this out.  We were able to sit down and map out the best of what we saw, pulling from prior examples, practical knowledge, and experience.


After determining what the best-in-class lawsuit would look like, we worked backwards to determine what information we would need from the user to create that document.  We weren’t interested in every single example over thousands of examples of lawsuits but instead focused on the information that would be needed to produce the best document for each case. 


We built the “lens” that AI would use to ensure that it had the right context and content to be able to draft the best lawsuit each time.  The lens included building clear rules that would apply universally in civil litigation.  Through trial and error and other proprietary efforts, we developed foundational rules that produced the best output for each case, no matter the state or cause of action.  This included developing new technology that helped AI focus how we needed it to.


Lastly, we experimented with LLMs to find the one that worked best with our lens to produce the best results possible.  We tested each, focused the lens more, and found that we liked a few LLMs each for different purposes.  We then put the software to use in real world practice and focused it some more.  I like to think that the end results are unmatched by any other litigation drafting software on the market.


Compare this process to one where someone walks into a big law firm and asks it to hand over terabytes of data to sift through to find “hidden golden nuggets” among all their files using AI.  Can you now see the problem with that?  AI is going to sift through all that data and the very thing that you would want AI to find (the needle in the haystack) is exactly what it would NOT find.  This is because by definition, that needle or golden nugget is an extreme outlier unlike anything else in the dataset.   This is exactly what AI will ignore as it provides you aggregate, mean, average data from the set. 


To make use of data found using this “nugget” method, your client is going to spend their time (and expertise) teaching AI what it considers best-in-class.  Eventually, that one client might end up with output that matches what your subject matter expert could have developed for them from the start.  But if a company forces every client to DIY AI training from scratch, expect longer-term success to come from those software developers that involve a subject matter expert from the beginning.


Troy Doucet is founder of AI.Law and has been a top-rated litigation lawyer for over a decade, with his firm handling over 2,200 matters.  AI.Law was developed with his experience to develop best-in-class litigation pleadings, discovery, and more.  The software also includes a medical timeline with robust features and functionalities.

bottom of page