Gary Lam is Toronto Site Lead and an Engineering Leader at Harvey. His engineering work connects machine-learning infrastructure with the document-processing and retrieval systems used in legal AI.[2][3]
Start with Scaling Document Processing Across the Harvey Platform →
Education
Links
Official current employer biography
X · lamgary Toronto Site Lead and Engineering Leader · Harvey
Career
Lam’s employer biography records graduation from Imperial College London and nine years at Twitter working on machine-learning infrastructure and ranking systems. He later developed platforms for Netflix’s personalization algorithms. At Harvey, he builds and leads teams responsible for scalable AI systems.[2]
Contributions
Give each processing stage its own failure boundary
His coauthored scaling article describes separating extraction, chunking, embedding, indexing and retrieval according to their bottlenecks. Durable workflow state lets work resume after a worker restart or deployment. Explicit timeouts and retries govern individual activities, while a corrupt or unsupported document can fail without restarting an entire batch. Queue isolation, task routing and regional workers make the processing path easier to observe and manage as document volume grows.[3]
Retrieve a page before interpreting its visual content
Lam’s image-understanding article, coauthored with Tom McCormick and Anna Zhang, explains why extracted text can lose the meaning of a chart, diagram or complex layout. Instead of describing every image during indexing, the agent invokes an image-analysis tool when the question needs it. It can search for the relevant part of a large document and inspect the page with the question’s context available. This preserves visual information while avoiding unnecessary analysis of unrelated images.[4]
Tools, writing & talks
Writing, research & talks
Start here
A team account of durable workflows, stage-specific bottlenecks and file-level failure isolation in a large ingestion system.
Follow one document through extraction, indexing and retrieval, noting where a retry can resume and where a single-file error is isolated. Experience with background jobs helps connect the design to its reliability tradeoffs.
Coauthor with the Harvey engineering team[3]Author: Tom McCormick, Jin Zhang, Shunrang Cao, Jinfeng Zhuang, Anna Zhang, Adam Shen, Gary Lam At Harvey, document processing sits underneath Vault, Assistant, and every workflow that interacts with a customer's own data. Unlike many other AI products, almost every query from a lawyer involves documents. These queries often range from a single file to hundreds or thousands of documents at once. Contracts, closing binders, deposition transcripts, email archives, scanned PDFs, and entire data-room exports all pass through the same path: fetch the file, extract the content, split it into useful pieces, and make it searchable. A year ago, that platform handled just under one million documents in a busy week. Users rarely think about document processing when it is working. Over the last 12 months, our work has been focused on keeping it that way while weekly volume moved from hundreds of thousands of documents to tens of millions. The main lesson was simple: At this scale, document processing stops being one pipeline and starts behaving like several different systems. Extraction, chunking, embedding, indexing, storage, and retrieval all break in different ways. We had to split the work along those lines. Below, we share a look into some of the work we did to stay reliable and low latency while scaling incredibly fast, plus a glimpse into the future and some of what we have planned for growth. A Look at the Growth Measured by completed-processing time across customer workspaces, the scale curve looked roughly like this: At current scale, full weeks are regularly in the tens of millions of documents. The latest complete week in the measurement window averaged about 3.5 million documents per day. Compared with a year ago, that is 26x more documents and 39x more data. Caption: Rounded quarterly snapshots. Raw weekly data has normal operational and holiday volatility; this view emphasizes the underlying scale curve. What Drove the Growth The growth in volume came from a
Catalog workOriginal sourceAn explanation of on-demand visual analysis during retrieval rather than image descriptions generated in advance.
Coauthor with Tom McCormick and Anna Zhang[4]