How should a battery company build an AI technical assistant?
Start with a technical knowledge assistant that can show its evidence. Add real-time battery-management-system (BMS) data only after the knowledge workflow is dependable. The first release should focus on fault codes, product manuals, test reports, and after-sales troubleshooting—not an all-purpose bot answering customers without supervision.
Battery operations combine specialist knowledge, device telemetry, and safety accountability. A fluent answer can still be dangerous if it cites an obsolete manual, confuses cell models, or presents a hypothesis as a confirmed diagnosis. The initial goal is therefore not breadth. It is traceable answers, controlled document versions, role-based access, and a safe refusal path when the evidence is insufficient.
Comparing the main approaches
| Approach | What it can do | Advantage | Main risk | Recommendation |
|---|---|---|---|---|
| General LLM chat | General battery questions, drafting, and summaries | Fastest to launch | Mixes public information with model memory and cannot guarantee the applicable product or document version | Do not use for internal technical conclusions |
| Enterprise RAG knowledge base | Search manuals, standards, reports, and resolved incidents | Can cite sources, update documents, and enforce permissions | Performance depends on version control, document preparation, and retrieval quality | Recommended first release |
| RAG + BMS data + tool use | Read alarms, state of health, cycle count, and recent activity, then support troubleshooting | Connects documented knowledge with the state of a real device | Adds API permissions, time-series data, operational risk, and more complex accountability | Build only after the knowledge assistant is stable |
A sensible first release
Choose two or three frequent, testable jobs from a short list:
- retrieve the correct manual section and troubleshooting procedure for a fault code;
- answer specification and test-condition questions for a particular product model;
- compare process or test-document revisions;
- summarize relevant historical service cases for support engineers.
Every answer should identify the source document, version, effective date, and page. If two approved sources conflict, the assistant should show the conflict and escalate it rather than selecting whichever answer sounds more plausible.
Document governance is a major part of the project. PDFs, Word files, wikis, test reports, and resolved cases need consistent metadata for product family, BMS model, firmware, market, issuing team, and expiry date. Superseded documents must be removed from retrieval, while confidential material should be filtered by role and project before the model sees it.
Adding BMS data in a second phase
Once the knowledge workflow passes evaluation, the assistant can read selected device data such as current alarms, cell-voltage spread, temperature, state of charge (SOC), state of health (SOH), cycle count, and recent charge/discharge history.
The model may explain and organize this information. Deterministic thresholds, alarm levels, and control commands should remain in rules and operational systems. Any action that could affect charging, discharging, or device control needs appropriate authorization, confirmation, audit logs, and a human fallback.
Acceptance criteria
Build the evaluation set around real job roles rather than random trivia. Measure factual correctness, valid citation rate, page-level citation accuracy, use of superseded documents, refusal on unsupported questions, unauthorized access attempts by role, P95 response time, and human escalation. Once device data is involved, add API success, timestamp freshness, and abnormal-state coverage.
Drawing on the device-integration and alerting work publicly described in Wavesteam's BMS battery-management case and agricultural-drone battery-swapping solution, we would normally pilot one role and one product family first. Schedule and expected performance should be based on document quality, API readiness, and evaluation scope; a fixed accuracy promise before the source material is inventoried would not be credible.
Sources
- The original Retrieval-Augmented Generation paper explains the technical approach; its research results do not establish performance on a company's private documents.
- The NIST Generative AI Profile covers reliability, information integrity, privacy, and human-oversight risks.
- The NISTIR 8259 IoT baseline series addresses device identification, configuration, data protection, and secure updates.
Outputs related to battery safety are decision support only. They do not replace established engineering judgment, test procedures, or approval by the accountable safety owner.