Enterprise HR · RAG Case study

Ask People Team

Anaconda / Agent.Press

An internal HR knowledge assistant for Anaconda employees, answered inside Slack from the company’s own People Team documents.

Anaconda / Agent.Press

Ask People Team Ask People Team

AI Systems & Platform Engineering

System map · Knowledge system

Engineering approach

  • Reviewed before it lands A human between the model and the employee
  • Accepted against a dataset Retrieval changes scored, not judged on impression

Answer path

  1. Knowledge sources

    People Team documents

  2. Ingestion

    Chunked, metadata at both levels

  3. Hybrid retrieval

    Dense

    Matches meaning

    Sparse

    Matches exact terms

  4. Grounded answer

    Drafted from retrieved passages

  5. Human review

    Before an employee sees it

  6. Slack

    Where employees already are

Measured, not assumed

  • Golden-dataset evaluation
  • Retrieval and answer scoring
  • Evaluation dashboard
  • Per-question tracing

Engineering

Python · FastAPI · Hybrid retrieval · Milvus · Evaluation service · Phoenix

Named with approval · Internal HR content, prompts and workspace details omitted

Role
AI Systems & Platform Engineering
Disclosure
Named with approval · Internal HR content, prompts and workspace details omitted

The problem

What the system had to solve.

An employee asking about leave, notice or benefits is making a consequential personal decision and will act on the answer. A confidently wrong answer is worse than no assistant, because it carries the organisation’s authority.

The assistant therefore had to answer only from the company’s own People Team documents, keep a human between the model and the employee, and make retrieval quality something that could be measured rather than assumed.

What I owned

The responsibility behind the work.

Worked across the assistant’s retrieval and evaluation surface: the Slack workflow and its intent routing, the document ingestion pipeline, hybrid retrieval over a vector store, the evaluation service and dashboard, and the tracing and deployment tooling around them.

Engineering approach

How it was built.

Documents are chunked with more than one strategy and carry metadata at both document and chunk level, so a retrieved passage is attributable. Retrieval combines dense and sparse matching to cover each other’s failure modes. A dedicated evaluation service scores the system against a curated golden dataset and reports to a dashboard, and tracing records routing, retrieval and generation so a specific bad answer can be reconstructed.

Answer path

  1. Question
  2. Routing
  3. Retrieval
  4. Review
  5. Answer

Answering HR questions is not a chat problem

Why this class of assistant is judged differently.

An employee asking about parental leave, notice periods or benefits is not browsing. They are making a decision, often a consequential and personal one, and they will act on whatever the assistant says. A confidently wrong answer about entitlement is worse than no assistant at all, because it carries the organisation’s authority.

That reframes the engineering. The hard requirements are not fluency or coverage. They are: answer only from the company’s own documents, make it clear where an answer came from, and have a way of knowing whether retrieval quality is getting better or worse.

What the system had to guarantee

  • Answers grounded in the company’s own People Team documents
  • A human check before an answer reaches an employee
  • Measurable retrieval quality
  • Traceable behaviour for any given question
  • Delivery where employees already are

Inside Slack, not another portal

Meeting employees where the question is asked.

The assistant lives in Slack. An HR knowledge tool that requires finding a portal, logging in and searching is a tool people use once. The question gets asked in the place people are already complaining that they cannot find the answer.

Question path

  1. Employee asks in Slack
  2. Intent routing By question type
  3. Retrieval over People Team documents
  4. Grounded answer drafted
  5. Human review
  6. Answer reaches the employee
Routing by intent first, because a policy question, a benefits question and a "who do I ask about this" question want different handling.

Turning documents into retrievable knowledge

Chunking is where retrieval quality is decided.

HR documents are long, structured and full of clauses that only make sense in context. Split them badly and retrieval returns a fragment that reverses the meaning of the paragraph it came from.

The ingestion pipeline therefore treats chunking as a first-class decision rather than a default. More than one strategy is implemented — sentence-aware and recursive — so the approach can be chosen and compared rather than assumed.

Ingestion pipeline

  1. Source document
  2. Document-level metadata
  3. Chunking Sentence-aware or recursive
  4. Chunk-level metadata
  5. Embedding
  6. Vector store
Metadata is generated at both document and chunk level, so a retrieved fragment carries the context needed to judge and cite it.

Chunk-level metadata is what makes an answer attributable. Without it a retrieved passage is text with no provenance, and provenance is most of what makes an HR answer usable.

Hybrid retrieval

Two ways of being relevant.

Dense vector search finds passages that mean the same thing in different words, which is what employees actually type. Sparse keyword matching finds exact terms — a policy name, a form number, a specific benefit — where semantic similarity is not enough. Using both covers the failure mode of each.

Why both

Dense retrieval

  • Matches meaning, not wording
  • Handles how employees actually phrase questions
  • Weak on exact names and identifiers

Sparse retrieval

  • Matches exact terms
  • Finds named policies and forms
  • Weak when the question uses different words
Each retrieval mode fails in a way the other one covers, which is the whole argument for combining them.

The vector store runs as a deployed service with its own storage and coordination components rather than as a library, so the index is operable, inspectable and separable from the application that queries it.

A human between the model and the employee

The control that makes the rest acceptable.

Retrieval quality can be improved but not guaranteed, and HR answers carry consequences. A human review step sits before an answer reaches an employee, which changes what the model has to be: not the final authority, but a well-grounded first draft with its sources attached.

The review step is also the cheapest source of evaluation data. Every corrected or rejected answer is a labelled example of where retrieval fell short.

Evaluation as a service

Knowing whether a change made it better.

Retrieval systems degrade quietly. A chunking change, a new document set or a model swap can improve some questions and break others, and nobody notices until an employee is told something wrong.

A dedicated evaluation service runs the system against a curated golden dataset of questions with known good answers, and reports the result to a dashboard. That turns "does this change help" from an opinion into a measurement.

Evaluation loop

  1. Golden dataset Questions with known good answers
  2. Run the current system
  3. Score retrieval and answers
  4. Dashboard comparison
  5. Accept or reject the change
Run against a fixed dataset, compare, then decide — rather than shipping a retrieval change and waiting to hear about it.

What evaluation protects against

  • A chunking change that helps some questions and breaks others
  • Retrieval quality drifting as documents change
  • A model swap that regresses grounding
  • Improvements that are only visible on the examples someone happened to try

Tracing and session logging

Reconstructing why an answer happened.

When someone reports a bad answer, the question is which stage failed: routing, retrieval, or the model’s use of what it retrieved. Tracing across the pipeline records each stage, so a specific answer can be reconstructed rather than guessed at.

What is captured

  • The routed intent
  • Retrieved passages and their scores
  • The model call and its output
  • The review outcome
  • Session history

Tracing and evaluation answer different questions. Tracing explains one answer; evaluation tells you whether the system as a whole is improving.

Running it

A multi-service system that has to be reproducible.

The assistant, the ingestion pipeline, the evaluation service, its dashboard, the vector store and its supporting components, the relational database and the tracing service are all separate services, composed so the whole system runs locally as well as deployed.

Components

Application

  • Slack assistant
  • Ingestion pipeline
  • Evaluation service
  • Evaluation dashboard

Infrastructure

  • Vector store
  • PostgreSQL
  • Versioned SQL migrations
  • Tracing service
  • Containerised deployment

Schema changes ship as versioned migrations rather than as manual steps, which is what makes the difference between an evaluation environment that matches production and one that only claims to.

Engineering scope

What I worked on.

  1. Slack assistant with intent routing per question type
  2. Document ingestion, chunking and embedding pipeline
  3. Hybrid dense and sparse retrieval over a vector store
  4. Human review before an answer reaches an employee
  5. Evaluation service, dashboard and retrieval-quality tracking
  6. Tracing, session logging and containerised deployment

Why these decisions mattered

The trade-offs behind the assistant.

  • Human review before delivery

    Decision
    An answer is reviewed before an employee sees it.
    Why
    HR answers are acted on. Retrieval quality can be improved, not guaranteed.
  • Hybrid retrieval

    Decision
    Dense and sparse retrieval together.
    Why
    Employees ask in their own words but policies have exact names; neither mode handles both.
  • Chunking as a decision, not a default

    Decision
    Multiple chunking strategies, comparable against each other.
    Why
    Where a document is split determines whether a retrieved passage still means what it said.
  • A dedicated evaluation service

    Decision
    Score against a golden dataset and report to a dashboard.
    Why
    Retrieval regressions are invisible without measurement until someone is told something wrong.
  • Deliver in Slack

    Decision
    The assistant lives where employees already work.
    Why
    A knowledge tool behind another login is a tool people use once.
  • Tracing from the start

    Decision
    Every stage of a question is traced.
    Why
    Debugging a bad answer means knowing whether routing, retrieval or generation failed.

Impact

What the design protects.

Retrieval changes are accepted or rejected against a golden dataset rather than on impression, every answer is reviewed before an employee sees it, and any answer can be traced back through routing, retrieval and generation.

Technology

The technical surface.

  • Python
  • FastAPI
  • OpenAI
  • Milvus
  • PostgreSQL
  • Phoenix
  • Docker
  • Kubernetes

Next: ScribeFlow

Back to all work Start a conversation