Search that works on your hardest documents. Designed, built, and proven.
I design and build retrieval systems for large, complex document collections, and the evaluation that proves they're right.
Prototyping with AI is exciting. We have all tried and seen how rewarding it can be. The harder part is knowing what is ready to ship, what is still fragile, and how to improve it without guessing.
For teams working with: scanned PDFs · complex tables · contracts · entity-heavy workflows · high-stakes document operations
My approach
- Define what "good" looks like for your use case
- Build extraction, normalization, and aggregation for unstructured documents
- Design retrieval that finds the right document and shows why it ranked there
- Prove it with benchmarks and error analysis
- Evaluation goes into the architecture from day one, so you know where to trust the output before you commit
What you leave with
-
A document pipeline that produces clean, searchable data
Ingestion, extraction, and normalization tuned to how your content behaves.
-
Hybrid retrieval engineered for your content
Retrieval built from the full toolbox: BM25 and embeddings, a document-as-graph layer, query-intent interpretation, and data modeling matched to your domain.
-
Provenance carried end to end
Every hit links back to the source document and passage it came from, through extraction and normalization, so any result can be checked at its origin.
-
A benchmark and error analysis your team can run
A benchmark on your real documents. Interpretable metrics. Error analysis that says where a failure comes from and what to change next in a change-test-compare cycle.
Recent work
Investment Data Extraction (VC Fund, 12+ months): Automated extraction that reduced a 19-person data operation to 5. Built multi-stage LLM architecture achieving 94% accuracy across 690 complex entities with zero hallucinations. System designed to report "not found" rather than invent answers.
RAG Evaluation Infrastructure (Enterprise Search): Built systematic measurement for an enterprise search assistant. Replaced generic metrics with a calibrated LLM-as-a-judge framework and CI/CD regression testing.
Medical Document Intelligence (Healthcare, working demonstrator): An OpenSearch-based search solution that turns unsorted patient documents (PDFs, scans, DOCX) into a structured, searchable per-patient index: physicians see cited hit lists, never generated answers.
-
We run a venture capital market database. We started with 19 people on data collection, management, and QA. Working with Halyna, we automated our core workflows and brought the team down to 5, with better quality and no speed bottleneck. She knows how to orchestrate agents, evaluate what they produce, and build the safeguards that make automation trustworthy.
About me
I'm Halyna. I've spent 17 years making search and extraction systems work on real documents. Long before LLMs, I was building information extraction pipelines for legal, HR, and government domains, learning what makes retrieval succeed or fail at a fundamental level.
I run LITAI LLC from the Raleigh-Durham area of North Carolina, on US Eastern time, and work with clients here and in Europe. I work in English, German, and Ukrainian.
How I think about search
- In regulated domains, the answer itself is not always the best possible output. Lawyers, doctors, and auditors need ranked, traceable evidence they can cite and check. That reframes the whole architecture. Read →
- The judge does not score. The judge diagnoses. Two competent LLM graders can disagree by 20+ points on the same answers. Layered evaluation gives retrieval, generation, and stability failures each their own verdict. Read →
- Entity types are a competing set. A schema with no
excluded_sectorsfield will file a fund's exclusions as investments, and no metric will show it. Read →
Questions, or want to see if it's a fit?
LITAI LLC · Raleigh-Durham, North Carolina · US Eastern time