What I learned implementing an "AI" system in 1995
Portable AI lessons learned while implementing machine translation in 1990s Los Angeles
Ah, 1995. Sure feels like a lifetime ago, but it wasn’t just a year that saw the release of many movies that are now considered classics but also an era that witnessed the arrival of several companies and technologies that still shape our world today.
There I was, a recent southern California transplant, blasting Oasis's "Wonderwall" while cruising down Sunset Boulevard in my ultra-cheap Hyundai Excel (manual transmission!), pairing "Die Hard with a Vengeance,” "Braveheart," and "Toy Story” with large buckets of extra butter popcorn at the AMC on Santa Monica’s Third Street Promenade (still a bit sketchy back then) and enjoying my enviably short commute from my home in West LA to the office a few blocks away.
Meanwhile, the digital world was beginning to take shape. Netscape Navigator and Internet Explorer were among the first browsers to bring the Internet to the masses. Jeff Bezos launched Amazon, laying the groundwork for a future where anything could be bought online with just a few clicks. Not far behind, Pierre Omidyar created eBay, lowering the barrier of entry for e-commerce from “formidable” to “practically zero.” It was a time of innovation and disruption, a precursor to the digital world we inhabit today.
At the time, I was part of a small team of machine translation early adopters at a forward-thinking software localization and translation outfit in Los Angeles. In addition to our regular responsibilities - like translating hefty manuals of such classics as Macromedia’s Extreme 3D - we had gotten the green light to implement an early machine translation system called Logos on a Sparc system to see if this basic version of AI could become a viable tool in addition to existing translation memory systems.
Early results were promising, but as with any pioneering endeavor, we faced numerous challenges and learned quite a few valuable lessons along the way.
Lessons Learned from the 1990s AI Front Lines
1. Integrating New AI Capabilities into Existing Workflows is Hard
One of the first hurdles we encountered was the tactical integration of the new AI capabilities into the existing workflows of editors and proofreaders. This involved several key concerns:
Truth in Labeling: What should we call the output of a machine translation system? First draft? First machine draft? Edit ready? Proofread ready? With the implied quality level of the respective categories, would editors be tempted to perform major text surgery or would they blindly trust the output and become sloppy, overlooking potentially serious flaws? Then as now, the output was often fluent, sometimes clumsy, but passable, and not always accurate.
Work flows through Workflows: Regardless of output labels, the overall workflow would also need to be revisited.
The machine translation system needed pre-processing that was not required for human translators: one of the steps involved “protecting” named entities like Windows or Extreme 3D that the Logos system should not translate into the target language.
To give you a bit of an idea of how long ago this was, let me just mention that we used the “@” sign as the delimiter character to flag named entities turning Windows into @Windows@. The @ sign just wasn’t used for anything else!
After machine translation, we then needed to decide whether a full edit and proofreading pass was necessary or if we could get away with just a single edit pass.
2. New Technical Capabilities May Change Your Business Model
The introduction of machine translation posed significant questions about our existing business model. Traditional translation is often billed by the word, a model that makes sense when human translators are the primary labor force. But what happens when a machine can translate text 50 times faster than a human? We’d go from an output of 2,000 words/day/translator to 100,000 words/day/machine, although that output may then have needed more rigorous editing, but less proofreading time.
This acceleration forced us to potentially reconsider our pricing structures. Should we continue to charge by the word, or should we adopt a new model that reflected the value and efficiency provided by the machine translation system? We needed to find a balance that acknowledged the speed of AI while still valuing the expertise of human oversight and also recognized the need for sometimes costly “clean up” when the raw machine translation output was comically inept.
3. Not Just Features and Functions, but Feelings
A significant concern that needed to be addressed early on was the question of whether or not machine translation was designed to “replace” human translators. Understandably, some professionals worried that their skills and livelihoods were at risk with the advent of machines that could crank out translations 50 times faster than humans. Even though our small prototype covering only limited language combinations wasn’t going to deliver anything resembling a viable alternative to the existing team of seasoned language professionals, we made sure to position machine translation as a tool to augment humans. A tool that was especially good at plowing through boring, uninspired, repetitive tasks such as translating bone-dry instructions like “Select Open from the File menu. Then specify the dimensions of the canvas…”. This would free up human translators to focus on the juiciest, most challenging, and most creative bits of the work.
Sound familiar?
By emphasizing the collaborative nature of this new technology (“through and with, not instead”), we aimed to alleviate concerns and highlight the enhanced value that human translators would bring to the process.
Moving Forward
Reflecting on those early days of machine translation, it's clear that the challenges we faced are not unlike those encountered with today's advanced AI systems. Proper integration into existing workflows, careful evaluation of potential impacts on business models, and establishment of trust through proper positioning continue to be critical whether you are dealing with proto-machine translation systems or sophisticated LLMs.
Our journey in 1995 was about much more than just implementing new technology; it was about fostering collaboration between humans and machines, providing holistic framing of technical and non-technical needs and outcomes, and - ultimately - showing respect for all involved.
I’d love to hear your thoughts on the above and feedback on lessons learned from your own time in the AI trenches!
I just found your article, great breakdown. its a brutal problem getting from concept workflow to real world business or industrial workflow.
My story on a mid-90s ML journey was just as haphazard as yours :)
I'm from LA (nice pic of Santa Monica early Promenade:) & grew-up thru college and left in 1990 (went in the US Army) & when I got out in 1995 was in Boston at the beginning of the new wave of computing (client/server, ML, internet, C++, powerful UNIX & Win NT workstations/servers etc..)
I studied CS/MIS/Engineering undergrad but my real learning was in a awesome/weird program course I took on the side while in the Army, it was 75% paid for by the US Army .. It took me 4yrs to actually complete it but was worth it as I grinded thru it.
NRI School of Computing --https://www.ebay.com/itm/402347864977
(which was a weird correspondence program of 140 booklets & building 2 x SCO Unix PCs while learning Hardware, Networking, Device Drivers, SCO Unix, C, C++, Structured Programming, QBase, SQL Gutpa, DB Connectors etc.. kinda wild)
I had to actually read like 10 CS books to help me thru it and the combined learning was what really made me a UNIX/C/Oracle systems person..
this program really took me down the hardcore path of client/server without realizing it.
When I left active duty Army I was in Boston and started in QA/QC in 1995 at a ML start-up called Unica Technologies that was later sold in late 2000s to IBM..
We had these 8 x monster MIT BS/MS Lincoln Labs engineers that were building a Unix & PC based workstation (remember those:) application..
It was designed around a concept called the "Pattern Recognition Workbench" PRW..
PRW was a analytic application with a massive spreadsheet 16k columns & 16m rows
It could load all in RAM and allow the performance to optimize from cache in large UNIX workstations or small servers.
PRW had Data/file mapping utilities, 100+ stats testing tools, tons of QA/QC tools for data quality
They built a dozen non-parametric algos with 20 or so parametric algos and integrations (old school flat file & point to point, ODBC) into SPSS/SAS/MatLab/Mathematica to mix ML/Stats/Maths etc..
we sold this to big retail, banks, industrial, healthcare
then the fun began.. all that awesome ML/Stats/Math tech hit the wall of how do I make this work in real daily workflow of business processes, industrial apps
I remember our struggle to build dozens of extra modules around PRW to match the actual customer business needs of the processes, workflows steps, back and forth with MS Excel or RDBMSs, MRPs, ERPs, real world mission critical apps in the business that you could not blow away.
this was brutal, we sold and implemented to dozens of customers but was very difficult. Later after I I left Unica pivoted to Marketing Automation and exploded with 1000s of customers and sold itself to IBM in 2009
I left after 2yrs(learned a ton I still use in engineering thinking) and went to PeopleSoft (ERP:) and had a great career in enterprise tech the following 25yrs and have come back into the ML space again and have seen nothing has changed except the founders are just that much more cult like in their one way belief in being right :)
thank you for the article..
Aaron