What an embedding is and is not
An embedding is a list of numbers that represents an input in a way software can compare with other inputs. Similar material tends to have vectors that are close according to a comparison method. The practical use is not “the vector understands a policy.” It is that an application can use the vector to find candidate material that may be relevant to a question.
OpenAI documents embeddings for search, clustering, recommendations, anomaly detection, classification, and measuring relatedness. An embedding request does not answer a customer, choose a source, check whether the source is current, or perform a refund. Those are application and policy decisions that remain outside the embeddings endpoint.
| Step in a knowledge workflow | What embeddings contribute | What still needs a decision |
|---|---|---|
| Prepare documents | A vector can be created for each approved chunk | Which sources are allowed, how they are split, and when they are refreshed |
| Retrieve candidates | A query vector can rank similar chunks | Which filters apply and whether the result is appropriate for this customer or team |
| Draft an answer | Retrieved text can be supplied to an answer model | Which instruction, citations, escalation rule, and action boundary apply |
| Deliver a result | Retrieval can inform a support workflow | Whether it reaches the correct channel and resolves the right customer issue |
Retrieval is evidence selection, not proof that a resulting answer is correct.
How to build and evaluate semantic search
A basic retrieval system takes approved source material, splits it into chunks, creates and stores embeddings, then creates an embedding for each query. It searches for nearby vectors, applies metadata and permission filters, and passes selected material into whatever answer or interface the product uses. The OpenAI embeddings guide covers the API side; your system owns storage, indexing, filtering, source refresh, observability, and failures.
Test the full chain, not just whether a vector call succeeds. Build a small, approved evaluation set that includes:
- A clear question where the expected policy is current and allowed.
- A vague request such as “where is my money back?” that should find a refund policy without exact keyword overlap.
- Two conflicting or superseded documents, where the old one must not win.
- A restricted document that must not be retrieved for an unauthorized user.
- A question with no approved answer, where the correct behavior is a handoff rather than a confident guess.
For each case, inspect the retrieved chunks before looking at the final answer. Ask whether the source is relevant, current, and permitted. Then test the response and any action separately. A high similarity score is not a policy check, and a good answer on one sample is not evidence that access filtering works.
Model choice and cost
Do not copy a stale performance table into a new design. OpenAI's current embeddings guide and pricing pages are the source for supported models and rates. The API request can set dimensions for compatible embedding models, but reducing vector size is an engineering trade-off to evaluate on your own retrieval set, not a free quality improvement.
Embedding input tokens are only one line in the cost model. Include document cleaning, initial indexing, re-embedding when sources or models change, vector storage and searches, metadata filters, evaluation runs, and the engineers or services that keep those processes working. A low price per million input tokens does not tell you whether a bad or stale source will be returned.
| Cost or quality question | Check before choosing an approach |
|---|---|
| Retrieval quality | Does the permitted, current source rank highly for representative queries? |
| Data freshness | What event triggers an update or re-embedding, and how is a failed update detected? |
| Access control | Can the retrieval layer filter by the requester's allowed records before an answer sees them? |
| Operations | Can the team trace a poor result back to source, chunk, model, and retrieval settings? |
Where eesel CLI fits for support knowledge
The OpenAI Embeddings API is infrastructure for an application you build. eesel is a ready-to-work teammate for a defined job, including helpdesk work. eesel CLI does not call the Embeddings API, choose an embedding model, or expose an OpenAI vector index. It operates the same eesel teammate and workspace available in the dashboard.
That means a support lead can inspect the setup in the dashboard while an engineer, CI script, Claude Code, Codex, or Cursor uses JSON output to check the selected teammate. This is useful for a retrieval-related question such as: “Does the refund teammate have the approved refund policy, and do its standing instructions describe the out-of-policy handoff?” It is not a way to benchmark OpenAI embedding models.
The documented CLI requires Node.js 18.17 or newer. Start by confirming the signed-in workspace and selecting the intended teammate:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
TARGET_EESEL_AGENT="paste-agent-id-or-name-here"
npx @eesel/cli status --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli integrations --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli instructions --agent "$TARGET_EESEL_AGENT"
status can show what is connected and whether content has downloaded; it does not prove that retrieval or answering is good. A coding agent can read those JSON results, identify a missing source or unclear instruction, and report the gap first. It should not add files, alter instructions, or enable an automation without the support owner's approval.
After a manager approves a new policy file and target teammate, a technical teammate can add it and confirm that it is present:
npx @eesel/cli files upload ./approved-refund-policy.pdf --agent "$TARGET_EESEL_AGENT" --dry-run
npx @eesel/cli files upload ./approved-refund-policy.pdf --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli files ls --agent "$TARGET_EESEL_AGENT"
Before testing, review what actions and permissions the selected teammate has. Disable or contain actions outside the test scope; a held-action queue is not a substitute for checking what can run without a hold. Then ask fictional questions that cover expected retrieval and the known handoff:
npx @eesel/cli new --name "refund-knowledge-check" --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli chat "A customer asks for a refund outside the normal window. Use the approved policy, identify missing evidence, and state when a human must decide." --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli approvals --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli activity --agent "$TARGET_EESEL_AGENT"
Finally, verify the helpdesk or channel outcome after a controlled rollout. A downloaded source, a terminal reply, or an activity row alone does not prove a customer received the correct result.
Choose the system that owns the job you need
Build with embeddings when your product needs a custom retrieval architecture and your team will own source pipelines, access filtering, evaluation, and the user-facing workflow. Measure it on the data and permissions it will actually face.
Use eesel when the job is a helpdesk teammate working with your company knowledge and workflows. The CLI is the terminal route into that same teammate, not a separate vector database or model API. It lets technical users make inspection and bounded configuration repeatable while support owners retain approval and outcome checks.
Inspect support knowledge with eesel
Try eesel if you want to operate a helpdesk teammate without beginning with a blank retrieval stack. Start with approved knowledge and a small, representative question set; inspect its connections and instructions in the dashboard or CLI, test expected handoffs, and verify results before expanding customer access. Check eesel pricing separately from OpenAI embedding rates because they are different products and units of work.
The Activity page provides a dashboard-side record to compare with the CLI's JSON output after a controlled knowledge test.
Frequently asked questions
What does the OpenAI Embeddings API do?
The OpenAI Embeddings API turns an input into a vector representation that software can compare with other vectors. It is useful for search, clustering, classification, and retrieval, but it does not supply the database, permissions, or customer-facing workflow.
Are embeddings the same as a support answer?
No. An embedding helps retrieve or compare material. A separate application decides what to retrieve, how to use it in an answer, what actions are allowed, and when the customer should be handed to a person.
How should I test embeddings for a support knowledge base?
Use approved questions with expected sources and include vague wording, conflicting policies, outdated documents, and queries that should produce no answer. Measure whether the retrieved source is relevant and permitted, then separately test the answer and any downstream action.
Do I need a vector database for OpenAI embeddings?
You need some way to store vectors and retrieve comparable records at your required scale. The embedding API supplies vectors; your architecture determines storage, indexing, filtering, refreshes, access control, and retrieval behavior.
How is the OpenAI Embeddings API priced?
OpenAI prices embedding models by input tokens. Check the current pricing page for the selected model, then include storage, indexing, re-embedding, retrieval, evaluation, and application operations in the total cost.
Does eesel CLI create OpenAI embeddings?
No. eesel CLI is not an OpenAI embedding endpoint. It lets people, scripts, and coding agents operate an eesel teammate: inspect connected knowledge, instructions, activity, and approvals in the same workspace as the dashboard.
Can a coding agent use eesel CLI for knowledge checks?
Yes. Claude Code, Codex, Cursor, or a script can use JSON output and explicit agent scope to inspect a selected teammate. A person should still approve new knowledge, use --dry-run for supported writes, test representative questions, and verify the actual helpdesk outcome.
Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.
