Multi-turn Dialogue and Prompt Engineering for IT Service

What the data for this category looks like

Marketing content data for IT services comes primarily from three sources: internal marketing asset libraries, customer ticket systems, and service consultation logs. Marketing asset libraries contain product plans, case whitepapers, and quotation documents, with updates aligned to quarterly marketing campaigns or new product launches. Customer ticket systems store real-time customer service requests being followed up. Service consultation logs record the service types and demand scenarios requested by users. Documents are split into two categories: structured documents with fields including service type, delivery cycle, and response time (with units such as days, yuan/person-day), and unstructured proposal texts. The length of individual documents varies widely.

What constraints these characteristics impose on multi-turn dialogue and prompt engineering

Structured fields require multi-turn dialogue to first confirm the user’s required service category. Prompts must specify extracting fields with units such as delivery cycle and response time, to avoid returning vague information without units. Long documents and multi-source data make it easy to exceed token limits for conversation context. The number and length of recalled content must be limited. Real-time ticket data requires retaining no more than the most recent 3 rounds of follow-up records in the conversation context, to avoid repeating already confirmed service requirements. Large differences in data format across sources require prompts to unify data extraction format specifications, preventing returned content from mixing structured and unstructured information.

How to set configurations

Configuration Item	Recommended Value	Rationale
`maxContext`	`8000–12000 characters`	Adapts to the total length of IT service marketing assets and ticket data, avoiding context overflow that interrupts conversations
`RECALL_TOP_K`	`Top 6–8 entries`	IT service proposal documents are lengthy; excessive recall consumes too many tokens and harms conversation smoothness
`SIMILARITY_THRESHOLD`	`0.72–0.8`	Accurately matches user needs to service types, filtering irrelevant marketing asset content
`UPLOAD_FILE_MAX_SIZE`	`500 MB`	Covers upload requirements for common marketing assets such as large proposal documents and case collections
`PARSE_FILE_TIMEOUT_SECONDS`	`300 seconds`	Adapts to parsing time for large PDF and Word format service documents
`JSON_STRICT_MODE`	`Enabled`	Ensures returned content for IT service structured fields complies with JSON format, avoiding parsing failures

The parameter values provided on this page are general recommendations to serve as a starting point for configuration. Actual values are affected by material format, data volume, and business rules. Specific issues require targeted analysis, and it is recommended to test on your own samples before finalizing settings.

Three common mistakes

Conversation returns contain line breaks, causing JSON request failures. This occurs when JSON_STRICT_MODE is not enabled, and line breaks in returned content are not escaped, breaking the JSON format of the request.
Uploading any file results in an error, but text input conversations operate normally. This happens when UPLOAD_FILE_MAX_SIZE is set smaller than the actual size of the uploaded file, or the uploaded file format is not included in the platform’s supported parsing list.
Unexpected end of JSON input error appears during conversation. When using the chatglm2 model, this occurs when the context length exceeds the maximum token limit supported by the model, or the request body is not properly closed.

How to confirm configurations are set correctly

Initiate a multi-turn conversation covering IT service types and delivery cycles, verify that returned content extracts the specified fields with corresponding units.
Upload a marketing proposal document under 500 MB, confirm parsing succeeds with no error prompts.
Initiate 5 consecutive conversations, verify that the context correctly retains previously confirmed service requirement information.
After enabling JSON_STRICT_MODE, test that returned content is valid JSON format with no formatting errors.

Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.