Customer-service knowledge: model connections for product questions

What the documents look like

This page covers model connection and configuration for product data and selection questions inside customer-service knowledge-base maintenance. The working documents are FAQ entries, reply templates, product parameter tables, and escalation tickets. Knowledge-base maintenance prepares question-and-answer material in advance and does not approve refunds directly, so the connection step exists to keep selection answers traceable to maintained product parameters and standard replies.

Two industry facts shape the work. First, the material set mixes structured parameter tables with free-text FAQ entries and templates, so a single answer may draw on a capacity figure from one table and a care instruction from another. Second, the parameters and templates are revised on a weekly or monthly cycle, and the connection check follows the material version rather than firing automatically when a document changes. The eight-dimension brief also notes that errors here surface as off-topic answers, escalated complaints, and failed agent training, which is why the checks below compare proposed copy against the maintained source text rather than against general product knowledge.

Constraints at the model connections step

Model access depends on AI Proxy. From V4.17.0, both the App and an Admin service that reuses App/Service configuration must set AIPROXY_API_ENDPOINT and a non-empty AIPROXY_API_TOKEN; a missing value in either item fails startup validation. Legacy OpenAI environment variables and a single-model custom request address do not substitute for these two. AIPROXY_API_ENDPOINT takes the service root address without a /v1 suffix. The system needs at least one language model and one index model to operate.

A model ID is the value of the model field in the request body and is globally unique; the model name is a display label that can be customized. In the documented mapping example, FastGPT requests gpt-4o-test and AI Proxy sends gpt-4o upstream. Model probing covers enabled system models only: after a first failure the system retries up to three more times, and only four failed attempts mark the model abnormal. Retrieval and similarity scores do not act as permission or entity filters, and the same-vector-model requirement inside a retrieval library does not extend to external systems.

Configuration and implementation checks

The sample below is a clearly labelled hypothetical paper exercise. It is not a record of any real customer, product, or test.

Hypothetical exercise sample: on a paper date of October 2026, a knowledge-base operator receives a proposed reply sentence awaiting review: "The A-type electric kettle supports a 1.7 L capacity and can be placed in a dishwasher for cleaning." The product parameter table supplied for comparison reads: "A-type electric kettle, capacity 1.7 L, body material 304 stainless steel, dishwasher cleaning not supported, hand wash only." The proposed sentence and the source text disagree on the cleaning-method field and agree on the capacity field. The configuration rows below serve this comparison exercise.

The mapping row is a configuration check, not evidence that any request was sent. Whether the upstream model identifier matches the mapping can only be read from the call log, and if no log entry is observed the item stays unverified. The probe interval row is a hypothetical starting value for this exercise, not an official default.

Three common errors

1. Writing AIPROXY_API_ENDPOINT as a full request address with a /v1 suffix. The check input is the environment variable value and the documented root-address form; the observable result is whether a path suffix appears.
2. Using an application API key as AIPROXY_API_TOKEN. The check input is the token source and the server-side administrator token; the observable result is whether the two values match and are non-empty.
3. Treating "can be placed in a dishwasher" in the proposed sentence as supported by the parameter table. The check input is the proposed sentence and the cleaning-method field of the parameter table; the observable result is whether the two values are mutually exclusive on the same field.

How to verify the setup

1. Take the proposed sentence and the parameter table text above and compare the cleaning-method field. The table states dishwasher cleaning is not supported; the proposed sentence states it can be placed in a dishwasher. The same field carries mutually exclusive values, so the sentence is judged contradictory and must be returned for rewriting.
2. Take the same two texts and compare the capacity field. The table states 1.7 L and the proposed sentence states 1.7 L. The values agree, so this field is supported.
3. Take the model mapping configuration and the model field in the request body and compare the mapping relation. The configuration maps gpt-4o-test to gpt-4o and the request uses gpt-4o-test, so the mapping relation holds. The actual upstream model identifier requires observation in the call log; with no observation, record the item as pending verification.

Probe alert delivery, Webhook connectivity, and retry outcomes are external-system behaviours; without an actual trigger they remain unknown. When a retrieval query returns an empty result, a downstream design can be checked against an explicit paper input of []; this does not establish that a fictional rule always returns an empty array. A pending review does not show that operation permission is absent, and an unsigned termination is not a completed termination.

Related reading

• self-host/config/env
• self-host/config/model/intro
• FastGPT model connections