Вопросы на собеседовании: AI-инженер

Я бы разделил асинхронный ingestion и retrieval-generation path с явными бюджетами latency, recall и tokens.

• Versioned workers парсят, chunk, embed и публикуют полные document generations, поэтому ingestion bursts не входят в query path.
• Hybrid retrieval возвращает около 100 candidates, reranker сокращает до 12, а context packing укладывает cited evidence примерно в 8 000 tokens.
• 150 мс отводится retrieval, 250 мс reranking, остальное model prefill и generation, затем load test идёт на 6 500 QPS с headroom 30%.

Я бы использовал structure-aware chunks примерно 400-700 tokens и расширял до parent section только при необходимости retrieval.

• Parser сохраняет headings, table rows, footnotes, page coordinates и source offsets вместо flatten PDF в plain text.
• Child chunks улучшают precise matching, а parent links добавляют surrounding section без повторного indexing множества overlapping copies.
• Chunk size и overlap перебираются по recall@20, citation accuracy, context tokens и answer quality на policy-specific queries.

Я бы сохранил first-stage recall через top-20 retrieval и использовал cross-encoder для концентрации relevance до context assembly.

• Дешёвый retrieval получает 50-100 lexical и dense candidates, если recall продолжает расти, а rerank обрабатывает только лучшие 20.
• Выбираются 5-10 diverse chunks внутри context budget с deduplication adjacent passages и cap на долю одного source.
• Widths настраиваются совместно по recall required evidence, nDCG, grounded answer rate, p95 reranker latency и token cost.

Я бы запустил BM25 и dense retrieval параллельно и объединил ranks до одного bounded reranking stage.

• BM25 находит rare identifiers и quoted text, а dense search семантически похожие формулировки из того же permission-filtered corpus.
• Reciprocal rank fusion не считает BM25 и cosine scores одной calibrated scale; каждая branch даёт 40-60 candidates.
• Lightweight reranker оценивает fused top 30, а branch deadlines и early fallback выбираются для retrieval p95 ниже 120 мс.

Я бы benchmark M и efSearch на реальных embedding и filter distributions, начиная примерно с M 32 и efSearch 100.

• Больший M улучшает graph connectivity и recall, но повышает index memory и build time для всех 50 млн vectors.
• Больший efSearch поднимает query-time recall, посещая больше nodes, но прямо повышает CPU work и tail latency.
• Я построю recall@10, p95, memory, build time и filtered-query behavior и выберу самый дешёвый point выше 95% recall и ниже 40 мс.

Я бы выбрал 768 dimensions, если gain 0,6 point не имеет измеримого end-task value.

• Float32 storage снижается примерно с 1,23 ТБ до 614 ГБ до graph и metadata overhead, также уменьшая memory bandwidth и replication cost.
• Обе dimensions сравниваются по recall@K, reranked quality, answer success, index build time и p95, а не только vector similarity.
• Если critical slice требует 1 536 dimensions, только этот corpus маршрутизируется отдельно или compressed вместо удвоения index каждого tenant.

Я бы маршрутизировал по tenant или tenant group, чтобы selective queries избегали global graph search и postfilter recall loss.

• Small tenants делят balanced partitions, а large или noisy tenants получают dedicated collections без смены logical retrieval API.
• Authorization и metadata constraints выполняются до candidate generation; overfetch с filter потом может вернуть меньше top-k authorized results.
• Измеряются shard skew, fan-out, recall, p95, rebalancing time и memory headroom до выбора partition counts.

Я бы сначала зарезервировал protected space и тратил remaining tokens на nonredundant evidence, не заполняя все 16 000.

• Около 1 500 tokens получает system и tool instructions, 2 500 output и 1 000 user query и conversation state.
• Оставшиеся 11 000 tokens содержат deduplicated passages по relevance, source diversity, contradiction coverage и citation boundaries.
• Per-source caps и deterministic truncation не дают одному long document удалить instructions или всё остальное evidence.

Я бы маршрутизировал только ambiguous или multi-hop queries через rewriting и сохранял original query независимой retrieval branch.

• Rewriter сохраняет names, numbers, negation, dates и authorization scope при resolution conversation references.
• Decomposition ограничена тремя subqueries, параллельными при независимости, с provenance каждого result к generated subquery.
• Нужен measurable recall или answer-quality gain выше добавленных model call, latency и semantic-drift rate на этом 20% slice.

Я бы тестировал graph expansion только на multi-entity slice и оставил lexical-vector RAG default.

• Entities и typed relations строятся с confidence и provenance, а вход в graph идёт от retrieved entities вместо traversal всего corpus.
• Expansion ограничивается двумя или тремя hops, а paths ранжируются по relation confidence, recency и query relevance до packing evidence.
• GraphRAG остаётся, только если task success на 30% slice оправдывает extraction errors, refresh cost, latency и extra storage.

Я бы протянул stable source spans через indexing, prompting и post-generation validation вместо reconstruction citations после ответа.

• Каждый chunk хранит source version, page, section, character offsets, checksum и local citation handle, доступный модели.
• Output schema связывает claims с citation handles; unknown handles отклоняются, а cited spans проверяются на lexical или entailment support.
• Trace хранит retrieved candidates, selected evidence, prompt и model versions и final claim-to-span map для audit.

Я бы enforce current authorization до retrieval и scope каждый downstream cache и trace тем же entitlement fingerprint.

• Search candidates создаются только внутри tenant и ACL filters от authoritative identity service, а не фильтруются после global top-k.
• Reranker inputs и prompts не получают unauthorized text, а cached answers включают principal scope, policy version и source generation в key.
• Revocation invalidates affected cache namespaces, а denial и cross-user tests доказывают, что TTL 15 минут не выдаёт old access.

Я бы обрабатывал ordered versioned changes через idempotent workers и показывал только complete document generations.

• Deterministic chunk IDs делают retries safe, stale events не перезаписывают новые source versions, а tombstones удаляют missing chunks.
• Queue age, source-to-search lag, failed embeddings и serving-version skew образуют freshness SLO пять минут.
• Embedding-model migrations используют shadow index и atomic alias switch, а periodic reconciliation исправляет missed changes и deletions.

Я бы benchmark multilingual embedding model и language-aware hybrid retrieval до поддержки трёх отдельных stacks.

• Relevance labels строятся по language, затем multilingual dense retrieval, translated queries и native BM25 tokenization сравниваются по recall@20 и nDCG.
• Original-language passages и citations сохраняются даже при translated query, а reranker проверяется для каждого language.
• Separate indexes оправданы, только если shared model не возвращает 12-point gap внутри latency и operating-cost limits.

Я бы создал modality-aware representations вместо принудительного paragraph chunking tables и code.

• Tables сохраняют headers, row groups, units и coordinates, с summaries для retrieval и exact cells для cited context.
• Code chunked по symbol и dependency boundaries с file path, signature, docstring и call relationships.
• Table и code slices оцениваются отдельно по evidence recall, executable correctness, citation accuracy, context tokens и latency до замены old index.

Я бы хранил authoritative conversation state вне prompt и собирал bounded working context для каждого turn.

• Всегда включаются current user intent, active constraints, recent turns и referenced tool results, а older turns становятся source-linked summaries.
• Facts вроде account state живут в typed storage и fetch fresh; model-generated summaries не считаются source of truth.
• Отслеживаются dropped-fact rate, summary faithfulness, context tokens, latency и resolution quality для short и long conversations.

Я бы сравнил retrieve-then-pack с full manual и, вероятно, выбрал RAG для routine queries.

• Long context помогает whole-document synthesis, но prefill 70 000 tokens повышает latency и cost и может страдать lost-in-the-middle.
• RAG получает current evidence per query, даёт exact citations и обновляет monthly manual без model deployment.
• Task success, citation support, p95 prefill и cost сравниваются на local fact, multi-section и global-summary query slices.

Я бы deploy один immutable manifest, связывающий каждый behavior-changing component, и rollback manifest как unit.

• Записываются prompt и policy hashes, model и decoding settings, tool-schema versions, embedding model, corpus snapshot и index build.
• Каждый evaluation и production trace несёт manifest ID для attribution quality или cost точной комбинации.
• Compatibility tests отклоняют unsupported prompt-tool или model-schema pairs, исключая untested mixtures при independent releases.

Я бы поставил stable instructions и tool schemas до user content и переиспользовал их exact tokenized KV prefix.

• Cache identity включает model, tokenizer, adapter, attention configuration, tenant scope и exact leading token sequence.
• Cache-aware routing улучшает locality, пока не перегружает одну replica; short prefixes могут быть дешевле recompute, чем remote transfer.
• Измеряются matched prefix length, hit rate, KV memory, saved prefill time, TTFT и routing skew на eligible traffic 80%.

Я бы добавил его только для side-effect-free questions и оптимизировал false-hit precision раньше hit rate.

• Search идёт в namespace, fixed по tenant, locale, prompt и model versions, policy и knowledge-base generation.
• Similarity и reranker калибруются на equivalent и near-miss pairs с целью false-reuse rate ниже product quality budget.
• Отслеживаются answer-quality delta, served-hit precision, hit rate, p95 и savings; repeat rate 40% не оправдывает semantically wrong reuse.