New opportunity

AI Researcher: Reasoning & Retrieval

Auric AI · Bengaluru/Mumbai, India

About this role

Auric AI is hiring a research engineer to develop a reasoning system over millions of messy, multilingual intelligence documents. The system must run entirely inside India on controlled, air-gapped infrastructure using self-hosted open-weight models. Fine-tuning and external APIs are not part of the approach; performance must come from system architecture.

Responsibilities

Develop retrieval that can identify gaps in its results and assess what it may have missed, rather than returning confident answers from incomplete evidence.
Design multi-hop reasoning that decomposes questions, retrieves across sources and surfaces contradictions instead of concealing them.
Propagate uncertainty through chains of inference when evidence differs in reliability or precision.
Explore how to externalise, compress and reconstruct information for investigations lasting days and involving hundreds of tool calls—beyond a model’s context window.
Build architectures that people can interrogate and measure their performance honestly against messy, schema-free documents spanning decades, multiple languages and inconsistent entity names.

Qualifications

The posting lists 0–10 years of experience and states that there is no experience or degree requirement. Candidates should understand language models and retrieval mechanically, explain why naive RAG fails on multi-hop temporal questions, and have built something that worked with real, messy data. A publication record or an independent repository is valued as evidence of ability, but neither is required. This is not a prompt-template, API-integration, backend, UI or labelled-data fine-tuning role.

The position is onsite in Bengaluru or Mumbai. To apply, send a resume and up to two pages describing a challenging retrieval or reasoning system you would build, what you would build first, what you expect to break and how you would measure whether your approach is wrong.

For full details about this role, click “Apply on company site” to view the employer’s original posting.

Skills for this role

Retrieval-augmented generation (RAG)Information retrievalLanguage modelsMulti-hop reasoningUncertainty propagationMultilingual information retrievalResearch evaluationSystems architectureOpen-weight modelsEvidence synthesis

Checking your profile…

Preparation suggestions, not the employer’s actual interview questions. Always check the original posting for current requirements.

Understand the role

What matters most

Detect retrieval gaps
The role calls for retrieval that can assess what it may have missed, rather than give a confident answer from incomplete evidence. Prepare to explain how a system could test coverage and signal unresolved gaps.
Reason across sources without hiding disagreement
Questions require decomposition, multiple retrieval steps and synthesis across sources. The posting explicitly prioritizes surfacing contradictions, including in multi-hop temporal questions.
Preserve uncertainty through inference
Evidence differs in reliability and precision, so confidence must remain explicit across several reasoning steps. A falsely confident answer is described as worse than no answer.
Sustain investigations beyond the context window
Investigations may last days and involve hundreds of tool calls. The role explores what to externalize, compress and reconstruct so earlier evidence remains usable.
Build inspectable architecture and honest evaluation
The system must be interrogable by people and measured against messy documents. Performance must come from architecture using self-hosted open-weight models, without fine-tuning or external APIs.

Likely challenges to think through

Finding the same entity across inconsistent records
Preparation hypothesis: multilingual documents spanning decades, with no schema and variant names, make it difficult to link evidence without merging distinct entities. Prepare to discuss conservative linking, traceable source references and tests for both missed and false matches.
Balancing search breadth against practical limits
Preparation hypothesis: searching more broadly may expose missing evidence but increase cost and irrelevant results on controlled, air-gapped infrastructure. Prepare to compare staged retrieval approaches and define when the system should keep searching or report an unresolved gap.
Compressing history without erasing a contradiction
Preparation hypothesis: summaries can make long investigations manageable while losing provenance, time qualifiers or dissenting evidence. Prepare to describe a reconstructable investigation record and tests that check whether later reasoning retains those distinctions.
Measuring errors when the answer set is incomplete
Preparation hypothesis: on messy, schema-free documents, a plausible answer may conceal missed sources, making ordinary answer accuracy insufficient. Prepare to propose separate checks for retrieval coverage, evidence support, contradiction handling and uncertainty, including what result would disprove the approach.

Practice your answers

Technical practice

Why does naive RAG fail on multi-hop temporal questions?

What to coverThe posting specifically asks for a mechanical explanation. Suggested answer focus: how retrieving individually relevant passages can miss intermediate links, changes over time, or conflicting evidence, and how decomposition and source-grounded synthesis might address those failures.

How would you detect gaps in retrieval results?

What to coverThe role calls for retrieval that assesses what it may have missed; whether recall can be bounded remains an open problem. Suggested answer focus: ways to probe uncovered entities, time periods, languages or reasoning hops, while stating what those checks cannot establish.

How would you decompose and investigate a multi-hop question?

What to coverThe posting describes questions requiring retrieval across several sources. Suggested answer focus: defining intermediate questions, tracking which claims depend on which retrieved evidence, and revisiting a hop when its support is missing.

How should a system handle disagreeing sources?

What to coverThe stated aim is to surface contradictions rather than average them away. Suggested answer focus: preserving each source's claim and provenance, distinguishing genuine disagreement from differences in date or precision, and indicating when the conflict remains unresolved.

How would you propagate uncertainty through an inference chain?

What to coverThe posting notes that evidence varies in reliability and precision across several steps. Suggested answer focus: representing uncertainty at each claim and dependency, avoiding false confidence from repeated or correlated evidence, and identifying when the system should withhold a conclusion.

What should persist beyond a model's context window?

What to coverThe role explicitly addresses investigations lasting days and hundreds of tool calls. Suggested answer focus: what to externalise, compress and reconstruct, and how to check that summaries have not lost qualifications, contradictions or links back to sources.

How would you retrieve across inconsistent names and languages?

What to coverThe source describes decades of schema-free documents in a dozen languages, with multiple names for the same entity. Suggested answer focus: candidate matching and disambiguation approaches, plus the trade-off between finding more relevant material and merging distinct entities incorrectly.

How would you make an answer interrogable?

What to coverThe posting rules out an opaque system for people accountable for decisions. Suggested answer focus: an inspectable trail from question to retrieved passages, intermediate claims and unresolved gaps, including how a person could challenge a conclusion.

What architecture would you build first under the deployment constraints?

What to coverThe stated constraints are self-hosted open-weight models, controlled air-gapped infrastructure in India, and no fine-tuning or external APIs. Suggested answer focus: a small end-to-end retrieval-and-reasoning design that can be measured, with architectural trade-offs rather than model-training assumptions.

What measurements would show the system is wrong?

What to coverThe posting asks for honest measurement against messy documents and, in its application prompt, for a result that would falsify an approach. Suggested answer focus: testing missing evidence, unsupported claims, temporal mistakes and hidden contradictions separately, including cases where the system ought to express uncertainty.

Behavioural practice

Tell me about working with messy real-world data

What to coverThe posting values work that survived messy data. Suggested practice: give a real situation, the data issue you encountered, the actions you took to test or adapt your approach, and the observed result.

Describe tackling an open problem without a playbook

What to coverThe role calls for deriving an architecture where no standard approach exists. Suggested practice: explain the situation, how you chose a first buildable step, what you did when assumptions failed, and what resulted.

When did measurement change your view of an approach?

What to coverThe posting emphasises measuring a system honestly and recognising when an approach is wrong. Suggested practice: describe the initial hypothesis, the evidence that challenged it, your action and the outcome without overstating success.

How have you kept complex work traceable over time?

What to coverThe stated work includes investigations spanning days and many tool calls. Suggested practice: if you have a relevant example, describe the situation, how you preserved decisions and evidence, and whether that helped you resume or verify the work.

Tell me about communicating an uncertain conclusion

What to coverThe posting stresses surfacing contradictions and avoiding false confidence for people making decisions. Suggested practice: recount a real situation, what uncertainty you communicated and why, how you presented the supporting evidence, and the result.

Sharpen your knowledge

Topics to prepare

Retrieval mechanics and missing evidence
The posting asks for mechanical understanding of retrieval and ways to assess what results may have missed. To revise, explain how document segmentation and ranking can omit a decisive passage, then propose a way to test for that omission without claiming recall is known.
Multi-hop temporal reasoning
The posting explicitly asks why naive RAG fails on multi-hop temporal questions. To revise, draw a question whose answer depends on two dated documents; identify the intermediate lookup, a possible date mismatch, and why a single retrieval could give the wrong answer.
Conflicting evidence and uncertainty
The role calls for surfacing contradictions and propagating confidence through inference. To revise, compare two sources with different reliability and date precision, and explain when a conclusion should remain disputed or unanswered.
Long-investigation memory
The posting describes investigations lasting days and hundreds of tool calls, beyond a model's context window. To revise, sketch what should be retained outside context, what could be compressed, and what must be recoverable with its source.
Messy multilingual document retrieval
The stated data spans decades, multiple languages, no schema, and inconsistent entity names. To revise, trace how variant names and dates could fragment evidence across documents, and explain how you would check whether two mentions refer to the same entity.
Interrogable architecture and honest measurement
The posting says people must be able to interrogate the system and that its performance must be measured honestly. To revise, outline what evidence trail an answer needs, then name a failure measure that could disprove an apparent improvement.

Skills to revise

Build and probe a retrieval baseline
Suggested practice: assemble a small set of messy documents, write questions with known supporting passages, run a simple retrieval baseline, and inspect relevant passages it misses. This exercises the posting's focus on retrieval gaps; the baseline exercise is a preparation suggestion, not a specified employer task.
Trace a multi-source answer
Suggested practice: decompose a temporal question into lookups, record the passage supporting each step, and present disagreements beside the final answer rather than resolving them silently. This mirrors the stated need for multi-hop synthesis with visible contradictions.
Maintain a reconstructable investigation record
Suggested practice: keep a compact record of findings, unresolved questions, source references, and discarded leads; pause and reconstruct the reasoning from that record. This tests the posting's externalisation and reconstruction problem without treating any particular storage design as required.
Design a falsifiable system proposal
Suggested practice: draft the up-to-two-page proposal requested in the posting: describe a challenging retrieval or reasoning system, the first build, expected breakages, and measurements that would show the approach is wrong. Include how a reviewer could inspect the supporting evidence.

Your preparation checklist

Prepare a messy-data project walkthrough
Choose a system you built, if available, and document its data, architecture, failures and measurements. The posting asks for evidence of work that survived real, messy data; a publication or repository is valued but not required.
Explain where naive RAG fails
Prepare a worked multi-hop temporal question showing how missed documents, changing entity names or conflicting dates can produce a confident but incomplete answer. Explain the retrieval and model mechanics, not just prompt choices.
Sketch a retrieval architecture
As a design exercise, draw how you would search schema-free, multilingual documents, handle entity variants and check for missing evidence. Label any proposed recall estimate as an approach to test, not a solved capability.
Trace a reasoning chain
Prepare one example that decomposes a question, retrieves across sources and preserves contradictions. Show how evidence reliability and precision affect each inference and when the system should withhold an answer.
Design investigation memory
Sketch what an investigation lasting days and hundreds of tool calls would externalise, compress and reconstruct. Show how a reviewer could recover the supporting documents and inspect consequential decisions.
Define tests that could disprove the design
Propose a small evaluation with messy, multilingual or time-dependent cases; record missed evidence, incorrect links, hidden contradictions and overconfident answers. State what result would make you revise the architecture.
Draft the requested application materials
Prepare a resume and no more than two pages on a challenging retrieval or reasoning system in any domain: what to build first, what may break and what measurement would show the approach is wrong. Keep the proposal within the stated self-hosted, air-gapped, no-fine-tuning constraints.
Prepare questions for Auric AI
Ask how the team would evaluate missed evidence and uncertain answers, what document access is available for testing, and how investigators need to interrogate results. These are questions to clarify, not assumptions about existing processes.

Availability last checked: 4 Nov 2026. Status can change after a check; confirm on the employer’s website. Report an issue · Our checking policy

KEEP EXPLORING

Similar AI jobs

Related skills and specializations in India. Matched to this role, not your profile.

Explore more jobs

Finding similar opportunities…